[Xen-devel] [distros-debian-sid test] 44342: tolerable trouble: blocked/broken
flight 44342 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44342/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf 3 host-install(3) broken like 44297 build-armhf-pvops 3 host-install(3) broken like 44297 build-i3863 host-install(3) broken like 44297 build-i386-pvops 3 host-install(3) broken like 44297 build-amd64 3 host-install(3) broken like 44297 build-amd64-pvops 3 host-install(3) broken like 44297 Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-sid-netboot-pygrub 1 build-check(1)blocked n/a test-amd64-amd64-i386-sid-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-sid-netboot-pvgrub 1 build-check(1)blocked n/a test-amd64-i386-amd64-sid-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-i386-i386-sid-netboot-pvgrub 1 build-check(1) blocked n/a baseline version: flight 44297 jobs: build-amd64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-sid-netboot-pvgrubblocked test-amd64-i386-i386-sid-netboot-pvgrub blocked test-amd64-i386-amd64-sid-netboot-pygrub blocked test-armhf-armhf-armhf-sid-netboot-pygrubblocked test-amd64-amd64-i386-sid-netboot-pygrub blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] The order of contents saved in "/var/run/xenstored/db" is reversed
> -Original Message- > From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: Sunday, April 17, 2016 8:21 PM > To: Sunguodong > Cc: xen-devel@lists.xen.org; Fanhenglong; Wei Liu > Subject: Re: [Xen-devel] The order of contents saved in > "/var/run/xenstored/db" is reversed > > On Sun, Apr 17, 2016 at 10:28:24AM +, Sunguodong wrote: > > Hi all, > > > > I have a question about oxenstored, please help if someone knows. > > Oxenstored saves store information to "/var/run/xenstored/db" when it > quits, but the contents is reversed. > > For example, > > before restart oxenstored, the output of 'xenstore-ls -f' is: > > ... > > /local/domain/0/memory/target = "8388608" > > /local/domain/0/memory/static-max = "4294967292" > > /local/domain/0/memory/freemem-slack = "0" > > ... > > after restart oxenstored, the output is: > > ... > > /local/domain/0/memory/freemem-slack = "0" > > /local/domain/0/memory/static-max = "4294967292" > > /local/domain/0/memory/target = "8388608" > > ... > > > > I found why when I read the code: > > When a new element is added to node list, it is added to the head of > the list, so the newest element will always be saved first, and then > restored first. > > > > Then question is: > > 1.What is the reason for this, is this done on purpose? > > 2.What is the impact of doing so if I save the store information in > the original order(first come first saved, and first saved first > restored ^_^)? > > > > Why do you care much about what order they appear in the output? I I was debugging it, and just confused about that. I was thinking if there are any features relied on the order and affected when oxenstored restored in reverse order. > don't > think the tools should make assumption on the order they appear and the > order doesn't matter. OK, I get it, thank you. > > In any case, if you need to have consistent view: > > xenstore-ls -f | sort > > Wei. > > > > Looking forward to your reply, thank you! > > > > Regards, > > Jason > > > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8.1 04/27] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op
On Sun, Apr 17, 2016 at 02:05:10AM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk 04/15/16 4:29 AM >>>
> >On Thu, Apr 14, 2016 at 10:36:46AM -0600, Jan Beulich wrote:
> >> >>> Konrad Rzeszutek Wilk 04/14/16 12:05 AM >>>
> >> > @@ -460,6 +461,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
> >> > u_sysctl)
> >> > ret = tmem_control(&op->u.tmem_op);
> >> > break;
> >> >
> >> > +case XEN_SYSCTL_xsplice_op:
> >> > +ret = xsplice_op(&op->u.xsplice);
> >> > +copyback = (ret == -ENOSYS || ret == -EOPNOTSUPP) ? 0 : 1;
> >>
> >> Why use a conditional expression here when its condition already is a
> >> boolean one
> >> just needing negating?
> >
> >B/c I thought you would want it this way.
> >
> >I changed it to
> >
> >466 if ( ret != -ENOSYS && ret != -EOPNOTSUPP )
> >467 copyback = 1;
>
> That's fine too.
>
> >But I don't think this what you meant by 'negating'? As in:
> >
> >copyback = !rc ?
> >
> >But one of the subops returns the number of items and we definitly
> >want copyback=1 for that.
>
> What I mean with "negating" was
>
> copyback = (ret != -ENOSYS && ret != -EOPNOTSUPP);
>
> >> > +spin_lock(&payload_lock);
> >> > +
> >> > +found = find_payload(n);
> >> > +if ( IS_ERR(found) )
> >> > +{
> >> > +rc = PTR_ERR(found);
> >> > +goto out;
> >> > +}
> >> > +else if ( found )
> >> > +{
> >> > +rc = -EEXIST;
> >> > +goto out;
> >> > +}
> >> > +
> >> > +data = xzalloc(struct payload);
> >>
> >> I generally advocate for not doing allocations with locks held, and I
> >> don't think
> >> it would severely complicate the code here doing so.
> >
> >I can certainly unlock and then lock again (when adding
> >it to the list).
>
> That would create a race again afaict. Instead what I have been trying to hint
> at is that the allocation should be done before taking the lock, freeing the
> object
> again if in the end it turned out it's not going to be needed. Hence the
> referral to
What if I get -ENOMEM and that the user supplied an payload we already
have? In that case I would return -ENOMEM while I would expect us to
return -EEXIST.
Unless I add some extra checks to continue on?
Also one could do a bit of memory DoS (perhaps by mistake) by continously
uploading the same and same payload and us first allocating the memory,
and then doing the check for the payload existence (which would then
free the memory). Since the allocation is outside the lock we can
eat a bit of memory.
> possibly complicating the code.
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] xen cpu scheduler internals
Hi, I think pick_cpu function in schedule.c can be a good starting point, am i right? From: tutu sky Sent: Sunday, April 17, 2016 6:18 PM To: Xen-devel@lists.xen.org Subject: xen cpu scheduler internals Hi, I know that scheduling is done via two main functions and their effective interaction: one 'schedule()' in schedule.c and another 'do_schedule(...)', which is specific for every scheduling policy. my question is that (although it may seem clear and very common for kernel developers, but not as mush for me): when a vcpu is selected to run on a specific cpu, what is the policy for choosing cpu (pcpu)? I see smp_processor_id() very frequent, and in my suppose, the current cpu is the cpu which is used for scheduling (i just think so). if i need to choose and find more than one cpu for running my tasks on, what should i do in scheduler context? Thanks and regards. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ARMv8: New board bring up hangs in kernel start?
On 16/04/2016 18:39, Dirk Behme wrote: Hi Julien, Hi Dirk, On 06.04.2016 12:48, Julien Grall wrote: On 04/04/2016 16:44, Dirk Behme wrote: Hi Julien, I'm using https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/renesas/r8a7795.dtsi#n134 The special thing here is that it has the offsets 0x1, 0x2, 0x4 and 0x6. Instead of the standard ones 0x1000, 0x2000, 0x4000 and 0x6000. Those offsets are normal, this platform seems to have a GIC using 64KB-aligned region rather than the classic 4KB-aligned one. Now, just by try & error, using [1] makes things working. I'm not sure why this changes anything, though: * To my understanding, the GIC register ranges are max 0x1000. So I'd think that the 0x2000 should be sufficient to map all necessary registers. * I haven't observed any MMU fault. So it didn't look like any non-mapped register was accessed without this change. Xen is checking if the platform is using an aliased GIC when the CPU interface size is 128KB (see gicv2_is_aliased and commit 21550029f709072aacf3b90edd574e7d3021b400). If you see "GICv2: Adjusting CPU interface base to..." then your GIC is aliased. In any case, the device-tree does not correctly describe the hardware on your platform. Can you send a patch to fix the upstream device-tree? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-i386-xl-qemut-win7-amd64
CC Paul and Andrew The bisector figured the said commit broke 3.18 test. Wei. On Sun, Apr 17, 2016 at 03:57:12PM +, osstest service owner wrote: > branch xen-unstable > xenbranch xen-unstable > job test-amd64-i386-xl-qemut-win7-amd64 > testid leak-check/check > > Tree: linux > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git > Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git > Tree: qemuu git://xenbits.xen.org/qemu-xen.git > Tree: xen git://xenbits.xen.org/xen.git > > *** Found and reproduced problem changeset *** > > Bug is in tree: xen git://xenbits.xen.org/xen.git > Bug introduced: a6f2cdb633bf519244a16674031b8034b581ba7f > Bug not present: d0540cbd4a9065b043ae5a26bb28b798f77a085b > Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/91781/ > > > commit a6f2cdb633bf519244a16674031b8034b581ba7f > Author: Paul Durrant > Date: Thu Mar 17 13:50:39 2016 +0100 > > x86/hvm/viridian: keep APIC assist page mapped... > > ... for the lifetime of the domain. > > If Xen is to make use of the APIC assist enlightenment then a persistent > mapping needs to be kept, rather than the temporary one which is > currently > used only to initialize the page content. > > This patch also adds a comment block at the top of the source with > information on the latest version of the spec. from Microsoft and the > current URL where it may be found. > > Signed-off-by: Paul Durrant > Reviewed-by: Andrew Cooper > > > For bisection revision-tuple graph see: > > http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-i386-xl-qemut-win7-amd64.leak-check--check.html > Revision IDs in each graph node refer, respectively, to the Trees above. > > > Running cs-bisection-step > --graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-i386-xl-qemut-win7-amd64.leak-check--check > --summary-out=tmp/91781.bisection-summary --basis-template=86513 > --blessings=real,real-bisect linux-3.18 test-amd64-i386-xl-qemut-win7-amd64 > leak-check/check > Searching for failure / basis pass: > 91420 fail [host=italia1] / 86513 [host=chardonnay0] 85493 [host=fiano0] > 66698 [host=huxelrebe1] template as basis? using template as basis. > Failure / basis pass flights: 91420 / 86513 > (tree with no url: minios) > (tree with no url: ovmf) > (tree with no url: seabios) > Tree: linux > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git > Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git > Tree: qemuu git://xenbits.xen.org/qemu-xen.git > Tree: xen git://xenbits.xen.org/xen.git > Latest b36eba9b4dd4344ed51b8f644049aeac606ccff2 > c530a75c1e6a472b0eb9558310b518f0dfcd8860 > 21f6526d1da331611ac5fe12967549d1a04e149b > 316a862e5534249a6e6d876b4e203342d3fb870e > a6f2cdb633bf519244a16674031b8034b581ba7f > Basis pass d439e869d612dd7a338ac75a4afc3646a5e67370 > c530a75c1e6a472b0eb9558310b518f0dfcd8860 > 21f6526d1da331611ac5fe12967549d1a04e149b > 316a862e5534249a6e6d876b4e203342d3fb870e > efc904263f483026672a5cdf3ccf9be8c4fdaa31 > Generating revisions with ./adhoc-revtuple-generator > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#d439e869d612dd7a338ac75a4afc3646a5e67370-b36eba9b4dd4344ed51b8f644049aeac606ccff2 > > git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 > > git://xenbits.xen.org/qemu-xen-traditional.git#21f6526d1da331611ac5fe12967549d1a04e149b-21f6526d1da331611ac5fe12967549d1a04e149b > > git://xenbits.xen.org/qemu-xen.git#316a862e5534249a6e6d876b4e203342d3fb870e-316a862e5534249a6e6d876b4e203342d3fb870e > > git://xenbits.xen.org/xen.git#efc904263f483026672a5cdf3ccf9be8c4fdaa31-a6f2cdb633bf519244a16674031b8034b581ba7f > Loaded 2002 nodes in revision graph > Searching for test results: > 86513 [host=chardonnay0] > 89247 fail b36eba9b4dd4344ed51b8f644049aeac606ccff2 > c530a75c1e6a472b0eb9558310b518f0dfcd8860 > 21f6526d1da331611ac5fe12967549d1a04e149b > 316a862e5534249a6e6d876b4e203342d3fb870e > a6f2cdb633bf519244a16674031b8034b581ba7f > 89339 blocked b36eba9b4dd4344ed51b8f644049aeac606ccff2 > c530a75c1e6a472b0eb9558310b518f0dfcd8860 > 21f6526d1da331611ac5fe12967549d1a04e149b > 316a862e5534249a6e6d876b4e203342d3fb870e > a6f2cdb633bf519244a16674031b8034b581ba7f > 90846 blocked b36eba9b4dd4344ed51b8f644049aeac606ccff2 > c530a75c1e6a472b0eb9558310b518f0dfcd8860 > 21f6526d1da331611ac5fe12967549d1a04e149b > 316a862e5534249a6e6d876b4e203342d3fb870e > a6f2cdb633bf519244a16674031b8034b581ba7f > 90979 fail b36eba9b4dd4344ed51b8f644049aeac606ccff2 > c530a75c1e6a472b0eb9558310b518f0dfcd8860 > 21f6526d1da331611ac5fe12967549d1a04e149b >
Re: [Xen-devel] Update SeaBIOS to include 8a0df3
On 4/15/16 10:29 AM, Roger Pau Monné wrote: > On Fri, Apr 15, 2016 at 10:19:49AM +0100, Wei Liu wrote: >> On Thu, Apr 14, 2016 at 06:51:04PM +0200, Roger Pau Monné wrote: >>> Hello, >>> >>> I would like to request an update of the SeaBIOS repository to include the >>> latest commits in the 1.9-stable branch. I'm only interested in commit >>> 8a0df3, which is basically our current version (rel-1.9.1) plus a build fix >>> for FreeBSD (or for objcopy implementations that are strict regarding >>> alignments). >>> >>> Would it be possible to push it to our SeaBIOS and update Config.mk, or now >>> is too late? >>> >> >> I can look into that. But I would wait until we get a push to master. >> That has not happened for a month. > > No problem, it's not very important TBH, but it would be a "nice to have". > > Roger. > We could also ask Kevin to do a 1.9.2 from the 1.9-stable branch. There's one more commit on top of the one that Roger asked for in the 1.9-stable branch. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-i386-xl-qemut-win7-amd64
On 18/04/16 09:23, Wei Liu wrote: CC Paul and Andrew The bisector figured the said commit broke 3.18 test. Should be fixed by c/s 78c5f59 "x86/hvm/viridian: save APIC assist vector" ~Andrew Wei. On Sun, Apr 17, 2016 at 03:57:12PM +, osstest service owner wrote: branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-win7-amd64 testid leak-check/check Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: a6f2cdb633bf519244a16674031b8034b581ba7f Bug not present: d0540cbd4a9065b043ae5a26bb28b798f77a085b Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/91781/ commit a6f2cdb633bf519244a16674031b8034b581ba7f Author: Paul Durrant Date: Thu Mar 17 13:50:39 2016 +0100 x86/hvm/viridian: keep APIC assist page mapped... ... for the lifetime of the domain. If Xen is to make use of the APIC assist enlightenment then a persistent mapping needs to be kept, rather than the temporary one which is currently used only to initialize the page content. This patch also adds a comment block at the top of the source with information on the latest version of the spec. from Microsoft and the current URL where it may be found. Signed-off-by: Paul Durrant Reviewed-by: Andrew Cooper For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-i386-xl-qemut-win7-amd64.leak-check--check.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-i386-xl-qemut-win7-amd64.leak-check--check --summary-out=tmp/91781.bisection-summary --basis-template=86513 --blessings=real,real-bisect linux-3.18 test-amd64-i386-xl-qemut-win7-amd64 leak-check/check Searching for failure / basis pass: 91420 fail [host=italia1] / 86513 [host=chardonnay0] 85493 [host=fiano0] 66698 [host=huxelrebe1] template as basis? using template as basis. Failure / basis pass flights: 91420 / 86513 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest b36eba9b4dd4344ed51b8f644049aeac606ccff2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 21f6526d1da331611ac5fe12967549d1a04e149b 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf519244a16674031b8034b581ba7f Basis pass d439e869d612dd7a338ac75a4afc3646a5e67370 c530a75c1e6a472b0eb9558310b518f0dfcd8860 21f6526d1da331611ac5fe12967549d1a04e149b 316a862e5534249a6e6d876b4e203342d3fb870e efc904263f483026672a5cdf3ccf9be8c4fdaa31 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#d439e869d612dd7a338ac75a4afc3646a5e67370-b36eba9b4dd4344ed51b8f644049aeac606ccff2 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#21f6526d1da331611ac5fe12967549d1a04e149b-21f6526d1da331611ac5fe12967549d1a04e149b git://xenbits.xen.org/qemu-xen.git#316a862e5534249a6e6d876b4e203342d3fb870e-316a862e5534249a6e6d876b4e203342d3fb870e git://xenbits.xen.org/xen.git#efc904263f483026672a5cdf3ccf9be8c4fdaa31-a6f2cdb633bf519244a16674031b8034b581ba7f Loaded 2002 nodes in revision graph Searching for test results: 86513 [host=chardonnay0] 89247 fail b36eba9b4dd4344ed51b8f644049aeac606ccff2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 21f6526d1da331611ac5fe12967549d1a04e149b 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf519244a16674031b8034b581ba7f 89339 blocked b36eba9b4dd4344ed51b8f644049aeac606ccff2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 21f6526d1da331611ac5fe12967549d1a04e149b 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf519244a16674031b8034b581ba7f 90846 blocked b36eba9b4dd4344ed51b8f644049aeac606ccff2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 21f6526d1da331611ac5fe12967549d1a04e149b 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf519244a16674031b8034b581ba7f 90979 fail b36eba9b4dd4344ed51b8f644049aeac606ccff2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 21f6526d1da331611ac5fe12967549d1a04e149b 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf51
[Xen-devel] [ovmf test] 91849: regressions - FAIL
flight 91849 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91849/ 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. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 60cfeeb3b656e746f98620cb99a971ee6310b028 baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 131 days Failing since 65593 2015-12-08 23:44:51 Z 131 days 152 attempts Testing same since91849 2016-04-18 02:26:49 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19615 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 April 2016 22:48
> To: xen-devel@lists.xen.org
> Cc: Andrew Cooper; Paul Durrant; George Dunlap; Jun Nakajima; Kevin Tian;
> zhiyuan...@intel.com; Yu Zhang; Keir (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm
> to p2m_ioreq_server
>
> >>> On 31.03.16 at 12:53, wrote:
> > --- a/xen/include/public/hvm/hvm_op.h
> > +++ b/xen/include/public/hvm/hvm_op.h
> > @@ -83,7 +83,7 @@ typedef enum {
> > HVMMEM_ram_rw, /* Normal read/write guest RAM */
> > HVMMEM_ram_ro, /* Read-only; writes are discarded */
> > HVMMEM_mmio_dm,/* Reads and write go to the device model
> */
> > -HVMMEM_mmio_write_dm /* Read-only; writes go to the device
> model */
> > +HVMMEM_ioreq_server,
> > } hvmmem_type_t;
> >
> > /* Following tools-only interfaces may change in future. */
>
> So there's one problem here, which the comment at the bottom
> of the context already hints at: This enum is part of the not
> tools restricted interface (as HVMOP_get_mem_type is usable
> by guests themselves), which we cannot change like this. Since
> the meaning of the enumerator value doesn't change, I guess
> we can get away with simply retaining its old name for non-up-
> to-date __XEN_INTERFACE_VERSION__.
>
Has the type made it into a release yet. I was assuming we could make the
change without any need to play with the version since it's only ever been
present in xen-unstable so far.
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] xen cpu scheduler internals
On Sun, Apr 17, 2016 at 7:18 PM, tutu sky wrote: > Hi, > I know that scheduling is done via two main functions and their effective > interaction: > one 'schedule()' in schedule.c and another 'do_schedule(...)', which is > specific for every scheduling policy. > my question is that (although it may seem clear and very common for kernel > developers, but not as mush for me): > when a vcpu is selected to run on a specific cpu, what is the policy for > choosing cpu (pcpu)? I'm afraid that's not the kind of question that's easy or useful to answer. Your best bet here is to look at the actual code and come back with more specific questions. See also http://wiki.xenproject.org/wiki/Asking_Developer_Questions. If the second question is asking about gang scheduling, you need to arrange for schedule() to be called on several cpus simultaneously (by raising the SCHEDULE softirq), and then you need to arrange for the specific scheduler code on each processor to choose the appropriate cpu. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
On Mon, Apr 18, 2016 at 9:41 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 08 April 2016 22:48
>> To: xen-devel@lists.xen.org
>> Cc: Andrew Cooper; Paul Durrant; George Dunlap; Jun Nakajima; Kevin Tian;
>> zhiyuan...@intel.com; Yu Zhang; Keir (Xen.org); Tim (Xen.org)
>> Subject: Re: [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm
>> to p2m_ioreq_server
>>
>> >>> On 31.03.16 at 12:53, wrote:
>> > --- a/xen/include/public/hvm/hvm_op.h
>> > +++ b/xen/include/public/hvm/hvm_op.h
>> > @@ -83,7 +83,7 @@ typedef enum {
>> > HVMMEM_ram_rw, /* Normal read/write guest RAM */
>> > HVMMEM_ram_ro, /* Read-only; writes are discarded */
>> > HVMMEM_mmio_dm,/* Reads and write go to the device model
>> */
>> > -HVMMEM_mmio_write_dm /* Read-only; writes go to the device
>> model */
>> > +HVMMEM_ioreq_server,
>> > } hvmmem_type_t;
>> >
>> > /* Following tools-only interfaces may change in future. */
>>
>> So there's one problem here, which the comment at the bottom
>> of the context already hints at: This enum is part of the not
>> tools restricted interface (as HVMOP_get_mem_type is usable
>> by guests themselves), which we cannot change like this. Since
>> the meaning of the enumerator value doesn't change, I guess
>> we can get away with simply retaining its old name for non-up-
>> to-date __XEN_INTERFACE_VERSION__.
>>
>
> Has the type made it into a release yet. I was assuming we could make the
> change without any need to play with the version since it's only ever been
> present in xen-unstable so far.
I think you need a Release Manager ack for that; but if it's the case
that the type has never been seen in public, then I think it should be
able to be renamed (in fact, we should rename it so that we don't have
to deal with backwards compatibility later).
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
On Mon, Apr 18, 2016 at 10:10:00AM +0100, George Dunlap wrote:
> On Mon, Apr 18, 2016 at 9:41 AM, Paul Durrant wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 08 April 2016 22:48
> >> To: xen-devel@lists.xen.org
> >> Cc: Andrew Cooper; Paul Durrant; George Dunlap; Jun Nakajima; Kevin Tian;
> >> zhiyuan...@intel.com; Yu Zhang; Keir (Xen.org); Tim (Xen.org)
> >> Subject: Re: [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm
> >> to p2m_ioreq_server
> >>
> >> >>> On 31.03.16 at 12:53, wrote:
> >> > --- a/xen/include/public/hvm/hvm_op.h
> >> > +++ b/xen/include/public/hvm/hvm_op.h
> >> > @@ -83,7 +83,7 @@ typedef enum {
> >> > HVMMEM_ram_rw, /* Normal read/write guest RAM */
> >> > HVMMEM_ram_ro, /* Read-only; writes are discarded */
> >> > HVMMEM_mmio_dm,/* Reads and write go to the device model
> >> */
> >> > -HVMMEM_mmio_write_dm /* Read-only; writes go to the device
> >> model */
> >> > +HVMMEM_ioreq_server,
> >> > } hvmmem_type_t;
> >> >
> >> > /* Following tools-only interfaces may change in future. */
> >>
> >> So there's one problem here, which the comment at the bottom
> >> of the context already hints at: This enum is part of the not
> >> tools restricted interface (as HVMOP_get_mem_type is usable
> >> by guests themselves), which we cannot change like this. Since
> >> the meaning of the enumerator value doesn't change, I guess
> >> we can get away with simply retaining its old name for non-up-
> >> to-date __XEN_INTERFACE_VERSION__.
> >>
> >
> > Has the type made it into a release yet. I was assuming we could make the
> > change without any need to play with the version since it's only ever been
> > present in xen-unstable so far.
>
> I think you need a Release Manager ack for that; but if it's the case
> that the type has never been seen in public, then I think it should be
> able to be renamed (in fact, we should rename it so that we don't have
> to deal with backwards compatibility later).
>
If it is not released yet, feel free to change it -- but at this point
you also need to present argument on why it should be changed. I don't
expect the seddery too hard to review.
Wei.
> -George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [for-4.7] xen/arm: Force broadcast of TLB and instruction cache maintenance instructions
UP guest usually uses TLB instruction to flush only on the local CPU. The TLB flush won't be broadcasted across all the CPUs within the same innershareable domain. When the vCPU is migrated between different CPUs, it may be rescheduled to a previous CPU where the TLB has not been flushed. The TLB may contain stale entries which will result to translate incorrectly a VA to IPA or even cause TLB conflicts. To avoid a such situation, always set HCR_EL2.FB which will force the broadcast of TLB and instruction cache maintenance instructions. Cheers, Signed-off-by: Julien Grall --- This is a bug fix for Xen 4.7 and should be backported up to Xen 4.4 (first official release for ARM). Without this patch, UP guest will crash if it gets migrated on a physical CPU with stale TLBs for this guest. --- xen/arch/arm/traps.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 5e865cf..9926a57 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -124,7 +124,8 @@ void init_traps(void) /* Setup hypervisor traps */ WRITE_SYSREG(HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM| - HCR_TWE|HCR_TWI|HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP, HCR_EL2); + HCR_TWE|HCR_TWI|HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB, + HCR_EL2); isb(); } -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 18 April 2016 10:15
> To: George Dunlap
> Cc: Paul Durrant; Jan Beulich; xen-devel@lists.xen.org; Kevin Tian; Keir
> (Xen.org); Andrew Cooper; Tim (Xen.org); Yu Zhang; zhiyuan...@intel.com;
> Jun Nakajima; Wei Liu
> Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename
> p2m_mmio_write_dm to p2m_ioreq_server
>
> On Mon, Apr 18, 2016 at 10:10:00AM +0100, George Dunlap wrote:
> > On Mon, Apr 18, 2016 at 9:41 AM, Paul Durrant
> wrote:
> > >> -Original Message-
> > >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> Sent: 08 April 2016 22:48
> > >> To: xen-devel@lists.xen.org
> > >> Cc: Andrew Cooper; Paul Durrant; George Dunlap; Jun Nakajima; Kevin
> Tian;
> > >> zhiyuan...@intel.com; Yu Zhang; Keir (Xen.org); Tim (Xen.org)
> > >> Subject: Re: [PATCH v2 2/3] x86/ioreq server: Rename
> p2m_mmio_write_dm
> > >> to p2m_ioreq_server
> > >>
> > >> >>> On 31.03.16 at 12:53, wrote:
> > >> > --- a/xen/include/public/hvm/hvm_op.h
> > >> > +++ b/xen/include/public/hvm/hvm_op.h
> > >> > @@ -83,7 +83,7 @@ typedef enum {
> > >> > HVMMEM_ram_rw, /* Normal read/write guest RAM */
> > >> > HVMMEM_ram_ro, /* Read-only; writes are discarded */
> > >> > HVMMEM_mmio_dm,/* Reads and write go to the device
> model
> > >> */
> > >> > -HVMMEM_mmio_write_dm /* Read-only; writes go to the
> device
> > >> model */
> > >> > +HVMMEM_ioreq_server,
> > >> > } hvmmem_type_t;
> > >> >
> > >> > /* Following tools-only interfaces may change in future. */
> > >>
> > >> So there's one problem here, which the comment at the bottom
> > >> of the context already hints at: This enum is part of the not
> > >> tools restricted interface (as HVMOP_get_mem_type is usable
> > >> by guests themselves), which we cannot change like this. Since
> > >> the meaning of the enumerator value doesn't change, I guess
> > >> we can get away with simply retaining its old name for non-up-
> > >> to-date __XEN_INTERFACE_VERSION__.
> > >>
> > >
> > > Has the type made it into a release yet. I was assuming we could make
> the change without any need to play with the version since it's only ever
> been present in xen-unstable so far.
> >
> > I think you need a Release Manager ack for that; but if it's the case
> > that the type has never been seen in public, then I think it should be
> > able to be renamed (in fact, we should rename it so that we don't have
> > to deal with backwards compatibility later).
> >
>
> If it is not released yet, feel free to change it -- but at this point
> you also need to present argument on why it should be changed. I don't
> expect the seddery too hard to review.
>
There was a design doc posted to the list a couple of months back which has the
justification. See
http://lists.xen.org/archives/html/xen-devel/2016-02/msg03770.html
Paul
> Wei.
>
> > -George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 91846: tolerable FAIL
flight 91846 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/91846/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 91745 build-i386-rumpuserxen6 xen-buildfail like 91745 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 91745 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 91745 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 91745 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 91745 test-amd64-amd64-xl-rtds 9 debian-install fail like 91745 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 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-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail 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-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-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-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail 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-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass version targeted for testing: xen f3a7ca02400d1c416e97451b4aebfaf608fc8192 baseline version: xen f3a7ca02400d1c416e97451b4aebfaf608fc8192 Last test of basis91846 2016-04-18 02:07:15 Z0 days Testing same since0 1970-01-01 00:00:00 Z 16909 days0 attempts jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops
[Xen-devel] [Hackathon 16] Notes from Security Session
Hi all, I took notes as much as I could. CC'ed the people who participated most. If I missed/misrepresented something, please add to the discussion. I know that George for example took some extra notes in the one or other area. Regards Lars == Topics discussed == QEMU De-privilige of QEMU XSA x-Splice x86 Emulator Enabling XSM By default === Slimline QEMU === Konrad: Some inroads on making QEMU better Konrad: QEMU is too big and it is hard to strip down the platform : how can we chop it up Wei: Wei attempted this 2 years ago : Wei defined some Xen stub CPU model, which was rejected at the time Stefano: Maybe what we need is different Stefano: Containers / Intel have similar issues Stefano: Intel have a very similar problem with ClearContainer Stefano: Re-implementing ClearContainers with QEMU because of market needs Stefano: QEMU does have already a no-default option Doug: In the QEMU model: you cannot run a board without a CPU Doug: KConfig may be acceptable, but re4moving boards may not (initially discussed with Antony L) George: Distros don't want to ship two versions of QEMU George: Compile configurability doesn't help with distros Konrad: PVH/HVMLite does not use QEMU (or only as a back) Lars: If we had a proposal, working with Intel and the QEMU community, we could discuss at Xen Summit / KVM Forum is co-located James: If we had a future with OVMF, then we probably wouldn't need QEMU (aka if you want security use PVH with OVMF) James: Proposal for security conscious applications we could fork and use a stubbed out version of QEMU Options: - KConfig - Run-time disablement - Xen Summit / KVM Forum - Intel work / collaboration - PIX3 > 935 - OVMF - Remove xl.cfg (stop configs - in fact we probably only can print a warning "this is not secure and has no security support" or something similar) Doug: Issue - For example Oracle could deal with Config - BUT, this approach won't work for distros ACTION: Konrad is volunteering to drive this discussion === De-privilige Qemu === Konrad: What's the status Stefano: not done, you need - QEMU as non-root (that is in 4.7 and QEMU part is there) - Now you still have a libxc and xenstore interface that needs to be de-priviliged - There is a patch for QEMI and xenstore to deal with the libxc part (not upstreamed) ... pretty big series, but won't make it for 4.7 - QEMU part is tiny - Libxc is sizeable (Ian Campbell was working on it), but it is now dormant : QEMU support is there, but Dom0 interface is missing - Ideas: Do registration in Dom0 [George has some additional notes] ISSUE: A proposal and a plan, but nobody to do this. Without this what we have is not useful Andrew: XenServer still using qemu-trad because of some gaps in emu-upstream Andrew: XS may end up working on this at some undefined point in the future There is a problem with using CD drive's to open ISOs as you need to be privileged to do this Andy Cooper: there may be real end-user issues Stefano: Could change ownership Doug: Issue was tried to be fixed in libvirt and went nowhere Andy: Qemu-trad does it wrong (QEMU in libxenlight does not do that) ACTION: High;right lack of owner Konrad: Seccomp may work Doug: everything has to be passed as file descriptor === Narrower XSA Coverage === Jan: XSA 77 (whitelisted a set of dom control and sys control) which are supposedly ... http://xenbits.xen.org/xsa/advisory-77.html See http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt (Security Status of dom0 disaggregation) Jan: Who runs this in production: running part of toolstack not in Dom0 - OpenXT wants to do this Jan: The observation is that we went to far with the XSA 77 => if we had a shorter whitelist, and reduce whitelist Jan: If there was agreement, then the security team would not handle issues in these areas as XSA's Ross Phillipson: Typic ally we have only higher level stuff in a different xl, but lower level stuff runs on Dom0. So there should be no issue George: QEMU stub domains should have security support George: There are a whole set of other things, which we don't know whether they are used George: Do we want to security support of disaggregated tools-stub Agreed: Propose patch to change http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt on the list Jan: We can only discuss in public if no issues are pending Cc: Christopher Clark , Ross Philipson , Daniel Smith CC the folks on this thread or ope...@googlegroups.com (OpenXT mailing list) === x86 Emulation de-privilige === Anthony is working on it Stefano: I think you had some measurements Anthony: Measurements were not very good Andrew: If you are introspecting, you sacrifice 70% performance Andrew: Patches were very complicated Andrew: Re-writing the emulator would only fix the outbound path Stefano: Risk would probably go from High/Critical to Low in terms of impact but not remove the issues Jan: The issue is really with in-guest security issues Doug: Could we look
Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation
On 04/14/2016 07:08 PM, Jan Beulich wrote:
Razvan Cojocaru 04/14/16 5:45 PM >>>
>> On 04/14/2016 06:40 PM, Jan Beulich wrote:
>>> To be honest, just having remembered that we do the write back for locked
>>> instructions using CMPXCHG, I'd first of all like to see a proper
>>> description
>>> of "the _whole_ issue".
>>
>> I believe at least part of the issue has to do with the comment on line
>> 1013 from xen/arch/x86/hvm/emulate.c:
>>
> >994 static int hvmemul_cmpxchg(
> >995 enum x86_segment seg,
> >996 unsigned long offset,
> >997 void *p_old,
> >998 void *p_new,
> >999 unsigned int bytes,
>> 1000 struct x86_emulate_ctxt *ctxt)
>> 1001 {
>> 1002 struct hvm_emulate_ctxt *hvmemul_ctxt =
>> 1003 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>> 1004
>> 1005 if ( unlikely(hvmemul_ctxt->set_context) )
>> 1006 {
>> 1007 int rc = set_context_data(p_new, bytes);
>> 1008
>> 1009 if ( rc != X86EMUL_OKAY )
>> 1010 return rc;
>> 1011 }
>> 1012
>> 1013 /* Fix this in case the guest is really relying on r-m-w atomicity.
>> */
>> 1014 return hvmemul_write(seg, offset, p_new, bytes, ctxt);
>> 1015 }
>
> Ah, so _that's_ where the problem wants to be fixed then (leaving - afaict -
> PV emulation paths completely unaffected).
That's what I had hoped too, an early version of this patch simply used
a spinlock that locked / unlock on entry / exit of hvmemul_cmpxchg().
Even with this patch, I've just tried it again with all ops->smp_lock()
/ ops->smp_unlock() calls commented out in x86_emulate(), and
hvmemul_cmpxchg() modified as follows:
994 static int hvmemul_cmpxchg(
995 enum x86_segment seg,
996 unsigned long offset,
997 void *p_old,
998 void *p_new,
999 unsigned int bytes,
1000 struct x86_emulate_ctxt *ctxt)
1001 {
1002 struct hvm_emulate_ctxt *hvmemul_ctxt =
1003 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
1004 int rc;
1005
1006 emulate_smp_lock(1);
1007
1008 if ( unlikely(hvmemul_ctxt->set_context) )
1009 {
1010 int rc = set_context_data(p_new, bytes);
1011
1012 if ( rc != X86EMUL_OKAY )
1013 return rc;
1014 }
1015
1016 /* Fix this in case the guest is really relying on r-m-w
atomicity. */
1017 rc = hvmemul_write(seg, offset, p_new, bytes, ctxt);
1018
1019 emulate_smp_unlock(1);
1020
1021 return rc;
1022 }
Unfortunately, with just this the guest still hangs, while with read and
write locking in x86_emulate() it does not.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xenfb: Fix overzealous ring test
From: Wei Liu
pv-grub booting got broken with recent qemu-xen, due to
ac0487e1d2ae811cd4d035741a109a4ecfb013f1 ('xenfb.c: avoid expensive loops
when prod <= out_cons')
prod - out_cons can actually be XENFB_OUT_RING_LEN when the ring is exactly
full, this is a normal condition and should not be excluded.
From: Wei Liu
Signed-off-by: Samuel Thibault
Tested-by: Hao Xudong
---
hw/display/xenfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 40b096a..9866dfd 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -775,7 +775,7 @@ static void xenfb_handle_events(struct XenFB *xenfb)
prod = page->out_prod;
out_cons = page->out_cons;
-if (prod - out_cons >= XENFB_OUT_RING_LEN) {
+if (prod - out_cons > XENFB_OUT_RING_LEN) {
return;
}
xen_rmb(); /* ensure we see ring contents up to prod */
--
2.8.0.rc3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 91861: regressions - FAIL
flight 91861 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/91861/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 60684 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 60684 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail REGR. vs. 60684 test-amd64-amd64-xl 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 60684 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail REGR. vs. 60684 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 60684 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. vs. 60684 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 14 guest-saverestore fail REGR. vs. 60684 test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 60684 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 60684 test-amd64-i386-xl-xsm 15 guest-localmigrate fail blocked in 60684 test-amd64-i386-xl 15 guest-localmigrate fail blocked in 60684 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail blocked in 60684 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 60684 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 60684 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 60684 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 60684 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-i386-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-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: linux58e08ffd18efad0815cd563e83197125ef5857b1 baseline version: linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0 Last test of basis60684 2015-08-13 04:21:46 Z 249 days Failing since 60712 2015-08-15 18:33:48 Z 246 days 188 attempts Testing same since91861 2016-04-18 04:24:28 Z0 days1 attempts 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 build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm fail test-amd64-i386-libvirt-
[Xen-devel] [ovmf test] 91887: regressions - FAIL
flight 91887 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91887/ 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. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf a8c39ba2986c1ffb1dab864cefedc86402a9695c baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 132 days Failing since 65593 2015-12-08 23:44:51 Z 131 days 153 attempts Testing same since91887 2016-04-18 09:18:52 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19638 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 173 (CVE-2016-3960) - x86 shadow pagetables: address width overflow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-3960 / XSA-173
version 3
x86 shadow pagetables: address width overflow
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
In the x86 shadow pagetable code, the guest frame number of a
superpage mapping is stored in a 32-bit field. If a shadowed guest
can cause a superpage mapping of a guest-physical address at or above
2^44 to be shadowed, the top bits of the address will be lost, causing
an assertion failure or NULL dereference later on, in code that
removes the shadow.
IMPACT
==
A HVM guest using shadow pagetables can cause the host to crash.
A PV guest using shadow pagetables (i.e. being migrated) with PV
superpages enabled (which is not the default) can crash the host, or
corrupt hypervisor memory, and so a privilege escalation cannot be
ruled out.
VULNERABLE SYSTEMS
==
Xen versions from 3.4 onwards are affected.
Only x86 variants of Xen are susceptible. ARM variants are not
affected.
HVM guests using shadow mode paging can expose this vulnerability. HVM
guests using Hardware Assisted Paging (HAP) are unaffected.
Systems running PV guests with PV superpages enabled are vulnerable if
those guests undergo live migration. PV superpages are disabled by
default, so systems are not vulnerable in this way unless
"allowsuperpage" is on the Xen command line.
To discover whether your HVM guests are using HAP, or shadow page
tables: request debug key `q' (from the Xen console, or with
`xl debug-keys q'). This will print (to the console, and visible in
`xl dmesg'), debug information for every domain, containing something
like this:
(XEN) General information for domain 2:
(XEN) refcnt=1 dying=2 pause_count=2
(XEN) nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0
dirty_cpus={} max_pages=262400
(XEN) handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=
(XEN) paging assistance: hap refcounts translate external
^^^
The presence of `hap' here indicates that the host is not
vulnerable to this domain. For an HVM domain the presence of `shadow'
indicates that the domain can exploit the vulnerability.
MITIGATION
==
Running only PV guests will avoid this vulnerability, unless PV
superpage support is enabled (see above).
Running HVM guests with Hardware Assisted Paging (HAP) enabled will
also avoid this vulnerability. This is the default mode on hardware
supporting HAP, but can be overridden by hypervisor command line
option and guest configuration setting. Such overrides ("hap=0" in
either case, with variants like "no-hap" being possible in the
hypervisor command line case) would need to be removed to avoid this
vulnerability.
CREDITS
===
This issue was discovered by Ling Liu and Yihan Lian of the Cloud
Security Team, Qihoo 360.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa173-unstable.patch xen-unstable
xsa173-4.6.patch Xen 4.6.x
xsa173-4.5.patch Xen 4.5.x
xsa173-4.4.patch Xen 4.4.x
xsa173-4.3.patch Xen 4.3.x
$ sha256sum xsa173*
bd4619334351afc9f71bb529e8ac102c63415bb4d13197e3bd24a58de03726cb
xsa173-unstable.patch
089c07f0c8237da674796f155ee7e3c0305efd11a59df30ef2c3d5f6b423bfea
xsa173-4.3.patch
35e02b8d4c2841ad951dd967b4f11aa7911fe5d52be2cb605b174e8c2e9214ca
xsa173-4.4.patch
8cd255416975b5589b85911142b385cc1ed78b8ea5e16ebe9d6c60e2679b23aa
xsa173-4.5.patch
6dbc34e3e2d4415967c4406e0f8392a9395bff74da115ae20f26bd112b19017c
xsa173-4.6.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJXFOGhAAoJEIP+FMlX6CvZXUYH/A1ekMpU71/JUK1c53qHmaTY
ZCsJj5hArL9poTYss/AfyumZRATalPrbX/Wt6JaVMutMefgPjphP8OKTzywr/aDJ
vRIim4piOABS15cWtYlfTans6X4yyk1NxmMt182osRW1JSW+OrjXORs6719zoEL7
3hzuf7g6pYiaVqtUmLEx9/U3T246ZaQ98V93YVxGGUyUYRBmFJxEAtA2yf4SlqNX
G3XNDc4DZpXnp8yABFEu+atfWef/Mn/gbN
[Xen-devel] [PATCH v2 00/11] Check VT-d Device-TLB flush error
This patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'.
While IOMMU Device-TLB flush timed out, xen calls panic() at present. However
the existing panic()
is going to be eliminated, so we must propagate the IOMMU Device-TLB flush
error up to the call trees.
This patch set is also based on the discussion of 'abstract model of IOMMU
unmaping/mapping failures'
In this version, I try that splitting things is to go function by function, top
level ones first,
and leaf ones last, one function per patch (maybe pairs of functions, as in the
map/unmap case).
Quan Xu (11):
vt-d: fix the IOMMU flush issue
IOMMU: handle IOMMU mapping and unmapping failures
IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
grant_table: avoid unnecessary work during grant table unmapping
vt-d: propagate IOMMU Device-TLB flush error up to IOMMU unmapping.
vt-d: propagate IOMMU Device-TLB flush error up to IOMMU mapping.
IOMMU/MMU: propagate IOMMU Device-TLB flush error up to
iommu_iotlb_flush{,_all} (top level ones).
IOMMU: propagate IOMMU Device-TLB flush error up to
iommu_iotlb_flush{,_all} (leaf ones).
IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending
vt-d: propagate IOMMU Device-TLB flush error up to vt-d hardware
initialization
vt-d: propagate error up to ME phantom function mapping and unmapping
xen/arch/arm/p2m.c| 5 +-
xen/arch/x86/acpi/power.c | 14 ++-
xen/arch/x86/mm.c | 13 ++-
xen/arch/x86/mm/p2m-ept.c | 25 -
xen/arch/x86/mm/p2m-pt.c | 22 +++-
xen/arch/x86/mm/p2m.c | 11 +-
xen/common/grant_table.c | 10 +-
xen/common/memory.c | 5 +-
xen/drivers/passthrough/amd/iommu_init.c | 9 +-
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +-
xen/drivers/passthrough/arm/smmu.c| 10 +-
xen/drivers/passthrough/iommu.c | 49 +++--
xen/drivers/passthrough/vtd/extern.h | 2 +-
xen/drivers/passthrough/vtd/iommu.c | 140 +-
xen/drivers/passthrough/vtd/quirks.c | 26 +++--
xen/drivers/passthrough/x86/iommu.c | 5 +-
xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 +-
xen/include/asm-x86/iommu.h | 2 +-
xen/include/xen/iommu.h | 12 +--
19 files changed, 256 insertions(+), 108 deletions(-)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 06/11] vt-d: propagate IOMMU Device-TLB flush error up to IOMMU mapping.
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to IOMMU mapping.
Signed-off-by: Quan Xu
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
---
xen/drivers/passthrough/vtd/iommu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 580a9cf..5cc70ca 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1720,6 +1720,7 @@ static int intel_iommu_map_page(
struct hvm_iommu *hd = domain_hvm_iommu(d);
struct dma_pte *page = NULL, *pte = NULL, old, new = { 0 };
u64 pg_maddr;
+int rc = 0;
/* Do nothing if VT-d shares EPT page table */
if ( iommu_use_hap_pt(d) )
@@ -1762,9 +1763,9 @@ static int intel_iommu_map_page(
unmap_vtd_domain_page(page);
if ( !this_cpu(iommu_dont_flush_iotlb) )
-iommu_flush_iotlb(d, gfn, dma_pte_present(old), 1);
+rc = iommu_flush_iotlb(d, gfn, dma_pte_present(old), 1);
-return 0;
+return rc;
}
static int intel_iommu_unmap_page(struct domain *d, unsigned long gfn)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 01/11] vt-d: fix the IOMMU flush issue
The propagation value from IOMMU flush interfaces may be positive, which
indicates callers need to flush cache, not one of faliures.
when the propagation value is positive, this patch fixes this flush issue
as follows:
- call iommu_flush_write_buffer() to flush cache.
- return zero.
Signed-off-by: Quan Xu
CC: Kevin Tian
CC: Feng Wu
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/drivers/passthrough/vtd/iommu.c | 94 -
xen/include/asm-x86/iommu.h | 2 +-
2 files changed, 63 insertions(+), 33 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 5ad25dc..50d98ac 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -558,14 +558,16 @@ static void iommu_flush_all(void)
}
}
-static void __intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
-int dma_old_pte_present, unsigned int page_count)
+static int iommu_flush_iotlb(struct domain *d, unsigned long gfn,
+ int dma_old_pte_present,
+ unsigned int page_count)
{
struct hvm_iommu *hd = domain_hvm_iommu(d);
struct acpi_drhd_unit *drhd;
struct iommu *iommu;
int flush_dev_iotlb;
int iommu_domid;
+int rc = 0;
/*
* No need pcideves_lock here because we have flush
@@ -584,29 +586,34 @@ static void __intel_iommu_iotlb_flush(struct domain *d,
unsigned long gfn,
continue;
if ( page_count != 1 || gfn == INVALID_GFN )
-{
-if ( iommu_flush_iotlb_dsi(iommu, iommu_domid,
-0, flush_dev_iotlb) )
-iommu_flush_write_buffer(iommu);
-}
+rc = iommu_flush_iotlb_dsi(iommu, iommu_domid,
+ 0, flush_dev_iotlb);
else
+rc = iommu_flush_iotlb_psi(iommu, iommu_domid,
+ (paddr_t)gfn << PAGE_SHIFT_4K,
+ PAGE_ORDER_4K,
+ !dma_old_pte_present,
+ flush_dev_iotlb);
+
+if ( rc > 0 )
{
-if ( iommu_flush_iotlb_psi(iommu, iommu_domid,
-(paddr_t)gfn << PAGE_SHIFT_4K, PAGE_ORDER_4K,
-!dma_old_pte_present, flush_dev_iotlb) )
-iommu_flush_write_buffer(iommu);
-}
+iommu_flush_write_buffer(iommu);
+rc = 0;
+} else if ( rc < 0 )
+break;
}
+
+return rc;
}
static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
unsigned int page_count)
{
-__intel_iommu_iotlb_flush(d, gfn, 1, page_count);
+iommu_flush_iotlb(d, gfn, 1, page_count);
}
static void intel_iommu_iotlb_flush_all(struct domain *d)
{
-__intel_iommu_iotlb_flush(d, INVALID_GFN, 0, 0);
+iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
}
/* clear one page's page table */
@@ -640,7 +647,7 @@ static void dma_pte_clear_one(struct domain *domain, u64
addr)
iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
if ( !this_cpu(iommu_dont_flush_iotlb) )
-__intel_iommu_iotlb_flush(domain, addr >> PAGE_SHIFT_4K, 1, 1);
+iommu_flush_iotlb(domain, addr >> PAGE_SHIFT_4K, 1, 1);
unmap_vtd_domain_page(page);
}
@@ -1281,6 +1288,7 @@ int domain_context_mapping_one(
u64 maddr, pgd_maddr;
u16 seg = iommu->intel->drhd->segment;
int agaw;
+int rc;
ASSERT(pcidevs_locked());
spin_lock(&iommu->lock);
@@ -1394,13 +1402,19 @@ int domain_context_mapping_one(
spin_unlock(&iommu->lock);
/* Context entry was previously non-present (with domid 0). */
-if ( iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
-DMA_CCMD_MASK_NOBIT, 1) )
-iommu_flush_write_buffer(iommu);
-else
+rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
+DMA_CCMD_MASK_NOBIT, 1);
+
+if ( !rc )
{
int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
-iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
+rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
+}
+
+if ( rc > 0 )
+{
+iommu_flush_write_buffer(iommu);
+rc = 0;
}
set_bit(iommu->index, &hd->arch.iommu_bitmap);
@@ -1410,7 +1424,7 @@ int domain_context_mapping_one(
if ( !seg )
me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
-return 0;
+return rc;
}
static int domain_context_mapping(
@@ -1505,6 +1519,7 @@ int domain_context_unmap_one(
struct context_entry *context, *context_entries;
u64 maddr;
int iommu_domid;
+int rc;
ASSERT(pcidevs_locked());
spin_lock(&iommu->lock);
@@ -1532,14 +1547,20 @@ int domain_context_unmap_one(
return -EI
[Xen-devel] [PATCH v2 03/11] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
If IOMMU mapping and unmapping failed, the domain (with the exception of
the hardware domain) is crashed, treated as a fatal error. Rollback can
be lighter weight.
For the hardware domain, we do things on a best effort basis. When rollback
is not feasible (in early initialization phase or trade-off of complexity),
at least, unmap upon maps error or then throw out error message.
IOMMU unmapping should perhaps continue despite an error, in an attempt to
do best effort cleanup.
Signed-off-by: Quan Xu
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
CC: Jun Nakajima
CC: Kevin Tian
CC: George Dunlap
---
xen/arch/x86/mm.c | 13 -
xen/arch/x86/mm/p2m-ept.c | 25 ++---
xen/arch/x86/mm/p2m-pt.c| 22 ++
xen/arch/x86/mm/p2m.c | 11 +--
xen/drivers/passthrough/iommu.c | 14 +-
5 files changed, 70 insertions(+), 15 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c997b53..5c4fb58 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info *page,
unsigned long type,
int preemptible)
{
unsigned long nx, x, y = page->u.inuse.type_info;
-int rc = 0;
+int rc = 0, ret = 0;
ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
@@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info *page,
unsigned long type,
if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
{
if ( (x & PGT_type_mask) == PGT_writable_page )
-iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
+ret = iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
else if ( type == PGT_writable_page )
-iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
- page_to_mfn(page),
- IOMMUF_readable|IOMMUF_writable);
+ret = iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
+ page_to_mfn(page),
+ IOMMUF_readable|IOMMUF_writable);
}
}
@@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info *page,
unsigned long type,
if ( (x & PGT_partial) && !(nx & PGT_partial) )
put_page(page);
+if ( unlikely(ret) )
+rc = ret;
+
return rc;
}
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 3cb6868..22c8d17 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -665,7 +665,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn,
mfn_t mfn,
ept_entry_t *table, *ept_entry = NULL;
unsigned long gfn_remainder = gfn;
unsigned int i, target = order / EPT_TABLE_ORDER;
-int ret, rc = 0;
+int ret, err = 0, rc = 0;
bool_t direct_mmio = (p2mt == p2m_mmio_direct);
uint8_t ipat = 0;
bool_t need_modify_vtd_table = 1;
@@ -830,10 +830,26 @@ out:
{
if ( iommu_flags )
for ( i = 0; i < (1 << order); i++ )
-iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
+{
+ret = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
iommu_flags);
+
+if ( unlikely(ret) )
+{
+while (i)
+iommu_unmap_page(d, gfn + --i);
+
+err = ret;
+break;
+}
+}
else
for ( i = 0; i < (1 << order); i++ )
-iommu_unmap_page(d, gfn + i);
+{
+ret = iommu_unmap_page(d, gfn + i);
+
+if ( unlikely(ret) )
+err = ret;
+}
}
}
@@ -849,6 +865,9 @@ out:
if ( rc == 0 && p2m_is_hostp2m(p2m) )
p2m_altp2m_propagate_change(d, _gfn(gfn), mfn, order, p2mt, p2ma);
+if ( unlikely(err) )
+rc = err;
+
return rc;
}
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 3d80612..db4257a 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -498,7 +498,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long gfn,
mfn_t mfn,
l1_pgentry_t intermediate_entry = l1e_empty();
l2_pgentry_t l2e_content;
l3_pgentry_t l3e_content;
-int rc;
+int rc, ret;
unsigned int iommu_pte_flags = p2m_get_iommu_flags(p2mt);
/*
* old_mfn and iommu_old_flags control possible flush/update needs on the
@@ -680,11 +680,25 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long
gfn, mfn_t mfn,
}
else if ( iommu_pte_flags )
for ( i = 0; i < (1UL << page_order); i++ )
-iommu_map_page(p2m->domain, gfn + i, mfn_x(mfn) + i,
- iommu_pte_fla
[Xen-devel] [PATCH v2 04/11] grant_table: avoid unnecessary work during grant table unmapping
While grant table is unmapping, the domain (with the exception of the hardware domain) may be crashed due to IOMMU mapping and unmapping failures, and then it is unnecessary to flush specified CPUs' TLBs. Signed-off-by: Quan Xu CC: Ian Jackson CC: Jan Beulich CC: Keir Fraser CC: Tim Deegan --- xen/common/grant_table.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c index 8b22299..1801fe9 100644 --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -1366,8 +1366,9 @@ gnttab_unmap_grant_ref( return 0; -fault: -gnttab_flush_tlb(current->domain); + fault: +if ( current->domain->is_shut_down ) +gnttab_flush_tlb(current->domain); for ( i = 0; i < partial_done; i++ ) __gnttab_unmap_common_complete(&(common[i])); @@ -1429,8 +1430,9 @@ gnttab_unmap_and_replace( return 0; -fault: -gnttab_flush_tlb(current->domain); + fault: +if ( current->domain->is_shut_down ) +gnttab_flush_tlb(current->domain); for ( i = 0; i < partial_done; i++ ) __gnttab_unmap_common_complete(&(common[i])); -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 08/11] IOMMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (leaf ones).
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
If IOMMU mapping and unmapping failed, the domain (with the exception of
the hardware domain) is crashed, treated as a fatal error. Rollback can
be lighter weight.
This patch fixes the leaf ones.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/iommu.c | 8 ++--
xen/drivers/passthrough/vtd/iommu.c | 8
xen/include/xen/iommu.h | 4 ++--
3 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 9254760..d44fc39 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -308,9 +308,7 @@ int iommu_iotlb_flush(struct domain *d, unsigned long gfn,
unsigned int page_cou
if ( !iommu_enabled || !hd->platform_ops || !hd->platform_ops->iotlb_flush
)
return 0;
-hd->platform_ops->iotlb_flush(d, gfn, page_count);
-
-return 0;
+return hd->platform_ops->iotlb_flush(d, gfn, page_count);
}
int iommu_iotlb_flush_all(struct domain *d)
@@ -320,9 +318,7 @@ int iommu_iotlb_flush_all(struct domain *d)
if ( !iommu_enabled || !hd->platform_ops ||
!hd->platform_ops->iotlb_flush_all )
return 0;
-hd->platform_ops->iotlb_flush_all(d);
-
-return 0;
+return hd->platform_ops->iotlb_flush_all(d);
}
int __init iommu_setup(void)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 5cc70ca..930661a 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -606,14 +606,14 @@ static int iommu_flush_iotlb(struct domain *d, unsigned
long gfn,
return rc;
}
-static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
unsigned int page_count)
+static int intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
unsigned int page_count)
{
-iommu_flush_iotlb(d, gfn, 1, page_count);
+return iommu_flush_iotlb(d, gfn, 1, page_count);
}
-static void intel_iommu_iotlb_flush_all(struct domain *d)
+static int intel_iommu_iotlb_flush_all(struct domain *d)
{
-iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
+return iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
}
/* clear one page's page table */
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index ff4608d..ca1c409 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -161,8 +161,8 @@ struct iommu_ops {
void (*resume)(void);
void (*share_p2m)(struct domain *d);
void (*crash_shutdown)(void);
-void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int
page_count);
-void (*iotlb_flush_all)(struct domain *d);
+int (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int
page_count);
+int (*iotlb_flush_all)(struct domain *d);
int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
void (*dump_p2m_table)(struct domain *d);
};
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 02/11] IOMMU: handle IOMMU mapping and unmapping failures
Now IOMMU mapping and unmapping failures are treated as a fatal to
the domain (with the exception of the hardware domain).
If IOMMU mapping and unmapping failed, crash the domain (with the
exception of the hardware domain) and propagate the error up to the
call trees.
Signed-off-by: Quan Xu
CC: Jan Beulich
---
xen/drivers/passthrough/iommu.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index b64676f..850101b 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -243,21 +243,33 @@ int iommu_map_page(struct domain *d, unsigned long gfn,
unsigned long mfn,
unsigned int flags)
{
struct hvm_iommu *hd = domain_hvm_iommu(d);
+int rc;
if ( !iommu_enabled || !hd->platform_ops )
return 0;
-return hd->platform_ops->map_page(d, gfn, mfn, flags);
+rc = hd->platform_ops->map_page(d, gfn, mfn, flags);
+
+if ( rc && !is_hardware_domain(d) )
+domain_crash(d);
+
+return rc;
}
int iommu_unmap_page(struct domain *d, unsigned long gfn)
{
struct hvm_iommu *hd = domain_hvm_iommu(d);
+int rc;
if ( !iommu_enabled || !hd->platform_ops )
return 0;
-return hd->platform_ops->unmap_page(d, gfn);
+rc = hd->platform_ops->unmap_page(d, gfn);
+
+if ( rc && !is_hardware_domain(d) )
+domain_crash(d);
+
+return rc;
}
static void iommu_free_pagetables(unsigned long unused)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 10/11] vt-d: propagate IOMMU Device-TLB flush error up to vt-d hardware initialization
While IOMMU Device-TLB flush timed out, xen calls panic() at present. However the existing panic() is going to be eliminated, so we must propagate the IOMMU Device-TLB flush error up to vt-d hardware initialization. Signed-off-by: Quan Xu CC: Jan Beulich CC: Kevin Tian CC: Feng Wu --- xen/drivers/passthrough/vtd/iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c index a821306..223522f 100644 --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -2137,8 +2137,8 @@ static int init_vtd_hw(void) return -EIO; } } -iommu_flush_all(); -return 0; + +return iommu_flush_all(); } static void __hwdom_init setup_hwdom_rmrr(struct domain *d) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 05/11] vt-d: propagate IOMMU Device-TLB flush error up to IOMMU unmapping.
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to IOMMU unmapping.
Signed-off-by: Quan Xu
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
---
xen/drivers/passthrough/vtd/iommu.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 50d98ac..580a9cf 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -617,11 +617,12 @@ static void intel_iommu_iotlb_flush_all(struct domain *d)
}
/* clear one page's page table */
-static void dma_pte_clear_one(struct domain *domain, u64 addr)
+static int dma_pte_clear_one(struct domain *domain, u64 addr)
{
struct hvm_iommu *hd = domain_hvm_iommu(domain);
struct dma_pte *page = NULL, *pte = NULL;
u64 pg_maddr;
+int rc = 0;
spin_lock(&hd->arch.mapping_lock);
/* get last level pte */
@@ -629,7 +630,7 @@ static void dma_pte_clear_one(struct domain *domain, u64
addr)
if ( pg_maddr == 0 )
{
spin_unlock(&hd->arch.mapping_lock);
-return;
+return 0;
}
page = (struct dma_pte *)map_vtd_domain_page(pg_maddr);
@@ -639,7 +640,7 @@ static void dma_pte_clear_one(struct domain *domain, u64
addr)
{
spin_unlock(&hd->arch.mapping_lock);
unmap_vtd_domain_page(page);
-return;
+return 0;
}
dma_clear_pte(*pte);
@@ -647,9 +648,11 @@ static void dma_pte_clear_one(struct domain *domain, u64
addr)
iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
if ( !this_cpu(iommu_dont_flush_iotlb) )
-iommu_flush_iotlb(domain, addr >> PAGE_SHIFT_4K, 1, 1);
+rc = iommu_flush_iotlb(domain, addr >> PAGE_SHIFT_4K, 1, 1);
unmap_vtd_domain_page(page);
+
+return rc;
}
static void iommu_free_pagetable(u64 pt_maddr, int level)
@@ -1770,9 +1773,7 @@ static int intel_iommu_unmap_page(struct domain *d,
unsigned long gfn)
if ( iommu_passthrough && is_hardware_domain(d) )
return 0;
-dma_pte_clear_one(d, (paddr_t)gfn << PAGE_SHIFT_4K);
-
-return 0;
+return dma_pte_clear_one(d, (paddr_t)gfn << PAGE_SHIFT_4K);
}
int iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 09/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to IOMMU suspending.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Liu Jinsong
CC: Keir Fraser
CC: Andrew Cooper
CC: Suravee Suthikulpanit
CC: Stefano Stabellini
CC: Julien Grall
CC: Kevin Tian
CC: Feng Wu
---
xen/arch/x86/acpi/power.c | 14 +-
xen/drivers/passthrough/amd/iommu_init.c | 9 -
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +-
xen/drivers/passthrough/arm/smmu.c| 10 ++
xen/drivers/passthrough/iommu.c | 7 +--
xen/drivers/passthrough/vtd/iommu.c | 22 +-
xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 +-
xen/include/xen/iommu.h | 4 ++--
8 files changed, 53 insertions(+), 17 deletions(-)
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 2885e31..9b87f00 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -45,19 +45,31 @@ void do_suspend_lowlevel(void);
static int device_power_down(void)
{
+int err;
+
console_suspend();
time_suspend();
i8259A_suspend();
-ioapic_suspend();
+err = iommu_suspend();
+if ( err )
+goto iommu_suspend_error;
iommu_suspend();
lapic_suspend();
return 0;
+
+ iommu_suspend_error:
+ioapic_resume();
+i8259A_resume();
+time_resume();
+console_resume();
+
+return err;
}
static void device_power_up(void)
diff --git a/xen/drivers/passthrough/amd/iommu_init.c
b/xen/drivers/passthrough/amd/iommu_init.c
index 4536106..02588aa 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1339,12 +1339,19 @@ static void invalidate_all_devices(void)
iterate_ivrs_mappings(_invalidate_all_devices);
}
-void amd_iommu_suspend(void)
+int amd_iommu_suspend(void)
{
struct amd_iommu *iommu;
for_each_amd_iommu ( iommu )
disable_iommu(iommu);
+
+return 0;
+}
+
+void amd_iommu_crash_shutdown(void)
+{
+amd_iommu_suspend();
}
void amd_iommu_resume(void)
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index c8ee8dc..fb8e816 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -628,6 +628,6 @@ const struct iommu_ops amd_iommu_ops = {
.suspend = amd_iommu_suspend,
.resume = amd_iommu_resume,
.share_p2m = amd_iommu_share_p2m,
-.crash_shutdown = amd_iommu_suspend,
+.crash_shutdown = amd_iommu_crash_shutdown,
.dump_p2m_table = amd_dump_p2m_table,
};
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index 62da087..36c2c83 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2540,7 +2540,7 @@ static int force_stage = 2;
*/
static u32 platform_features = ARM_SMMU_FEAT_COHERENT_WALK;
-static void arm_smmu_iotlb_flush_all(struct domain *d)
+static int arm_smmu_iotlb_flush_all(struct domain *d)
{
struct arm_smmu_xen_domain *smmu_domain =
domain_hvm_iommu(d)->arch.priv;
struct iommu_domain *cfg;
@@ -2557,13 +2557,15 @@ static void arm_smmu_iotlb_flush_all(struct domain *d)
arm_smmu_tlb_inv_context(cfg->priv);
}
spin_unlock(&smmu_domain->lock);
+
+return 0;
}
-static void arm_smmu_iotlb_flush(struct domain *d, unsigned long gfn,
- unsigned int page_count)
+static int arm_smmu_iotlb_flush(struct domain *d, unsigned long gfn,
+unsigned int page_count)
{
/* ARM SMMU v1 doesn't have flush by VMA and VMID */
-arm_smmu_iotlb_flush_all(d);
+return arm_smmu_iotlb_flush_all(d);
}
static struct iommu_domain *arm_smmu_get_domain(struct domain *d,
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index d44fc39..98b934b 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -392,11 +392,14 @@ int iommu_do_domctl(
return ret;
}
-void iommu_suspend()
+int iommu_suspend()
{
const struct iommu_ops *ops = iommu_get_ops();
+
if ( iommu_enabled )
-ops->suspend();
+return ops->suspend();
+
+return 0;
}
void iommu_share_p2m_table(struct domain* d)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 930661a..a821306 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -542,11 +542,12 @@ static int iommu_flush_iotlb_psi(
return status;
}
-static void iommu_flush_all(void)
+static int iommu_flush_all(void)
{
struct acpi_drhd_unit *drhd;
struct iommu *iommu;
int flush_dev_iotlb;
+int rc = 0;
flush_all_cache();
[Xen-devel] [PATCH v2 07/11] IOMMU/MMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (top level ones).
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
If IOMMU mapping and unmapping failed, the domain (with the exception of
the hardware domain) is crashed, treated as a fatal error. Rollback can
be lighter weight.
This patch fixes the top level ones (this patch doesn't fix the leaf
ones but the next patch does).
Signed-off-by: Quan Xu
CC: Stefano Stabellini
CC: Julien Grall
CC: Jan Beulich
---
xen/arch/arm/p2m.c | 5 -
xen/common/memory.c | 5 +++--
xen/drivers/passthrough/iommu.c | 12
xen/drivers/passthrough/x86/iommu.c | 5 +++--
xen/include/xen/iommu.h | 4 ++--
5 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index a2a9c4b..11d2c02 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1177,7 +1177,10 @@ out:
if ( flush )
{
flush_tlb_domain(d);
-iommu_iotlb_flush(d, sgfn, egfn - sgfn);
+ret = iommu_iotlb_flush(d, sgfn, egfn - sgfn);
+
+if ( ret )
+rc = ret;
}
while ( (pg = page_list_remove_head(&free_pages)) )
diff --git a/xen/common/memory.c b/xen/common/memory.c
index c7fca96..965bd51 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -678,8 +678,9 @@ static int xenmem_add_to_physmap(struct domain *d,
if ( need_iommu(d) )
{
this_cpu(iommu_dont_flush_iotlb) = 0;
-iommu_iotlb_flush(d, xatp->idx - done, done);
-iommu_iotlb_flush(d, xatp->gpfn - done, done);
+rc = iommu_iotlb_flush(d, xatp->idx - done, done);
+if ( !rc )
+rc = iommu_iotlb_flush(d, xatp->gpfn - done, done);
}
#endif
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index c351209..9254760 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -301,24 +301,28 @@ static void iommu_free_pagetables(unsigned long unused)
cpumask_cycle(smp_processor_id(),
&cpu_online_map));
}
-void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int
page_count)
+int iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int
page_count)
{
struct hvm_iommu *hd = domain_hvm_iommu(d);
if ( !iommu_enabled || !hd->platform_ops || !hd->platform_ops->iotlb_flush
)
-return;
+return 0;
hd->platform_ops->iotlb_flush(d, gfn, page_count);
+
+return 0;
}
-void iommu_iotlb_flush_all(struct domain *d)
+int iommu_iotlb_flush_all(struct domain *d)
{
struct hvm_iommu *hd = domain_hvm_iommu(d);
if ( !iommu_enabled || !hd->platform_ops ||
!hd->platform_ops->iotlb_flush_all )
-return;
+return 0;
hd->platform_ops->iotlb_flush_all(d);
+
+return 0;
}
int __init iommu_setup(void)
diff --git a/xen/drivers/passthrough/x86/iommu.c
b/xen/drivers/passthrough/x86/iommu.c
index 8cbb655..c2c1ee3 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -104,8 +104,9 @@ int arch_iommu_populate_page_table(struct domain *d)
this_cpu(iommu_dont_flush_iotlb) = 0;
if ( !rc )
-iommu_iotlb_flush_all(d);
-else if ( rc != -ERESTART )
+rc = iommu_iotlb_flush_all(d);
+
+if ( rc && rc != -ERESTART )
iommu_teardown(d);
return rc;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8217cb7..ff4608d 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -182,8 +182,8 @@ int iommu_do_pci_domctl(struct xen_domctl *, struct domain
*d,
int iommu_do_domctl(struct xen_domctl *, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t));
-void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int
page_count);
-void iommu_iotlb_flush_all(struct domain *d);
+int iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int
page_count);
+int iommu_iotlb_flush_all(struct domain *d);
/*
* The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 11/11] vt-d: propagate error up to ME phantom function mapping and unmapping
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to ME phantom function
mapping and unmapping.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/vtd/extern.h | 2 +-
xen/drivers/passthrough/vtd/quirks.c | 26 --
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/extern.h
b/xen/drivers/passthrough/vtd/extern.h
index cbe0286..d4d37c3 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -91,7 +91,7 @@ int is_igd_vt_enabled_quirk(void);
void platform_quirks_init(void);
void vtd_ops_preamble_quirk(struct iommu* iommu);
void vtd_ops_postamble_quirk(struct iommu* iommu);
-void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map);
+int me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map);
void pci_vtd_quirk(const struct pci_dev *);
bool_t platform_supports_intremap(void);
bool_t platform_supports_x2apic(void);
diff --git a/xen/drivers/passthrough/vtd/quirks.c
b/xen/drivers/passthrough/vtd/quirks.c
index 49df41d..c6d9a03 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -332,10 +332,11 @@ void __init platform_quirks_init(void)
* assigning Intel integrated wifi device to a guest.
*/
-static void map_me_phantom_function(struct domain *domain, u32 dev, int map)
+static int map_me_phantom_function(struct domain *domain, u32 dev, int map)
{
struct acpi_drhd_unit *drhd;
struct pci_dev *pdev;
+int rc;
/* find ME VT-d engine base on a real ME device */
pdev = pci_get_pdev(0, 0, PCI_DEVFN(dev, 0));
@@ -343,23 +344,26 @@ static void map_me_phantom_function(struct domain
*domain, u32 dev, int map)
/* map or unmap ME phantom function */
if ( map )
-domain_context_mapping_one(domain, drhd->iommu, 0,
- PCI_DEVFN(dev, 7), NULL);
+rc = domain_context_mapping_one(domain, drhd->iommu, 0,
+PCI_DEVFN(dev, 7), NULL);
else
-domain_context_unmap_one(domain, drhd->iommu, 0,
- PCI_DEVFN(dev, 7));
+rc = domain_context_unmap_one(domain, drhd->iommu, 0,
+ PCI_DEVFN(dev, 7));
+
+return rc;
}
-void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map)
+int me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map)
{
u32 id;
+int rc = 0;
id = pci_conf_read32(0, 0, 0, 0, 0);
if ( IS_CTG(id) )
{
/* quit if ME does not exist */
if ( pci_conf_read32(0, 0, 3, 0, 0) == 0x )
-return;
+return 0;
/* if device is WLAN device, map ME phantom device 0:3.7 */
id = pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0);
@@ -373,7 +377,7 @@ void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn,
int map)
case 0x423b8086:
case 0x423c8086:
case 0x423d8086:
-map_me_phantom_function(domain, 3, map);
+rc = map_me_phantom_function(domain, 3, map);
break;
default:
break;
@@ -383,7 +387,7 @@ void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn,
int map)
{
/* quit if ME does not exist */
if ( pci_conf_read32(0, 0, 22, 0, 0) == 0x )
-return;
+return 0;
/* if device is WLAN device, map ME phantom device 0:22.7 */
id = pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0);
@@ -399,12 +403,14 @@ void me_wifi_quirk(struct domain *domain, u8 bus, u8
devfn, int map)
case 0x42388086:/* Puma Peak */
case 0x422b8086:
case 0x422c8086:
-map_me_phantom_function(domain, 22, map);
+rc = map_me_phantom_function(domain, 22, map);
break;
default:
break;
}
}
+
+return rc;
}
void pci_vtd_quirk(const struct pci_dev *pdev)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 04/14] firmware/makefile: install BIOS blob ...
On 3/14/16 5:55 PM, Anthony PERARD wrote: > ... into the firmware directory, along with hvmloader. > > Signed-off-by: Anthony PERARD > --- > Change in V4: > - remove install of acpi dsdt table > > Change in V3: > - do not check if ROMs file exist before installing, they should exist > - change rules for dsdt_anycpu_qemu_xen.c in oder to generate both .c and > .aml files without changing temporarly the other dsdt_*.c rules. > --- > tools/firmware/Makefile | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile > index 6cc86ce..6a37758 100644 > --- a/tools/firmware/Makefile > +++ b/tools/firmware/Makefile > @@ -19,6 +19,9 @@ SUBDIRS-y += hvmloader > > LD32BIT-$(CONFIG_FreeBSD) := LD32BIT_FLAG=-melf_i386_fbsd > > +SEABIOS_ROM := seabios-dir/out/bios.bin > +OVMF_ROM := ovmf-dir/ovmf.bin > + > ovmf-dir: > GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) > $(OVMF_UPSTREAM_REVISION) ovmf-dir > cp ovmf-makefile ovmf-dir/Makefile; > @@ -45,6 +48,16 @@ endif > install: all > [ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR) > [ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR) > +ifeq ($(CONFIG_SEABIOS),y) > +ifeq ($(SEABIOS_PATH),) > + $(INSTALL_DATA) $(SEABIOS_ROM) $(INST_DIR)/seabios.bin > +endif > +endif > +ifeq ($(CONFIG_OVMF),y) > +ifeq ($(OVMF_PATH),) > + $(INSTALL_DATA) $(OVMF_ROM) $(INST_DIR)/ovmf.bin > +endif > +endif > > .PHONY: clean > clean: subdirs-clean > So I'm going to toss this out there but what if we don't install these at all? We talked about reducing the scope that the Xen Security team had to maintain. What if we just state that SeaBIOS and/or OVMF are dependencies? All the downstream distros don't use the pre-built binaries from Xen and build it themselves. For plain Xen users we just add that to the list of dependencies. I think SeaBIOS and OVMF are a lot more low risk than something like QEMU since they have a very clear target so they're a lot more likely to remain stable. SeaBIOS also has a fairly low level of churn, especially on stable branches. Just a thought. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xenfb: Fix overzealous ring test
On Mon, Apr 18, 2016 at 02:41:48PM +0200, Samuel Thibault wrote:
> From: Wei Liu
>
> pv-grub booting got broken with recent qemu-xen, due to
> ac0487e1d2ae811cd4d035741a109a4ecfb013f1 ('xenfb.c: avoid expensive loops
> when prod <= out_cons')
>
> prod - out_cons can actually be XENFB_OUT_RING_LEN when the ring is exactly
> full, this is a normal condition and should not be excluded.
>
> From: Wei Liu
> Signed-off-by: Samuel Thibault
> Tested-by: Hao Xudong
Hi Samuel,
This patch is already queued by Stefano. After it has been applied
upstream we will backport it to our own tree.
Wei.
> ---
> hw/display/xenfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 40b096a..9866dfd 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -775,7 +775,7 @@ static void xenfb_handle_events(struct XenFB *xenfb)
>
> prod = page->out_prod;
> out_cons = page->out_cons;
> -if (prod - out_cons >= XENFB_OUT_RING_LEN) {
> +if (prod - out_cons > XENFB_OUT_RING_LEN) {
> return;
> }
> xen_rmb(); /* ensure we see ring contents up to prod */
> --
> 2.8.0.rc3
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xenfb: Fix overzealous ring test
Wei Liu, on Mon 18 Apr 2016 15:40:15 +0100, wrote: > This patch is already queued by Stefano. Ah, sorry, I missed it. Samuel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen cpu scheduler internals
i know that in SMP linux kernel, each processor call schdule() function every quantum time. is it the case for xen? if yes,Does it mean that every core invoke it's own schedule() every quantum (using an interrupt), so i don't understand the difference between this and what you said: "you need to arrange for schedule() to be called on several cpus simultaneously (by raising the SCHEDULE softirq)". would you please tell me where is my misunderstanding? Thanks. From: dunl...@gmail.com on behalf of George Dunlap Sent: Monday, April 18, 2016 9:07 AM To: tutu sky Cc: Xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen cpu scheduler internals On Sun, Apr 17, 2016 at 7:18 PM, tutu sky wrote: > Hi, > I know that scheduling is done via two main functions and their effective > interaction: > one 'schedule()' in schedule.c and another 'do_schedule(...)', which is > specific for every scheduling policy. > my question is that (although it may seem clear and very common for kernel > developers, but not as mush for me): > when a vcpu is selected to run on a specific cpu, what is the policy for > choosing cpu (pcpu)? I'm afraid that's not the kind of question that's easy or useful to answer. Your best bet here is to look at the actual code and come back with more specific questions. See also http://wiki.xenproject.org/wiki/Asking_Developer_Questions. If the second question is asking about gang scheduling, you need to arrange for schedule() to be called on several cpus simultaneously (by raising the SCHEDULE softirq), and then you need to arrange for the specific scheduler code on each processor to choose the appropriate cpu. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 91862: regressions - FAIL
flight 91862 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/91862/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10fail REGR. vs. 59254 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate fail REGR. vs. 59254 test-amd64-i386-xl 15 guest-localmigratefail REGR. vs. 59254 test-amd64-i386-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-armhf-armhf-xl-vhd 9 debian-di-install fail baseline untested test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt 14 guest-saverestorefail blocked in 59254 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 59254 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail 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 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pa
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> -Original Message- > From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: 14 April 2016 11:45 > To: George Dunlap; Paul Durrant; xen-devel@lists.xen.org > Cc: Jan Beulich; Kevin Tian; Andrew Cooper; Lv, Zhiyuan; Tim (Xen.org); > jun.nakaj...@intel.com > Subject: Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to > map guest ram with p2m_ioreq_server to an ioreq server > > On 4/11/2016 7:15 PM, Yu, Zhang wrote: > > > > > > On 4/8/2016 7:01 PM, George Dunlap wrote: > >> On 08/04/16 11:10, Yu, Zhang wrote: > >> [snip] > >>> BTW, I noticed your reply has not be CCed to mailing list, and I also > >>> wonder if we should raise this last question in community? > >> > >> Oops -- that was a mistake on my part. :-) I appreciate the > >> discretion; just so you know in the future, if I'm purposely changing > >> the CC list (removing xen-devel and/or adding extra people), I'll almost > >> always say so at the top of the mail. > >> > And then of course there's the p2m_ioreq_server -> > p2m_ram_logdirty > transition -- I assume that live migration is incompatible with this > functionality? Is there anything that prevents a live migration from > being started when there are outstanding p2m_ioreq_server entries? > > >>> > >>> Another good question, and the answer is unfortunately yes. :-) > >>> > >>> If live migration happens during the normal emulation process, entries > >>> marked with p2m_ioreq_server will be changed to p2m_log_dirty in > >>> resolve_misconfig(), and later write operations will change them to > >>> p2m_ram_rw, thereafter these pages can not be forwarded to device > model. > >>> From this point of view, this functionality is incompatible with live > >>> migration. > >>> > >>> But for XenGT, I think this is acceptable, because, if live migration > >>> is to be supported in the future, intervention from backend device > >>> model will be necessary. At that time, we can guarantee from the device > >>> model side that there's no outdated p2m_ioreq_server entries, hence > no > >>> need to reset the p2m type back to p2m_ram_rw(and do not include > >>> p2m_ioreq_server in the P2M_CHANGEABLE_TYPES). By "outdated", I > mean > >>> when an ioreq server is detached from p2m_ioreq_server, or before an > >>> ioreq server is attached to this type, entries marked with > >>> p2m_ioreq_server should be regarded as outdated. > >>> > >>> Is this acceptible to you? Any suggestions? > >> > >> So the question is, as of this series, what happens if someone tries to > >> initiate a live migration while there are outstanding p2m_ioreq_server > >> entries? > >> > >> If the answer is "the ioreq server suddenly loses all control of the > >> memory", that's something that needs to be changed. > >> > > > > Sorry, for this patch series, I'm afraid the above description is the > > answer. > > > > Besides, I find it's hard to change current code to both support the > > deferred resetting of p2m_ioreq_server and the live migration at the > > same time. One reason is that a page with p2m_ioreq_server behaves > > differently in different situations. > > > > My assumption of XenGT is that, for live migration to work, the device > > model should guarantee there's no outstanding p2m_ioreq_server pages > > in hypervisor(no need to use the deferred recalculation), and it is our > > device model who should be responsible for the copying of the write > > protected guest pages later. > > > > And another solution I can think of: when unmapping the ioreq server, > > we walk the p2m table and reset entries with p2m_ioreq_server back > > directly, instead of deferring the reset. And of course, this means > > performance impact. But since the mapping and unmapping of an ioreq > > server is not a frequent one, the performance penalty may be acceptable. > > How do you think about this approach? > > > > George, sorry to bother you. Any comments on above option? :) > > Another choice might be to let live migration fail if there's > outstanding p2m_ioreq_server entries. But I'm not quite inclined to do > so, because: > 1> I'd still like to keep live migration feature for XenGT. > 2> Not easy to know if there's outstanding p2m_ioreq_server entries. I > mean, since p2m type change is not only triggered by hypercall, to keep > a counter for remaining p2m_ioreq_server entries means a lot code > changes; > > Besides, I wonder whether the requirement to reset the p2m_ioreq_server > is indispensable, could we let the device model side to be responsible > for this? The worst case I can imagine for device model failing to do > so is that operations of a gfn might be delivered to a wrong device > model. I'm not clear what kind of damage would this cause to the > hypervisor or other VM. > > Does any other maintainers have any suggestions? Note that it is a requirement that an ioreq server be disabled before VM suspend. That means ioreq server pages essentially have to go back to ram_rw semantics. Paul
[Xen-devel] memory sharing
hi, what is the difference between memory sharing in Xen and memory de-duplication ? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8.1 04/27] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op
>>> Konrad Rzeszutek Wilk 04/18/16 9:50 AM >>>
>On Sun, Apr 17, 2016 at 02:05:10AM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 04/15/16 4:29 AM >>>
>> >On Thu, Apr 14, 2016 at 10:36:46AM -0600, Jan Beulich wrote:
>> >> >>> Konrad Rzeszutek Wilk 04/14/16 12:05 AM >>>
>> >> > +spin_lock(&payload_lock);
>> >> > +
>> >> > +found = find_payload(n);
>> >> > +if ( IS_ERR(found) )
>> >> > +{
>> >> > +rc = PTR_ERR(found);
>> >> > +goto out;
>> >> > +}
>> >> > +else if ( found )
>> >> > +{
>> >> > +rc = -EEXIST;
>> >> > +goto out;
>> >> > +}
>> >> > +
>> >> > +data = xzalloc(struct payload);
>> >>
>> >> I generally advocate for not doing allocations with locks held, and I
>> >> don't think
>> >> it would severely complicate the code here doing so.
>> >
>> >I can certainly unlock and then lock again (when adding
>> >it to the list).
>>
>> That would create a race again afaict. Instead what I have been trying to
>> hint
>> at is that the allocation should be done before taking the lock, freeing the
>> object
>> again if in the end it turned out it's not going to be needed. Hence the
>> referral to
>
>What if I get -ENOMEM and that the user supplied an payload we already
>have? In that case I would return -ENOMEM while I would expect us to
>return -EEXIST.
>
>Unless I add some extra checks to continue on?
Or unless you didn't check the allocation result right after the allocation
call,
but only where you check it now.
>Also one could do a bit of memory DoS (perhaps by mistake) by continously
>uploading the same and same payload and us first allocating the memory,
>and then doing the check for the payload existence (which would then
>free the memory). Since the allocation is outside the lock we can
>eat a bit of memory.
Why that? You'd free the memory right away on the error path.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 91905: regressions - FAIL
flight 91905 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91905/ 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. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf a8c39ba2986c1ffb1dab864cefedc86402a9695c baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 132 days Failing since 65593 2015-12-08 23:44:51 Z 131 days 154 attempts Testing same since91887 2016-04-18 09:18:52 Z0 days2 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19638 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
>>> Paul Durrant 04/18/16 10:41 AM >>>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 April 2016 22:48
>> >>> On 31.03.16 at 12:53, wrote:
>> > --- a/xen/include/public/hvm/hvm_op.h
>> > +++ b/xen/include/public/hvm/hvm_op.h
>> > @@ -83,7 +83,7 @@ typedef enum {
>> > HVMMEM_ram_rw, /* Normal read/write guest RAM */
>> > HVMMEM_ram_ro, /* Read-only; writes are discarded */
>> > HVMMEM_mmio_dm,/* Reads and write go to the device model
>> */
>> > -HVMMEM_mmio_write_dm /* Read-only; writes go to the device
>> model */
>> > +HVMMEM_ioreq_server,
>> > } hvmmem_type_t;
>> >
>> > /* Following tools-only interfaces may change in future. */
>>
>> So there's one problem here, which the comment at the bottom
>> of the context already hints at: This enum is part of the not
>> tools restricted interface (as HVMOP_get_mem_type is usable
>> by guests themselves), which we cannot change like this. Since
>> the meaning of the enumerator value doesn't change, I guess
>> we can get away with simply retaining its old name for non-up-
>> to-date __XEN_INTERFACE_VERSION__.
>
>Has the type made it into a release yet. I was assuming we could make the
>change without any need to play with the version since it's only ever been
>present in >xen-unstable so far.
Oh, I didn't realize this got added only after 4.6. If that was the case,
then the
change of course could be done without any conditional. Checking ... No, 4.6.1
has it.
As for any of this going in now - I suppose this would need a freeze exception,
which I think we've meant to avoid as much as possible this time round.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation
>>> Razvan Cojocaru 04/18/16 2:40 PM >>>
>On 04/14/2016 07:08 PM, Jan Beulich wrote:
> Razvan Cojocaru 04/14/16 5:45 PM >>>
>>> On 04/14/2016 06:40 PM, Jan Beulich wrote:
To be honest, just having remembered that we do the write back for locked
instructions using CMPXCHG, I'd first of all like to see a proper
description
of "the _whole_ issue".
>>>
>>> I believe at least part of the issue has to do with the comment on line
>>> 1013 from xen/arch/x86/hvm/emulate.c:
>>>
>> >994 static int hvmemul_cmpxchg(
>> >995 enum x86_segment seg,
>> >996 unsigned long offset,
>> >997 void *p_old,
>> >998 void *p_new,
>> >999 unsigned int bytes,
>>> 1000 struct x86_emulate_ctxt *ctxt)
>>> 1001 {
>>> 1002 struct hvm_emulate_ctxt *hvmemul_ctxt =
>>> 1003 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>>> 1004
>>> 1005 if ( unlikely(hvmemul_ctxt->set_context) )
>>> 1006 {
>>> 1007 int rc = set_context_data(p_new, bytes);
>>> 1008
>>> 1009 if ( rc != X86EMUL_OKAY )
>>> 1010 return rc;
>>> 1011 }
>>> 1012
>>> 1013 /* Fix this in case the guest is really relying on r-m-w
>>> atomicity. */
>>> 1014 return hvmemul_write(seg, offset, p_new, bytes, ctxt);
>>> 1015 }
>>
>> Ah, so _that's_ where the problem wants to be fixed then (leaving - afaict -
>> PV emulation paths completely unaffected).
>
>That's what I had hoped too, an early version of this patch simply used
>a spinlock that locked / unlock on entry / exit of hvmemul_cmpxchg().
>Even with this patch, I've just tried it again with all ops->smp_lock()
>/ ops->smp_unlock() calls commented out in x86_emulate(), and
>hvmemul_cmpxchg() modified as follows:
>
>994 static int hvmemul_cmpxchg(
>995 enum x86_segment seg,
>996 unsigned long offset,
>997 void *p_old,
>998 void *p_new,
>999 unsigned int bytes,
>1000 struct x86_emulate_ctxt *ctxt)
>1001 {
>1002 struct hvm_emulate_ctxt *hvmemul_ctxt =
>1003 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>1004 int rc;
>1005
>1006 emulate_smp_lock(1);
>1007
>1008 if ( unlikely(hvmemul_ctxt->set_context) )
>1009 {
>1010 int rc = set_context_data(p_new, bytes);
>1011
>1012 if ( rc != X86EMUL_OKAY )
>1013 return rc;
>1014 }
>1015
>1016 /* Fix this in case the guest is really relying on r-m-w
>atomicity. */
>1017 rc = hvmemul_write(seg, offset, p_new, bytes, ctxt);
>1018
>1019 emulate_smp_unlock(1);
>1020
>1021 return rc;
>1022 }
>
>Unfortunately, with just this the guest still hangs, while with read and
>write locking in x86_emulate() it does not.
That's unexpected at least at the first glance, but justifying some variant of
the patch you have submitted would require understanding why the above
change isn't enough and can't be suitably extended to be sufficient.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 April 2016 17:40
> To: Paul Durrant
> Cc: Andrew Cooper; George Dunlap; jun.nakaj...@intel.com; Kevin Tian;
> zhiyuan...@intel.com; yu.c.zh...@linux.intel.com; xen-devel@lists.xen.org;
> Keir (Xen.org); Tim (Xen.org)
> Subject: Re: RE: [PATCH v2 2/3] x86/ioreq server: Rename
> p2m_mmio_write_dm to p2m_ioreq_server
>
> >>> Paul Durrant 04/18/16 10:41 AM >>>
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 08 April 2016 22:48
> >> >>> On 31.03.16 at 12:53, wrote:
> >> > --- a/xen/include/public/hvm/hvm_op.h
> >> > +++ b/xen/include/public/hvm/hvm_op.h
> >> > @@ -83,7 +83,7 @@ typedef enum {
> >> > HVMMEM_ram_rw, /* Normal read/write guest RAM */
> >> > HVMMEM_ram_ro, /* Read-only; writes are discarded */
> >> > HVMMEM_mmio_dm,/* Reads and write go to the device
> model
> >> */
> >> > -HVMMEM_mmio_write_dm /* Read-only; writes go to the device
> >> model */
> >> > +HVMMEM_ioreq_server,
> >> > } hvmmem_type_t;
> >> >
> >> > /* Following tools-only interfaces may change in future. */
> >>
> >> So there's one problem here, which the comment at the bottom
> >> of the context already hints at: This enum is part of the not
> >> tools restricted interface (as HVMOP_get_mem_type is usable
> >> by guests themselves), which we cannot change like this. Since
> >> the meaning of the enumerator value doesn't change, I guess
> >> we can get away with simply retaining its old name for non-up-
> >> to-date __XEN_INTERFACE_VERSION__.
> >
> >Has the type made it into a release yet. I was assuming we could make the
> change without any need to play with the version since it's only ever been
> present in >xen-unstable so far.
>
> Oh, I didn't realize this got added only after 4.6. If that was the case,
> then
> the
> change of course could be done without any conditional. Checking ... No,
> 4.6.1
> has it.
>
Damn. It needs to be ifdef-ed then :-(
> As for any of this going in now - I suppose this would need a freeze
> exception,
> which I think we've meant to avoid as much as possible this time round.
>
The original patch was posted before the cut-off IIRC so I'm not sure of the
policy regarding freeze-exceptions.
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
>>> Paul Durrant 04/18/16 6:45 PM >>> >The original patch was posted before the cut-off IIRC so I'm not sure > of the policy regarding freeze-exceptions. It was submitted before the feature freeze, yes, but didn't make it in by code freeze. So it's my understanding that an exception would be needed. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan > Beulich > Sent: 18 April 2016 17:47 > To: Paul Durrant > Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George > Dunlap; xen-devel@lists.xen.org; yu.c.zh...@linux.intel.com; > zhiyuan...@intel.com; jun.nakaj...@intel.com > Subject: Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename > p2m_mmio_write_dm to p2m_ioreq_server > > >>> Paul Durrant 04/18/16 6:45 PM >>> > >The original patch was posted before the cut-off IIRC so I'm not sure > > of the policy regarding freeze-exceptions. > > It was submitted before the feature freeze, yes, but didn't make it in by > code freeze. So it's my understanding that an exception would be needed. > Ok. Thanks for the clarification. IMO getting this in is worth the freeze exception... it's a shame p2m_mmio_write_dm made it into 4.6.1. It needs to go before it proliferates any further. Paul > Jan > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 91597: regressions - FAIL
On 04/16/2016 05:54 AM, osstest service owner wrote: > flight 91597 libvirt real [real] > http://logs.test-lab.xenproject.org/osstest/logs/91597/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-amd64-libvirt 5 libvirt-build fail REGR. vs. > 91479 > build-i386-libvirt5 libvirt-build fail REGR. vs. > 91479 > build-armhf-libvirt 5 libvirt-build fail REGR. vs. > 91479 These build failures (warnings treated as errors) surfaced after defining LIBXL_API_VERSION=0x040200. E.g. In file included from /home/osstest/build.91597.build-amd64-libvirt/xendist/usr/local/include/libxl.h:439:0, from libxl/libxl_domain.h:27, from libxl/libxl_domain.c:28: /home/osstest/build.91597.build-amd64-libvirt/xendist/usr/local/include/libxl_uuid.h:64:1: error: 'static' is not at beginning of declaration [-Werror=old-style-declaration] void static inline libxl_uuid_copy_0x040400(libxl_uuid *dst, ^ /home/osstest/build.91597.build-amd64-libvirt/xendist/usr/local/include/libxl_uuid.h:64:1: error: 'inline' is not at beginning of declaration [-Werror=old-style-declaration] I suppose the obvious fix is to change the declarations and backport to all maintained releases. Another option is suppressing the warning. Or perhaps a better trick? Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 91886: regressions - FAIL
flight 91886 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/91886/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 91608 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 91608 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 91608 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 91608 Tests which did not succeed, but are not blocking: 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-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-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-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail 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-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail 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-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 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: qemuu072035eba1ceb87a987cc03d756fc2da3f3ba058 baseline version: qemuuc7b45f12828c1ba7105dbc029c63d7de68eaa91c Last test of basis91608 2016-04-16 05:33:07 Z2 days Testing same since91886 2016-04-18 10:02:33 Z0 days1 attempts People who touched revisions under test: Denis V. Lunev Dr. David Alan Gilbert Eric Blake Fam Zheng Jeff Cody Kevin Wolf Laszlo Ersek Max Reitz Paolo Bonzini Pavel Butsykin Peter Maydell Sascha Silbe Stefan Hajnoczi jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl
[Xen-devel] [ovmf test] 91932: regressions - FAIL
flight 91932 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91932/ 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. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf a8c39ba2986c1ffb1dab864cefedc86402a9695c baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 132 days Failing since 65593 2015-12-08 23:44:51 Z 131 days 155 attempts Testing same since91887 2016-04-18 09:18:52 Z0 days3 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19638 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt bisection] complete build-armhf-libvirt
branch xen-unstable xenbranch xen-unstable job build-armhf-libvirt testid libvirt-build Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: libvirt git://libvirt.org/libvirt.git Bug introduced: e744065679ccba8471d28b2cf6e93f443cd20c8c Bug not present: 744d74fafd0048c01a2b5cc18d1b03917ece8886 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/91943/ commit e744065679ccba8471d28b2cf6e93f443cd20c8c Author: Jim Fehlig Date: Thu Apr 14 16:10:32 2016 -0600 libxl: use LIBXL_API_VERSION 0x040200 To ensure the libvirt libxl driver will build with future versions of Xen where the libxl API may change in incompatible ways, explicitly use LIBXL_API_VERSION 0x040200. The libxl driver does use new libxl APIs that have been added since Xen 4.2, but currently it does not make use of any changes made to existing APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity. The version can be bumped if/when the libxl driver consumes the changed APIs. Further details can be found in the following discussion thread https://www.redhat.com/archives/libvir-list/2016-April/msg00178.html Signed-off-by: Jim Fehlig For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/build-armhf-libvirt.libvirt-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/libvirt/build-armhf-libvirt.libvirt-build --summary-out=tmp/91943.bisection-summary --basis-template=91479 --blessings=real,real-bisect libvirt build-armhf-libvirt libvirt-build Searching for failure / basis pass: 91860 fail [host=arndale-metrocentre] / 91479 [host=arndale-bluewater] 91380 [host=arndale-bluewater] 91230 [host=cubietruck-gleizes] 91073 [host=arndale-westfield] 90907 ok. Failure / basis pass flights: 91860 / 90907 Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest c81bba4f6f925eda28e64bc6593e916f852db99e 6cc32c63e80bc1a30c521b2f07f2b54909b59892 316a862e5534249a6e6d876b4e203342d3fb870e f3a7ca02400d1c416e97451b4aebfaf608fc8192 Basis pass 799ced1f80b10d32815615e4d342aa71f8e1c113 6cc32c63e80bc1a30c521b2f07f2b54909b59892 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf519244a16674031b8034b581ba7f Generating revisions with ./adhoc-revtuple-generator git://libvirt.org/libvirt.git#799ced1f80b10d32815615e4d342aa71f8e1c113-c81bba4f6f925eda28e64bc6593e916f852db99e git://git.sv.gnu.org/gnulib.git#6cc32c63e80bc1a30c521b2f07f2b54909b59892-6cc32c63e80bc1a30c521b2f07f2b54909b59892 git://xenbits.xen.org/qemu-xen.git#316a862e5534249a6e6d876b4e203342d3fb870e-316a862e5534249a6e6d876b4e203342d3fb870e git://xenbits.xen.org/xen.git#a6f2cdb633bf519244a16674031b8034b581ba7f-f3a7ca02400d1c416e97451b4aebfaf608fc8192 Loaded 2001 nodes in revision graph Searching for test results: 90907 pass 799ced1f80b10d32815615e4d342aa71f8e1c113 6cc32c63e80bc1a30c521b2f07f2b54909b59892 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf519244a16674031b8034b581ba7f 91009 pass irrelevant 91025 pass irrelevant 91019 fail irrelevant 91060 fail irrelevant 91032 pass irrelevant 91038 pass irrelevant 91073 [host=arndale-westfield] 91046 pass irrelevant 91056 pass irrelevant 91230 [host=cubietruck-gleizes] 91380 [host=arndale-bluewater] 91479 [host=arndale-bluewater] 91597 fail irrelevant 91722 fail 727a3c5860ef5e1fb8878da9d44c6e5e33a4f4ae 6cc32c63e80bc1a30c521b2f07f2b54909b59892 316a862e5534249a6e6d876b4e203342d3fb870e f3a7ca02400d1c416e97451b4aebfaf608fc8192 91826 fail 727a3c5860ef5e1fb8878da9d44c6e5e33a4f4ae 6cc32c63e80bc1a30c521b2f07f2b54909b59892 316a862e5534249a6e6d876b4e203342d3fb870e f3a7ca02400d1c416e97451b4aebfaf608fc8192 91815 pass 799ced1f80b10d32815615e4d342aa71f8e1c113 6cc32c63e80bc1a30c521b2f07f2b54909b59892 316a862e5534249a6e6d876b4e203342d3fb870e a6f2cdb633bf519244a16674031b8034b581ba7f 91833 pass 799ced1f80b10d32815615e4d342aa71f8e1c113 6cc32c63e80bc1a30c521b2f07f2b54909b59892 316a862e5534249a6e6d876b4e203342d3fb870e 1d8279231ff8781c013dd1b909edda22f7b57720 91840 pass 799ced1f80b10d32815615e4d342aa71f8e1c113 6cc32c63e80bc1a30c521b2f07f2b54909b59892 316a862e5534249a6e6d876b4e203342d3fb870e 671361d40526cff052b97bfe16dc901d851899f0 91847 pass f376069fa513f82098f802ee3ad2c328cd3f2c4d 6cc32c63e80bc1a30c521b2f07f2b54909b59892 316a862e5534249a6e6d876b4e203342d3fb870e ac703c285a4fbfcb85c19364ea0c67780bf16c2d 91854 pass c493d216424e64723d958f31958ac386ea6a3acf 6cc32c63e80bc1a30c521b2f07f
[Xen-devel] [ovmf test] 91949: regressions - FAIL
flight 91949 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91949/ 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. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf a8c39ba2986c1ffb1dab864cefedc86402a9695c baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 132 days Failing since 65593 2015-12-08 23:44:51 Z 131 days 156 attempts Testing same since91887 2016-04-18 09:18:52 Z0 days4 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19638 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 91964: regressions - FAIL
flight 91964 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91964/ 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. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf a8c39ba2986c1ffb1dab864cefedc86402a9695c baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 132 days Failing since 65593 2015-12-08 23:44:51 Z 132 days 157 attempts Testing same since91887 2016-04-18 09:18:52 Z0 days5 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19638 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 91935: regressions - FAIL
flight 91935 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/91935/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 9 debian-installfail REGR. vs. 91608 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-installfail REGR. vs. 91608 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 91608 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 91608 Tests which did not succeed, but are not blocking: 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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-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-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail 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-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail 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-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 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: qemuu92b674b62a1aec734280c9019cfb3b3745044b66 baseline version: qemuuc7b45f12828c1ba7105dbc029c63d7de68eaa91c Last test of basis91608 2016-04-16 05:33:07 Z2 days Failing since 91886 2016-04-18 10:02:33 Z0 days2 attempts Testing same since91935 2016-04-18 17:51:02 Z0 days1 attempts People who touched revisions under test: Andreas Färber David Gibson Denis V. Lunev Dr. David Alan Gilbert Eduardo Habkost Eduardo Otubo Eric Blake Fam Zheng James Hogan Jeff Cody Kevin Wolf Laszlo Ersek Mark Cave-Ayland Max Reitz Michael Fritscher Miroslav Rezanina Paolo Bonzini Pavel Butsykin Peter Maydell Sascha Silbe Stefan Hajnoczi Stefan Weil Thomas Huth jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl
[Xen-devel] [ovmf test] 91978: regressions - FAIL
flight 91978 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/91978/ 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. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf a8c39ba2986c1ffb1dab864cefedc86402a9695c baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 132 days Failing since 65593 2015-12-08 23:44:51 Z 132 days 158 attempts Testing same since91887 2016-04-18 09:18:52 Z0 days6 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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 19638 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv8] x86/ept: defer the invalidation until the p2m lock is released
> From: David Vrabel [mailto:david.vra...@citrix.com] > Sent: Wednesday, April 13, 2016 12:20 AM > > Holding the p2m lock while calling ept_sync_domain() is very expensive > since it does an on_selected_cpus() call. IPIs on many socket > machines can be very slow and on_selected_cpus() is serialized. > > It is safe to defer the invalidate until the p2m lock is released > except for two cases: > > 1. When freeing a page table page (since partial translations may be >cached). > 2. When reclaiming a zero page as part of PoD. > > For these cases, add p2m_tlb_flush_sync() calls which will immediately > perform the invalidate before the page is freed or reclaimed. > > Signed-off-by: David Vrabel Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: Thursday, April 14, 2016 6:45 PM > > On 4/11/2016 7:15 PM, Yu, Zhang wrote: > > > > > > On 4/8/2016 7:01 PM, George Dunlap wrote: > >> On 08/04/16 11:10, Yu, Zhang wrote: > >> [snip] > >>> BTW, I noticed your reply has not be CCed to mailing list, and I also > >>> wonder if we should raise this last question in community? > >> > >> Oops -- that was a mistake on my part. :-) I appreciate the > >> discretion; just so you know in the future, if I'm purposely changing > >> the CC list (removing xen-devel and/or adding extra people), I'll almost > >> always say so at the top of the mail. > >> > And then of course there's the p2m_ioreq_server -> p2m_ram_logdirty > transition -- I assume that live migration is incompatible with this > functionality? Is there anything that prevents a live migration from > being started when there are outstanding p2m_ioreq_server entries? > > >>> > >>> Another good question, and the answer is unfortunately yes. :-) > >>> > >>> If live migration happens during the normal emulation process, entries > >>> marked with p2m_ioreq_server will be changed to p2m_log_dirty in > >>> resolve_misconfig(), and later write operations will change them to > >>> p2m_ram_rw, thereafter these pages can not be forwarded to device model. > >>> From this point of view, this functionality is incompatible with live > >>> migration. > >>> > >>> But for XenGT, I think this is acceptable, because, if live migration > >>> is to be supported in the future, intervention from backend device > >>> model will be necessary. At that time, we can guarantee from the device > >>> model side that there's no outdated p2m_ioreq_server entries, hence no > >>> need to reset the p2m type back to p2m_ram_rw(and do not include > >>> p2m_ioreq_server in the P2M_CHANGEABLE_TYPES). By "outdated", I mean > >>> when an ioreq server is detached from p2m_ioreq_server, or before an > >>> ioreq server is attached to this type, entries marked with > >>> p2m_ioreq_server should be regarded as outdated. > >>> > >>> Is this acceptible to you? Any suggestions? > >> > >> So the question is, as of this series, what happens if someone tries to > >> initiate a live migration while there are outstanding p2m_ioreq_server > >> entries? > >> > >> If the answer is "the ioreq server suddenly loses all control of the > >> memory", that's something that needs to be changed. > >> > > > > Sorry, for this patch series, I'm afraid the above description is the > > answer. > > > > Besides, I find it's hard to change current code to both support the > > deferred resetting of p2m_ioreq_server and the live migration at the > > same time. One reason is that a page with p2m_ioreq_server behaves > > differently in different situations. > > > > My assumption of XenGT is that, for live migration to work, the device > > model should guarantee there's no outstanding p2m_ioreq_server pages > > in hypervisor(no need to use the deferred recalculation), and it is our > > device model who should be responsible for the copying of the write > > protected guest pages later. > > > > And another solution I can think of: when unmapping the ioreq server, > > we walk the p2m table and reset entries with p2m_ioreq_server back > > directly, instead of deferring the reset. And of course, this means > > performance impact. But since the mapping and unmapping of an ioreq > > server is not a frequent one, the performance penalty may be acceptable. > > How do you think about this approach? > > > > George, sorry to bother you. Any comments on above option? :) > > Another choice might be to let live migration fail if there's > outstanding p2m_ioreq_server entries. But I'm not quite inclined to do > so, because: > 1> I'd still like to keep live migration feature for XenGT. > 2> Not easy to know if there's outstanding p2m_ioreq_server entries. I > mean, since p2m type change is not only triggered by hypercall, to keep > a counter for remaining p2m_ioreq_server entries means a lot code > changes; > > Besides, I wonder whether the requirement to reset the p2m_ioreq_server > is indispensable, could we let the device model side to be responsible > for this? The worst case I can imagine for device model failing to do > so is that operations of a gfn might be delivered to a wrong device > model. I'm not clear what kind of damage would this cause to the > hypervisor or other VM. > > Does any other maintainers have any suggestions? > Thanks in advance! :) I'm not sure how above is working. In pre-copy phase (where logdirty is concerned), the device model is still actively serving requests from guest, including initiating new write-protection requests. How can you guarantee draining of outstanding p2m_ioreq_server entries w/o actually freezing device model (while freezing device model means guest driver might be blocked with random errors)? Thanks Kevin ___ Xe
Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com] > Sent: Thursday, April 14, 2016 5:57 PM > > And with all three bits now possibly being clear, aren't we risking the > > entries to be mis-treated as not-present ones? > > Hah. You got me. Thanks! :) > Now I realized it would be difficult if we wanna to emulate the read > operations for HVM. According to Intel mannual, entry->r is to be > cleared, so should entry->w if we do not want ept misconfig. And > with both read and write permissions being forbidden, entry->x can be > set only on processors with EXECUTE_ONLY capability. > To avoid any entry to be mis-treated as not-present. We have several > solutions: > a> do not support the read emulation for now - we have no such usage > case; > b> add the check of p2m_t against p2m_ioreq_server in is_epte_present - > a bit weird to me. > Which one do you prefer? or any other suggestions? > >>> > >>> That question would also need to be asked to others who had > >>> suggested supporting both. I'd be fine with a, but I also don't view > >>> b as too awkward. > >> > >> According to Intel mannual, an entry is regarded as not present, if > >> bit0:2 is 0. So adding a p2m type check in is_epte_present() means we > >> will change its semantics, if this is acceptable(with no hurt to > >> hypervisor). I'd prefer option b> > > > > Perhaps time for the VMX maintainers to chime in - such a change is > > acceptable > > only if it doesn't result in changed hardware behavior. I can't think of > > any such off > > the top of my head, but this really should be confirmed by the maintainers > > before > > deciding to go such a route. > > > > Thanks, Jan. :) > Jun & Kevin, any suggestions? > I'm a bit worried about this change, since it's a fundamental EPT interface. Can we avoid supporting read emulation now? Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4] vm_event: Allow subscribing to write events for specific MSR-s
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > Sent: Monday, April 18, 2016 3:16 AM > > Previously, subscribing to MSR write events was an all-or-none > approach, with special cases for introspection MSR-s. This patch > allows the vm_event consumer to specify exactly what MSR-s it is > interested in, and as a side-effect gets rid of the > vmx_introspection_force_enabled_msrs[] special case. > This replaces the previously posted "xen: Filter out MSR write > events" patch. > > Signed-off-by: Razvan Cojocaru > Acked-by: Wei Liu > Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8.1 12/27] xsplice: Implement support for applying/reverting/replacing patches.
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>--- a/docs/misc/xsplice.markdown
>+++ b/docs/misc/xsplice.markdown
>@@ -289,8 +289,13 @@ describing the functions to be patched:
>
>struct xsplice_patch_func {
>const char *name;
>+#if BITS_PER_LONG == 32
>+uint32_t new_addr;
>+uint32_t old_addr;
>+#else
>uint64_t new_addr;
>uint64_t old_addr;
>+#endif
I don't think this belongs here (instead it should go wherever the structure
gets
introduced).
>@@ -298,7 +303,8 @@ struct xsplice_patch_func {
>};
>
>
>-The size of the structure is 64 bytes.
>+The size of the structure is 64 bytes or 52 bytes if compiled under 32-bit
>+hypervisors.
And I'm uncertain this sentence is of much value.
>@@ -120,6 +121,7 @@ static void idle_loop(void)
>(*pm_idle)();
>do_tasklet();
>do_softirq();
>+check_for_xsplice_work(); /* Must be last. */
Without also saying why, the comment isn't very useful imo.
>+void arch_xsplice_apply_jmp(struct xsplice_patch_func_internal *func)
>+{
>+int32_t val;
>+uint8_t *old_ptr;
>+
>+BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->u.undo));
>+BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
Standard sizeof() please.
>+old_ptr = func->old_addr;
>+memcpy(func->u.undo, old_ptr, PATCH_INSN_SIZE);
>+
>+*old_ptr++ = 0xe9; /* Relative jump */
>+val = func->new_addr - func->old_addr - PATCH_INSN_SIZE;
>+memcpy(old_ptr, &val, sizeof val);
Again (and I won't make further comments to that effect, the more that this was
requested in a previous round already anyway).
>+/*
>+ * Note that because of this NOP code the do_nmi is not safely patchable.
>+ * Also if we do receive 'real' NMIs we have lost them. Ditto for MCE.
>+ */
The reference to MCE is misleading here: You don't redirect the latter here, so
its
handling is not the same as NMI.
>@@ -148,12 +224,12 @@ int arch_xsplice_secure(void *va, unsigned int pages,
>enum va_type type)
>ASSERT(va);
>ASSERT(pages);
>
>-if ( type == XSPLICE_VA_RX ) /* PAGE_HYPERVISOR_RX */
>-flag = _PAGE_PRESENT;
>-else if ( type == XSPLICE_VA_RW ) /* PAGE_HYPERVISOR_RW */
>-flag = _PAGE_RW | _PAGE_NX | _PAGE_PRESENT;
>-else /* PAGE_HYPERVISOR_RO */
>-flag = _PAGE_NX | _PAGE_PRESENT;
>+if ( type == XSPLICE_VA_RX )
>+flag = PAGE_HYPERVISOR_RX;
>+else if ( type == XSPLICE_VA_RW )
>+flag = PAGE_HYPERVISOR_RW;
>+else
>+flag = PAGE_HYPERVISOR_RO;
Misplaced hunk (belongs in an earlier patch, and matches exactly what I
had asked
for there).
>@@ -11,18 +12,28 @@
>#include
>#include
>#include
>+#include
>#include
>#include
>+#include
>#include
>#include
>
>#include
>#include
>
>-/* Protects against payload_list operations. */
>+/*
>+ * Protects against payload_list operations and also allows only one
>+ * caller in schedule_work.
>+ */
>static DEFINE_SPINLOCK(payload_lock);
>static LIST_HEAD(payload_list);
>
>+/*
>+ * Patches which have been applied.
>+ */
Ehem - comment style (still).
>+/* Defines an outstanding patching action. */
>+struct xsplice_work
>+{
>+atomic_t semaphore; /* Used for rendezvous. */
>+atomic_t irq_semaphore; /* Used to signal all IRQs disabled. */
Why do you, btw, need two of them? I would seem to me that having just one
for both purposes should be fine.
>+static int check_special_sections(const struct xsplice_elf *elf)
>+{
>+unsigned int i;
>+static const char *const names[] = { ".xsplice.funcs" };
>+unsigned int count[ARRAY_SIZE(names)] = { 0 };
>+
>+for ( i = 0; i < ARRAY_SIZE(names); i++ )
>+{
>+const struct xsplice_elf_sec *sec;
>+
>+sec = xsplice_elf_sec_by_name(elf, names[i]);
>+if ( !sec )
>+{
>+dprintk(XENLOG_ERR, XSPLICE "%s: %s is missing!\n",
>+elf->name, names[i]);
>+return -EINVAL;
>+}
>+
>+if ( !sec->sec->sh_size )
>+{
>+dprintk(XENLOG_ERR, XSPLICE "%s: %s is empty!\n",
>+elf->name, names[i]);
>+return -EINVAL;
>+}
>+count[i]++;
To conserve stack space, use a bool_t array instead and do the check-and-exit
here instead of in a second loop.
>+static int prepare_payload(struct payload *payload,
>+ struct xsplice_elf *elf)
>+{
>+const struct xsplice_elf_sec *sec;
>+unsigned int i;
>+struct xsplice_patch_func_internal *f;
Why is there a second ("internal") variant of this structure now? What
guarantees it to remain in sync with the non-"internal" one?
>+sec = xsplice_elf_sec_by_name(elf, ".xsplice.funcs");
Since the string literal occurs at least twice, I'd suggest having a #define
for it.
>+ASSERT(sec);
>+if ( sec->sec->sh_size % sizeof(*payload->funcs) )
>+{
>+dprintk(XENLOG_ERR, XSPLICE "%s: Wrong size of .xsplice.funcs!\n",
>+
Re: [Xen-devel] [PATCH v2 01/11] vt-d: fix the IOMMU flush issue
> From: Xu, Quan
> Sent: Monday, April 18, 2016 10:00 PM
>
> The propagation value from IOMMU flush interfaces may be positive, which
> indicates callers need to flush cache, not one of faliures.
>
> when the propagation value is positive, this patch fixes this flush issue
> as follows:
> - call iommu_flush_write_buffer() to flush cache.
> - return zero.
>
> Signed-off-by: Quan Xu
>
> CC: Kevin Tian
> CC: Feng Wu
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Andrew Cooper
> ---
> xen/drivers/passthrough/vtd/iommu.c | 94
> -
> xen/include/asm-x86/iommu.h | 2 +-
> 2 files changed, 63 insertions(+), 33 deletions(-)
>
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index 5ad25dc..50d98ac 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -558,14 +558,16 @@ static void iommu_flush_all(void)
> }
> }
>
> -static void __intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> -int dma_old_pte_present, unsigned int page_count)
> +static int iommu_flush_iotlb(struct domain *d, unsigned long gfn,
any reason for the renaming here?
> + int dma_old_pte_present,
> + unsigned int page_count)
> {
> struct hvm_iommu *hd = domain_hvm_iommu(d);
> struct acpi_drhd_unit *drhd;
> struct iommu *iommu;
> int flush_dev_iotlb;
> int iommu_domid;
> +int rc = 0;
>
> /*
> * No need pcideves_lock here because we have flush
> @@ -584,29 +586,34 @@ static void __intel_iommu_iotlb_flush(struct domain *d,
> unsigned long gfn,
> continue;
>
> if ( page_count != 1 || gfn == INVALID_GFN )
> -{
> -if ( iommu_flush_iotlb_dsi(iommu, iommu_domid,
> -0, flush_dev_iotlb) )
> -iommu_flush_write_buffer(iommu);
> -}
> +rc = iommu_flush_iotlb_dsi(iommu, iommu_domid,
> + 0, flush_dev_iotlb);
> else
> +rc = iommu_flush_iotlb_psi(iommu, iommu_domid,
> + (paddr_t)gfn << PAGE_SHIFT_4K,
> + PAGE_ORDER_4K,
> + !dma_old_pte_present,
> + flush_dev_iotlb);
> +
> +if ( rc > 0 )
> {
> -if ( iommu_flush_iotlb_psi(iommu, iommu_domid,
> -(paddr_t)gfn << PAGE_SHIFT_4K, PAGE_ORDER_4K,
> -!dma_old_pte_present, flush_dev_iotlb) )
> -iommu_flush_write_buffer(iommu);
> -}
> +iommu_flush_write_buffer(iommu);
> +rc = 0;
> +} else if ( rc < 0 )
> +break;
> }
> +
> +return rc;
> }
>
> static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> unsigned int
> page_count)
> {
> -__intel_iommu_iotlb_flush(d, gfn, 1, page_count);
> +iommu_flush_iotlb(d, gfn, 1, page_count);
> }
>
> static void intel_iommu_iotlb_flush_all(struct domain *d)
> {
> -__intel_iommu_iotlb_flush(d, INVALID_GFN, 0, 0);
> +iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
> }
Do you plan to change return value of above 2 functions in another
patch, or will keep it current form w/o propagation?
>
> /* clear one page's page table */
> @@ -640,7 +647,7 @@ static void dma_pte_clear_one(struct domain *domain, u64
> addr)
> iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
>
> if ( !this_cpu(iommu_dont_flush_iotlb) )
> -__intel_iommu_iotlb_flush(domain, addr >> PAGE_SHIFT_4K, 1, 1);
> +iommu_flush_iotlb(domain, addr >> PAGE_SHIFT_4K, 1, 1);
>
> unmap_vtd_domain_page(page);
> }
> @@ -1281,6 +1288,7 @@ int domain_context_mapping_one(
> u64 maddr, pgd_maddr;
> u16 seg = iommu->intel->drhd->segment;
> int agaw;
> +int rc;
>
> ASSERT(pcidevs_locked());
> spin_lock(&iommu->lock);
> @@ -1394,13 +1402,19 @@ int domain_context_mapping_one(
> spin_unlock(&iommu->lock);
>
> /* Context entry was previously non-present (with domid 0). */
> -if ( iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
> -DMA_CCMD_MASK_NOBIT, 1) )
> -iommu_flush_write_buffer(iommu);
> -else
> +rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
> +DMA_CCMD_MASK_NOBIT, 1);
> +
> +if ( !rc )
> {
> int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> -iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
> +rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
> +}
> +
> +if ( rc > 0 )
> +{
> +iommu_flush_write_buffer(iommu);
> +rc = 0;
what about 'rc>0' in iommu_flush_context_device while "rc<0"
in iommu_flush_iotlb_dsi,
Re: [Xen-devel] [PATCH v2 02/11] IOMMU: handle IOMMU mapping and unmapping failures
> From: Quan Xu > Sent: Monday, April 18, 2016 10:00 PM > > Now IOMMU mapping and unmapping failures are treated as a fatal to > the domain (with the exception of the hardware domain). 'Now' is more about eixsting state, while it's actually what you want to change towards. Better directly say "Treat IOMMU mapping...". > > If IOMMU mapping and unmapping failed, crash the domain (with the > exception of the hardware domain) and propagate the error up to the > call trees. > > Signed-off-by: Quan Xu > > CC: Jan Beulich Otherwise looks OK to me. Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 02/11] IOMMU: handle IOMMU mapping and unmapping failures
On April 19, 2016 2:37pm, Tian, Kevin wrote: > > From: Quan Xu > > Sent: Monday, April 18, 2016 10:00 PM > > > > Now IOMMU mapping and unmapping failures are treated as a fatal to the > > domain (with the exception of the hardware domain). > > 'Now' is more about eixsting state, while it's actually what you want to > change > towards. Better directly say "Treat IOMMU mapping...". > Agreed. I'll modify it in next v3. Thanks for your review!! Quan > > > > If IOMMU mapping and unmapping failed, crash the domain (with the > > exception of the hardware domain) and propagate the error up to the > > call trees. > > > > Signed-off-by: Quan Xu > > > > CC: Jan Beulich > > Otherwise looks OK to me. > > Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 03/11] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
> From: Xu, Quan
> Sent: Monday, April 18, 2016 10:00 PM
>
> If IOMMU mapping and unmapping failed, the domain (with the exception of
> the hardware domain) is crashed, treated as a fatal error. Rollback can
> be lighter weight.
What do you mean by 'lighter weight"? Please clarify it.
>
> For the hardware domain, we do things on a best effort basis. When rollback
> is not feasible (in early initialization phase or trade-off of complexity),
> at least, unmap upon maps error or then throw out error message.
remove 'or'. Based on next sentence, is above specific for IOMMU mapping?
>
> IOMMU unmapping should perhaps continue despite an error, in an attempt to
> do best effort cleanup.
>
> Signed-off-by: Quan Xu
>
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Jun Nakajima
> CC: Kevin Tian
> CC: George Dunlap
> ---
> xen/arch/x86/mm.c | 13 -
> xen/arch/x86/mm/p2m-ept.c | 25 ++---
> xen/arch/x86/mm/p2m-pt.c| 22 ++
> xen/arch/x86/mm/p2m.c | 11 +--
> xen/drivers/passthrough/iommu.c | 14 +-
> 5 files changed, 70 insertions(+), 15 deletions(-)
>
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index c997b53..5c4fb58 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info *page,
> unsigned
> long type,
> int preemptible)
> {
> unsigned long nx, x, y = page->u.inuse.type_info;
> -int rc = 0;
> +int rc = 0, ret = 0;
>
> ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
>
> @@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info *page,
> unsigned
> long type,
> if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
> {
> if ( (x & PGT_type_mask) == PGT_writable_page )
> -iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
> +ret = iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
> else if ( type == PGT_writable_page )
> -iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
> - page_to_mfn(page),
> - IOMMUF_readable|IOMMUF_writable);
> +ret = iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
> + page_to_mfn(page),
> + IOMMUF_readable|IOMMUF_writable);
> }
> }
>
> @@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info *page,
> unsigned
> long type,
> if ( (x & PGT_partial) && !(nx & PGT_partial) )
> put_page(page);
>
> +if ( unlikely(ret) )
> +rc = ret;
> +
> return rc;
> }
>
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index 3cb6868..22c8d17 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -665,7 +665,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn,
> mfn_t mfn,
> ept_entry_t *table, *ept_entry = NULL;
> unsigned long gfn_remainder = gfn;
> unsigned int i, target = order / EPT_TABLE_ORDER;
> -int ret, rc = 0;
> +int ret, err = 0, rc = 0;
> bool_t direct_mmio = (p2mt == p2m_mmio_direct);
> uint8_t ipat = 0;
> bool_t need_modify_vtd_table = 1;
> @@ -830,10 +830,26 @@ out:
> {
> if ( iommu_flags )
> for ( i = 0; i < (1 << order); i++ )
> -iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
> +{
> +ret = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
> iommu_flags);
> +
> +if ( unlikely(ret) )
> +{
> +while (i)
> +iommu_unmap_page(d, gfn + --i);
How about below?
while (i-- >= 0)
iommu_unmap_page(d, gfn + i);
> +
> +err = ret;
> +break;
> +}
> +}
> else
> for ( i = 0; i < (1 << order); i++ )
> -iommu_unmap_page(d, gfn + i);
> +{
> +ret = iommu_unmap_page(d, gfn + i);
> +
> +if ( unlikely(ret) )
> +err = ret;
> +}
> }
> }
>
> @@ -849,6 +865,9 @@ out:
> if ( rc == 0 && p2m_is_hostp2m(p2m) )
> p2m_altp2m_propagate_change(d, _gfn(gfn), mfn, order, p2mt, p2ma);
>
> +if ( unlikely(err) )
> +rc = err;
> +
not sure we need three return values here: rc, ret, err...
> return rc;
> }
>
> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> index 3d80612..db4257a 100644
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -498,7 +498,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long
> gfn,
> mfn_t mfn,
> l1_pgentry_t i
Re: [Xen-devel] [PATCH v2 04/11] grant_table: avoid unnecessary work during grant table unmapping
> From: Quan Xu > Sent: Monday, April 18, 2016 10:00 PM > > While grant table is unmapping, the domain (with the exception of the unmapping -> unmapped. > hardware domain) may be crashed due to IOMMU mapping and unmapping > failures, and then it is unnecessary to flush specified CPUs' TLBs. Above description is not complete. You said "with the exception of the hardware domain". Then people will ask whether 'unnecessary' is also true for hardware domain (if not restriction for hardware domain to invoke those interfaces). > > Signed-off-by: Quan Xu > > CC: Ian Jackson > CC: Jan Beulich > CC: Keir Fraser > CC: Tim Deegan > --- > xen/common/grant_table.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c > index 8b22299..1801fe9 100644 > --- a/xen/common/grant_table.c > +++ b/xen/common/grant_table.c > @@ -1366,8 +1366,9 @@ gnttab_unmap_grant_ref( > > return 0; > > -fault: > -gnttab_flush_tlb(current->domain); > + fault: > +if ( current->domain->is_shut_down ) > +gnttab_flush_tlb(current->domain); > > for ( i = 0; i < partial_done; i++ ) > __gnttab_unmap_common_complete(&(common[i])); > @@ -1429,8 +1430,9 @@ gnttab_unmap_and_replace( > > return 0; > > -fault: > -gnttab_flush_tlb(current->domain); > + fault: > +if ( current->domain->is_shut_down ) > +gnttab_flush_tlb(current->domain); > > for ( i = 0; i < partial_done; i++ ) > __gnttab_unmap_common_complete(&(common[i])); > -- > 1.9.1 > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 05/11] vt-d: propagate IOMMU Device-TLB flush error up to IOMMU unmapping.
> From: Xu, Quan > Sent: Monday, April 18, 2016 10:00 PM > > While IOMMU Device-TLB flush timed out, xen calls panic() at present. > However the existing panic() is going to be eliminated, so we must > propagate the IOMMU Device-TLB flush error up to IOMMU unmapping. Thought you don't need replicate the same reason in every patch. clear enough to just keep last line. > > Signed-off-by: Quan Xu > > CC: Kevin Tian > CC: Feng Wu > CC: Jan Beulich Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 06/11] vt-d: propagate IOMMU Device-TLB flush error up to IOMMU mapping.
> From: Xu, Quan > Sent: Monday, April 18, 2016 10:00 PM > > While IOMMU Device-TLB flush timed out, xen calls panic() at present. > However the existing panic() is going to be eliminated, so we must > propagate the IOMMU Device-TLB flush error up to IOMMU mapping. > > Signed-off-by: Quan Xu > > CC: Kevin Tian > CC: Feng Wu > CC: Jan Beulich same comment on above message. for code itself: Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 08/11] IOMMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (leaf ones).
> From: Xu, Quan
> Sent: Monday, April 18, 2016 10:00 PM
>
> While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> However the existing panic() is going to be eliminated, so we must
> propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
>
> If IOMMU mapping and unmapping failed, the domain (with the exception of
> the hardware domain) is crashed, treated as a fatal error. Rollback can
> be lighter weight.
>
> This patch fixes the leaf ones.
what about other leaves like AMD/ARM callbacks?
>
> Signed-off-by: Quan Xu
>
> CC: Jan Beulich
> CC: Kevin Tian
> CC: Feng Wu
> ---
> xen/drivers/passthrough/iommu.c | 8 ++--
> xen/drivers/passthrough/vtd/iommu.c | 8
> xen/include/xen/iommu.h | 4 ++--
> 3 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index 9254760..d44fc39 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -308,9 +308,7 @@ int iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> unsigned int page_cou
> if ( !iommu_enabled || !hd->platform_ops ||
> !hd->platform_ops->iotlb_flush )
> return 0;
>
> -hd->platform_ops->iotlb_flush(d, gfn, page_count);
> -
> -return 0;
> +return hd->platform_ops->iotlb_flush(d, gfn, page_count);
> }
>
> int iommu_iotlb_flush_all(struct domain *d)
> @@ -320,9 +318,7 @@ int iommu_iotlb_flush_all(struct domain *d)
> if ( !iommu_enabled || !hd->platform_ops ||
> !hd->platform_ops->iotlb_flush_all )
> return 0;
>
> -hd->platform_ops->iotlb_flush_all(d);
> -
> -return 0;
> +return hd->platform_ops->iotlb_flush_all(d);
> }
>
> int __init iommu_setup(void)
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index 5cc70ca..930661a 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -606,14 +606,14 @@ static int iommu_flush_iotlb(struct domain *d, unsigned
> long
> gfn,
> return rc;
> }
>
> -static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> unsigned int
> page_count)
> +static int intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> unsigned int
> page_count)
> {
> -iommu_flush_iotlb(d, gfn, 1, page_count);
> +return iommu_flush_iotlb(d, gfn, 1, page_count);
> }
>
> -static void intel_iommu_iotlb_flush_all(struct domain *d)
> +static int intel_iommu_iotlb_flush_all(struct domain *d)
> {
> -iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
> +return iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
> }
>
> /* clear one page's page table */
> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
> index ff4608d..ca1c409 100644
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -161,8 +161,8 @@ struct iommu_ops {
> void (*resume)(void);
> void (*share_p2m)(struct domain *d);
> void (*crash_shutdown)(void);
> -void (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int
> page_count);
> -void (*iotlb_flush_all)(struct domain *d);
> +int (*iotlb_flush)(struct domain *d, unsigned long gfn, unsigned int
> page_count);
> +int (*iotlb_flush_all)(struct domain *d);
> int (*get_reserved_device_memory)(iommu_grdm_t *, void *);
> void (*dump_p2m_table)(struct domain *d);
> };
> --
> 1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
