Re: [Xen-devel] [PATCH v6 08/16] x86: implement set value flow for MBA
>>> On 13.10.17 at 04:02, wrote: > On 17-10-12 03:43:26, Jan Beulich wrote: >> >>> On 12.10.17 at 06:33, wrote: >> > On 17-10-11 07:38:52, Jan Beulich wrote: >> >> >>> On 08.10.17 at 09:23, wrote: >> >> > --- a/xen/arch/x86/psr.c >> >> > +++ b/xen/arch/x86/psr.c >> >> > @@ -138,6 +138,12 @@ static const struct feat_props { >> >> > >> >> > /* write_msr is used to write out feature MSR register. */ >> >> > void (*write_msr)(unsigned int cos, uint32_t val, enum psr_type >> >> > type); >> >> > + >> >> > +/* >> >> > + * check_val is used to check if input val fulfills SDM >> >> > requirement. >> >> > + * Change it to valid value if SDM allows. >> >> > + */ >> >> > +bool (*check_val)(const struct feat_node *feat, unsigned long >> >> > *val); >> >> >> >> I'm pretty sure I've said so before - "check" to me implies all r/o >> >> inputs. Perhaps sanitize_val() or even just sanitize()? >> >> >> >> And why unsigned long when the only caller has a uint32_t in its >> >> hands? >> >> >> > To be compatible with cat_check_cbm (old name is 'psr_check_cbm' in L2 >> > series), >> > the last parameter type is 'unsigned long'. We have discussed it in L2 >> > patch set >> > v9, patch 10. >> >> Iirc (without checking the old thread) this was for calculations to >> be done as unsigned long ones. If that's the only aspect here, >> then imo this is not a valid reason for the hook's parameter type >> to be unsigned long *. >> > Because below macros used in cat_check_cbm require the input addr to be > unsigned > long, we define the last parameter of cat_check_cbm to be unsigned long. > find_first_bit > find_next_zero_bit > find_next_bit > > If you think the unsigned long is not appropriate for 'check_val', I think I > have to define a local variable in cat_check_cbm to do the convertion. Exactly - the use of unsigned long is specific to this function, not generic for all implementations of the hook. The parameter type change back then was only a simple way to avoid defining another local variable. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-next 2/3] xen/x86: Introduce static inline wrappers for l{idt, gdt, ldt, tr}()
>>> On 12.10.17 at 18:06, wrote: > On 12/10/17 16:53, Jan Beulich wrote: > On 02.10.17 at 18:13, wrote: >>> The triple-fault reboot method stays as is, to avoid the int3 possibly >>> getting >>> moved relative to the lidt. >> Aren't asm volatile()s ordered wrt to one another? > > From the docs > > "Note that the compiler can move even volatile |asm| instructions > relative to other code, including across jump instructions." I had looked at the doc (and this sentence) before replying: It does not make explicit whether two volatile asm()s can be legitimately moved. After all the purpose of the volatile is to deal with resource (register) uses which can't otherwise be expressed to the compiler. The example they give there with the floating point control/status register isn't sufficient, as it doesn't show how an asm() producing and one consuming the resource would interact. But yes, to be on the safe side keeping insn here both in one asm() is certainly the better option. > Also, I seem to recall Tim finding an example where GCC 6 did reorder > two asm volatiles relative to each other, due to their output operands > not being causally linked. Oh, good to know. In which case using a fake operand would help to establish a dependency (like suggested in that PPC example in the doc, albeit partially wrong afaict in that the asm() writing a variable the subsequent statement also write does not make this a valid dependency - the asm() would need to write x or y imo), but of course that wouldn't make things any better for the specific triple fault case here. > On that note however, these should gain memory clobbers to make them > full barriers. l{i,g}dt() are serialising, while nothing good will come > of having a segment register access reordered with respect to l{g,l}dt(). >[...] >> Reviewed-by: Jan Beulich > > Does this still stand in light of the barrier change above? Sure. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.8-testing test] 114384: FAIL
flight 114384 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/114384/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu broken in 114313 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 4 host-install(4) broken in 114313 pass in 114384 test-xtf-amd64-amd64-5 48 xtf/test-hvm64-lbr-tsx-vmentry fail in 114313 pass in 114384 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 114313 pass in 114384 test-armhf-armhf-xl-credit2 12 guest-startfail pass in 114313 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 48 xtf/test-hvm64-lbr-tsx-vmentry fail in 114313 like 114093 test-xtf-amd64-amd64-3 48 xtf/test-hvm64-lbr-tsx-vmentry fail in 114313 like 114173 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 114313 never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 114313 never pass test-xtf-amd64-amd64-4 48 xtf/test-hvm64-lbr-tsx-vmentry fail like 114126 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 114173 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114173 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114173 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114173 test-amd64-amd64-xl-rtds 10 debian-install fail like 114173 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass build-i386-prev 7 xen-build/dist-test fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass build-amd64-prev 7 xen-build/dist-test fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen 9f092f57d2829a271233aef1d1df0bff84275122 baseline version: xen 667f70e658c4c382672056ebaf1505b4c5cdb0aa Last test of basis 114173 2017-10-09 03:27:38 Z4 days Testing same since 114313 2017-10-11 00:46:14 Z
Re: [Xen-devel] [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver
ping On 10/04/2017 09:50 AM, Oleksandr Andrushchenko wrote: gentle reminder On 09/26/2017 02:35 PM, Oleksandr Andrushchenko wrote: Clemens, Sakamoto-san, could you please review the below if you by chance have a minute? Thank you, Oleksandr On 09/19/2017 11:57 AM, Oleksandr Andrushchenko wrote: Hi, all! We did some work on implementing the idea with feedback events from the backend to the frontend. Please see attached the changes to the existing sndif protocol [1]: 1. Introduced a new event channel from back to front 2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS, to be used for sending snd_pcm_period_elapsed at frontend. Sent in bytes, not frames to make the protocol generic and consistent) 3. New request for playback/capture control (XENSND_OP_TRIGGER) with start/pause/stop/resume sub-ops. The implementation we have showed that this is sufficient to successfully play/capture w/o using emulated interrupts. Clemens, Sakamoto-san, could you please review the changes and confirm that these are ok to be upstreamed to the sndif protocol and are enough for the frontend driver we want to upstream (we have it implemented, just need to make sure the general approach is accepted by the ALSA community). Thank you very much for your time, Oleksandr Andrushchenko Oleksandr Grytsov [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h?h=v4.14-rc1 On 09/12/2017 10:52 AM, Oleksandr Grytsov wrote: On Tue, Sep 5, 2017 at 10:24 AM, Clemens Ladisch wrote: Oleksandr Andrushchenko wrote: We understand that emulated interrupt on the frontend side is completely not acceptable Allow me to expand on that: Proper synchronization requires that the exact position is communicated, not estimated. Just because the nominal rate of the stream is known does not imply that you know the actual rate. Forget for the moment that there even is a nominal rate; assume that it works like, e.g., a storage controller, and that you can know that a DMA buffer was consumed by the device only after it has told you. It's possible and likely that there is a latency when reporting the stream position, but that is still better than guessing what the DMA is doing. (You would never just try to guess when writing data to disk, would you?) and definitely we need to provide some feedback mechanism from Dom0 to DomU. In our case it is technically impossible to provide precise period interrupt (mostly because our backend is a user space application). As far as I can see, all audio APIs (ALSA, PulseAudio, etc.) have poll() or callbacks or similar mechanisms to inform you when new data can be written, and always allow to query the current position. [...] ok, so the main concern here is that we cannot properly synchronize Dom0-DomU. If we put this apart for a second are there any other concerns on having ALSA frontend driver? If not, can we have the driver with timer implementation upstreamed as experimental until we have some acceptable synchronization solution? This will allow broader audience to try and feel the solution and probably contribute? I doubt that the driver architecture will stay completely the same, so I do not think that this experimental driver would demonstrate how the solution would feel. As the first step, I would suggest creating a driver with proper synchronization, even if it has high latency. Reducing the latency would then be 'just' an optimization. Regards, Clemens Definitely feedback from the backend side is required. Currently we are working on synchronized version on the backend and frontend side. We will be back once we have the solution. Thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [GIT PULL] xen: fixes for 4.14 rc5
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.14c-rc5-tag xen: fixes for 4.14 rc5 It contains a minor fix correcting the cpu hotplug name for Xen guests. Thanks. Juergen arch/x86/xen/enlighten.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Zhenzhong Duan (1): xen/vcpu: Use a unified name about cpu hotplug state for pv and pvhvm ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 114395: tolerable all pass - PUSHED
flight 114395 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/114395/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 114088 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 114088 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 114088 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt 764d7d0915422bf8d3608bff078c6c1480d25730 baseline version: libvirt c44b29aacb6a3f445ab06d61899a0308b9d6d0d3 Last test of basis 114088 2017-10-07 04:21:11 Z6 days Failing since114325 2017-10-11 04:28:10 Z2 days2 attempts Testing same since 114395 2017-10-12 04:20:04 Z1 days1 attempts People who touched revisions under test: Andrea Bolognani Daniel P. Berrange Jiri Denemark Ján Tomko Kothapally Madhu Pavan Marc Hartmayer 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-amd64-i386-libvirt-qcow2pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : + branch=libvirt + revision=764d7d0915422bf8d3608bff078c6c1480d25730 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig export PERLLIB=.:. PERLLIB=.:. +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/oss
[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-xl-pvh-amd
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-pvh-amd testid guest-start Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.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: c7dfe4ac58dd9c8678126b78da961b233a49f3f9 Bug not present: 3c44f8ed44ab559c7e5b58316751bea53adfd83b Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/114449/ commit c7dfe4ac58dd9c8678126b78da961b233a49f3f9 Author: Roger Pau Monne Date: Fri Sep 22 16:25:06 2017 +0100 xl: introduce a domain type option Introduce a new type option to xl configuration files in order to specify the domain type. This supersedes the current builder option. The new option is documented in the xl.cfg man page, and the previous builder option is marked as deprecated. Signed-off-by: Roger Pau Monné Acked-by: Ian Jackson For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-amd64-xl-pvh-amd.guest-start.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-amd64-xl-pvh-amd.guest-start --summary-out=tmp/114449.bisection-summary --basis-template=114042 --blessings=real,real-bisect qemu-mainline test-amd64-amd64-xl-pvh-amd guest-start Searching for failure / basis pass: 114279 fail [host=pinot0] / 114042 [host=rimava0] 113974 [host=pinot1] 113964 [host=merlot1] 113876 [host=pinot1] 113864 [host=nocera1] 113852 [host=rimava1] 113839 [host=merlot0] 113817 [host=rimava0] 113784 [host=nocera0] 113780 [host=pinot1] 113769 [host=merlot1] 113743 [host=nocera1] 113711 [host=rimava1] 113689 [host=pinot1] 113659 [host=rimava0] 113646 [host=nocera1] 113626 [host=merlot1] 113613 ok. Failure / basis pass flights: 114279 / 113613 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: xen git://xenbits.xen.org/xen.git Latest 1852eae92c460813692808234da35d142a405ab7 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 530049bc1dcc24c1178a29d99ca08b6dd08413e0 dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e Basis pass 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d c51700273ad9802a21c19f8d2b4bcb67c38e74ac 16b1414de91b5a82a0996c67f6db3af7d7e32873 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae-1852eae92c460813692808234da35d142a405ab7 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d git://git.qemu.org/qemu.git#c51700273ad9802a21c19f8d2b4bcb67c38e74ac-530049bc1dcc24c1178a29d99ca08b6dd08413e0 git://xenbits.xen.org/xen.git#16b1414de91b5a82a0996c67f6db3af7d7e32873-dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e Loaded 8949 nodes in revision graph Searching for test results: 113613 pass 4ad5dcaca7428dd2bc1a6a40c948e3799c1e27ae c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d c51700273ad9802a21c19f8d2b4bcb67c38e74ac 16b1414de91b5a82a0996c67f6db3af7d7e32873 113659 [host=rimava0] 113646 [host=nocera1] 113626 [host=merlot1] 113689 [host=pinot1] 113711 [host=rimava1] 113769 [host=merlot1] 113784 [host=nocera0] 113743 [host=nocera1] 113780 [host=pinot1] 113817 [host=rimava0] 113839 [host=merlot0] 113852 [host=rimava1] 113876 [host=pinot1] 113864 [host=nocera1] 113964 [host=merlot1] 113974 [host=pinot1] 114042 [host=rimava0] 114083 fail 1852eae92c460813692808234da35d142a405ab7 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 530049bc1dcc24c1178a29d99ca08b6dd08413e0 dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e 114106 fail 1852eae92c460813692808234da35d142a405ab7 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 530049bc1dcc24c1178a29d99ca08b6dd08413e0 dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e 114148 fail 1852eae92c460813692808234da35d142a405ab7 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 530049bc1dcc24c1178a29d99ca08b6dd08413e0 dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e 1
[Xen-devel] [xen-4.9-testing test] 114372: regressions - FAIL
flight 114372 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/114372/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl broken in 114312 test-armhf-armhf-xl-multivcpu broken in 114312 test-armhf-armhf-libvirt-raw broken in 114312 build-i386-prev 6 xen-build fail in 114312 REGR. vs. 114118 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 4 host-install(4) broken in 114312 pass in 114372 test-armhf-armhf-libvirt-raw 4 host-install(4) broken in 114312 pass in 114372 test-armhf-armhf-xl-multivcpu 4 host-install(4) broken in 114312 pass in 114372 test-armhf-armhf-libvirt 7 xen-boot fail pass in 114312 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install fail pass in 114312 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail pass in 114312 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 114118 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked in 114312 n/a test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 114118 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 114312 like 114091 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 114312 like 114118 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 114312 like 114118 test-armhf-armhf-libvirt13 migrate-support-check fail in 114312 never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail in 114312 never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 114091 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114091 test-amd64-amd64-xl-rtds 10 debian-install fail like 114118 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10
Re: [Xen-devel] [PATCH v6 08/16] x86: implement set value flow for MBA
On 17-10-12 03:43:26, Jan Beulich wrote: > >>> On 12.10.17 at 06:33, wrote: > > On 17-10-11 07:38:52, Jan Beulich wrote: > >> >>> On 08.10.17 at 09:23, wrote: > >> > --- a/xen/arch/x86/psr.c > >> > +++ b/xen/arch/x86/psr.c > >> > @@ -138,6 +138,12 @@ static const struct feat_props { > >> > > >> > /* write_msr is used to write out feature MSR register. */ > >> > void (*write_msr)(unsigned int cos, uint32_t val, enum psr_type > >> > type); > >> > + > >> > +/* > >> > + * check_val is used to check if input val fulfills SDM requirement. > >> > + * Change it to valid value if SDM allows. > >> > + */ > >> > +bool (*check_val)(const struct feat_node *feat, unsigned long *val); > >> > >> I'm pretty sure I've said so before - "check" to me implies all r/o > >> inputs. Perhaps sanitize_val() or even just sanitize()? > >> > >> And why unsigned long when the only caller has a uint32_t in its > >> hands? > >> > > To be compatible with cat_check_cbm (old name is 'psr_check_cbm' in L2 > > series), > > the last parameter type is 'unsigned long'. We have discussed it in L2 > > patch set > > v9, patch 10. > > Iirc (without checking the old thread) this was for calculations to > be done as unsigned long ones. If that's the only aspect here, > then imo this is not a valid reason for the hook's parameter type > to be unsigned long *. > Because below macros used in cat_check_cbm require the input addr to be unsigned long, we define the last parameter of cat_check_cbm to be unsigned long. find_first_bit find_next_zero_bit find_next_bit If you think the unsigned long is not appropriate for 'check_val', I think I have to define a local variable in cat_check_cbm to do the convertion. > Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 114368: regressions - trouble: blocked/broken/fail/pass
flight 114368 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/114368/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf 4 host-install(4)broken REGR. vs. 114034 test-amd64-amd64-xl-pvh-intel 12 guest-start fail REGR. vs. 114034 test-amd64-amd64-xl-pvh-amd 12 guest-start fail REGR. vs. 114034 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail in 114133 pass in 114368 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail pass in 114133 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 saverestore-support-check fail in 114133 like 114034 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 114133 like 114034 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 114133 like 114034 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 114133 never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 114133 never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 114133 never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 114133 never pass test-armhf-armhf-xl 13 migrate-support-check fail in 114133 never pass test-armhf-armhf-libvirt13 migrate-support-check fail in 114133 never pass test-armhf-armhf-xl 14 saverestore-support-check fail in 114133 never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 114133 never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 114133 never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 114133 never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 114133 never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 114133 never pass test-armhf-armhf-xl-rtds13 migrate-support-check fail in 114133 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 114133 never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 114133 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 114133 never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 114133 never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114034 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114034 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114034 test-amd64-amd64-xl-rtds 10 debian-install fail like 114034 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-i
Re: [Xen-devel] [PATCH 1/2] x86/boot: fix early error display
> On Oct 12, 2017, at 4:27 PM, Daniel Kiper wrote: > >> On Thu, Oct 12, 2017 at 03:50:06PM -0500, Doug Goldstein wrote: >> From: David Esler >> >> In 9180f5365524 a change was made to the send_chr function to take in >> C-strings and print out a character at a time until a NULL was >> encountered. However there is no code to increment the current character >> position resulting in an endless loop of the first character. This adds >> a simple increment. >> >> Reviewed-by: Doug Goldstein >> Signed-off-by: David Esler >> --- >> xen/arch/x86/boot/head.S | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S >> index fd6fc337fe..f48bbbd2e5 100644 >> --- a/xen/arch/x86/boot/head.S >> +++ b/xen/arch/x86/boot/head.S >> @@ -174,6 +174,7 @@ not_multiboot: >> mov sym_esi(vga_text_buffer),%edi >> .Lsend_chr: >> mov (%esi),%bl >> +inc %esi >> test%bl,%bl# Terminate on '\0' sentinel >> je .Lhalt >> mov $0x3f8+5,%dx # UART Line Status Register > > I have a feeling that you have tested this on machine without > VGA text buffer available. Then your fix works. However, if VGA > text buffer is available then %esi is increased twice. First time > by inc here and once again by movsb below. So, I think that the > issue have to be fixed in a bit different way. > > Daniel Correct. It was an EFI machine with serial only where I saw it in action. David has put together a new change and I’ll get it submitted tomorrow. — Doug ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 114362: tolerable FAIL - PUSHED
flight 114362 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/114362/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 114297 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 114297 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114297 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114297 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114297 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114297 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 114297 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 114297 test-amd64-amd64-xl-rtds 10 debian-install fail like 114297 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 114297 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linuxa957fd420ca8774f1a6708c64a867f056e67c46e baseline version: linux7056964a85031f42e2360617b14272593729ce1b Last test of basis 114297 2017-10-10 20:24:19 Z2 days Testing same since 114362 2017-10-11 17:01:10 Z1 days1 attempts People who touched revisions under test: Colin Ian King Eric Biggers Eryu Guan J. Bruce Fields Jeff Layton Kees Cook Linus Torvalds 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
[Xen-devel] [qemu-upstream-unstable bisection] complete test-amd64-amd64-xl-pvh-intel
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-pvh-intel testid guest-start Tree: linux git://xenbits.xen.org/linux-pvops.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: c7dfe4ac58dd9c8678126b78da961b233a49f3f9 Bug not present: 3c44f8ed44ab559c7e5b58316751bea53adfd83b Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/114437/ commit c7dfe4ac58dd9c8678126b78da961b233a49f3f9 Author: Roger Pau Monne Date: Fri Sep 22 16:25:06 2017 +0100 xl: introduce a domain type option Introduce a new type option to xl configuration files in order to specify the domain type. This supersedes the current builder option. The new option is documented in the xl.cfg man page, and the previous builder option is marked as deprecated. Signed-off-by: Roger Pau Monné Acked-by: Ian Jackson For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream-unstable/test-amd64-amd64-xl-pvh-intel.guest-start.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/qemu-upstream-unstable/test-amd64-amd64-xl-pvh-intel.guest-start --summary-out=tmp/114437.bisection-summary --basis-template=114029 --blessings=real,real-bisect qemu-upstream-unstable test-amd64-amd64-xl-pvh-intel guest-start Searching for failure / basis pass: 114273 fail [host=chardonnay1] / 114029 [host=elbling1] 114014 [host=nobling1] 113699 [host=chardonnay0] 113668 [host=godello1] 113359 [host=huxelrebe0] 113162 [host=elbling1] 113153 ok. Failure / basis pass flights: 114273 / 113153 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.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 1852eae92c460813692808234da35d142a405ab7 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 5cd7ce5dde3f228b3b669ed9ca432f588947bd40 dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e Basis pass 458ca52f1564938c158d271f45bce0bc6ede2b3f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d c349189772cec43498b0bec8a84146f10b8937af ee2c1fc48ac14a4c8b9eb9224753591fa5e7 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#458ca52f1564938c158d271f45bce0bc6ede2b3f-1852eae92c460813692808234da35d142a405ab7 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d git://xenbits.xen.org/qemu-xen.git#c349189772cec43498b0bec8a84146f10b8937af-5cd7ce5dde3f228b3b669ed9ca432f588947bd40 git://xenbits.xen.org/xen.git#ee2c1fc48ac14a4c8b9eb9224753591fa5e7-dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e Loaded 7962 nodes in revision graph Searching for test results: 113162 [host=elbling1] 113153 pass 458ca52f1564938c158d271f45bce0bc6ede2b3f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d c349189772cec43498b0bec8a84146f10b8937af ee2c1fc48ac14a4c8b9eb9224753591fa5e7 113359 [host=huxelrebe0] 113668 [host=godello1] 113699 [host=chardonnay0] 114029 [host=elbling1] 114014 [host=nobling1] 114328 pass 458ca52f1564938c158d271f45bce0bc6ede2b3f c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d c349189772cec43498b0bec8a84146f10b8937af ee2c1fc48ac14a4c8b9eb9224753591fa5e7 114273 fail 1852eae92c460813692808234da35d142a405ab7 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 5cd7ce5dde3f228b3b669ed9ca432f588947bd40 dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e 114406 fail d59dabdc4cb380b79c965af28cd4ba001f04834b c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 0b157f8d977a9425e2d8d510aa011c5d4f3ec247 6ed3559f0666b7a5436ae5a73af48e57425fc452 114437 fail d59dabdc4cb380b79c965af28cd4ba001f04834b c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 0b157f8d977a9425e2d8d510aa011c5d4f3ec247 c7dfe4ac58dd9c8678126b78da961b233a49f3f9 114413 blocked d59dabdc4cb380b79c965af28cd4ba001f04834b c530a75c1e6a472b0eb9558310b518f0dfcd8860 8051789e982499050680a26febeada7467e18a8d 0b157f8d977a9425e2d8d510aa011c5d4f3ec247 52d
[Xen-devel] [xen-unstable test] 114357: regressions - FAIL
flight 114357 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/114357/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-cubietruck 17 guest-start.2 fail REGR. vs. 114204 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 12 guest-start fail like 114204 test-amd64-amd64-xl-pvh-amd 12 guest-start fail like 114204 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 114204 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 114204 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114204 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114204 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 114204 test-amd64-amd64-xl-rtds 10 debian-install fail like 114204 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: xen 3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a baseline version: xen 572a78190403e5f2acbd01fa72c35fafe9700169 Last test of basis 114204 2017-10-09 19:19:08 Z3 days Failing since114288 2017-10-10 17:02:59 Z2 days2 attempts Testing same since 114357 2017-10-11 14:33:38 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Julien Grall Julien Grall Kevin Tian Manish Jaggi Stefano Stabellini Tim Deegan Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386
Re: [Xen-devel] [PATCH 2/2] x86/boot: rename send_chr to print_err
On Thu, Oct 12, 2017 at 09:56:01PM +0100, Andrew Cooper wrote: > On 12/10/2017 21:50, Doug Goldstein wrote: > > From: David Esler > > > > The send_chr function sends an entire C-string and not one character and > > doesn't necessarily just send it over the serial UART anymore so rename > > it to print_err so that its closer in name to what it does. > > > > Reviewed-by: Doug Goldstein > > Signed-off-by: David Esler > > Reviewed-by: Andrew Cooper Reviewed-by: Daniel Kiper Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/boot: fix early error display
On Thu, Oct 12, 2017 at 03:50:06PM -0500, Doug Goldstein wrote: > From: David Esler > > In 9180f5365524 a change was made to the send_chr function to take in > C-strings and print out a character at a time until a NULL was > encountered. However there is no code to increment the current character > position resulting in an endless loop of the first character. This adds > a simple increment. > > Reviewed-by: Doug Goldstein > Signed-off-by: David Esler > --- > xen/arch/x86/boot/head.S | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S > index fd6fc337fe..f48bbbd2e5 100644 > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -174,6 +174,7 @@ not_multiboot: > mov sym_esi(vga_text_buffer),%edi > .Lsend_chr: > mov (%esi),%bl > +inc %esi > test%bl,%bl# Terminate on '\0' sentinel > je .Lhalt > mov $0x3f8+5,%dx # UART Line Status Register I have a feeling that you have tested this on machine without VGA text buffer available. Then your fix works. However, if VGA text buffer is available then %esi is increased twice. First time by inc here and once again by movsb below. So, I think that the issue have to be fixed in a bit different way. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/2] ARM: ACPI: IORT: Hide SMMU from hardware domain's IORT table
On 10/12/2017 5:14 PM, Julien Grall wrote: On 12/10/17 12:22, Manish Jaggi wrote: Hi Julien, Why do you omit parts of mail where I have asked a question , please avoid skiping that removes the context. I believe I answered it just after because you asked twice the same thing. So may I dropped the context but the answer was there... For your convenience here the replicated answer. "Why? The generation of IORT is fairly standalone. And again, this was suggestion to share in the future and an expectation for this series. What I care the most is the generation to be fully separated from the rest." I raised a valid point and it was totally ignored and you asked me to explain the rationale on a later point. So if you choose to ignore my first point, how can I put any point. Well, maybe you should read the e-mail more carefully because your point have been addressed. If they are not, then please say it rather than accusing the reviewers on spending not enough time on your series... [...] Now if you see both the codes are quite similar and there is redundancy in libxl and in xen code for preparing ACPI tables for dom0 and domU. The point I am raising is quite clear, if all other tables like MADT, XSDT, RSDP, GTDT etc does not share a common generation code with xen what is so special about IORT. Either we move all generation into a common code or keep redundancy for IORT. I hope I have shown the code and made the point quite clear. Please provide a technical answer rather than a simple "Why". Why do you still continue arguing on how this is going to interact with libxl when your only work now (as I stated in every single e-mail) is for Dom0. If the generation is generic enough, it will require little code to interface. After all, you only need: - informations (e.g DeviceID, MasterID...) - buffer for writing the generated IORT So now it is maybe time for you to suggest an interface we can discuss on. Sure. A quick draft is shared on mailing list. [1] [1] https://marc.info/?l=xen-devel&m=150784236208192&w=2 Cheers, ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.
ACPI/IORT Support in Xen. -- I had sent out patch series [0] to hide smmu from Dom0 IORT. Extending the scope and including all that is required to support ACPI/IORT in Xen. Presenting for review first _draft_ of design of ACPI/IORT support in Xen. Not complete though. Discussed is the parsing and generation of IORT table for Dom0 and DomUs. It is proposed that IORT be parsed and the information in saved into xen data-structure say host_iort_struct and is reused by all xen subsystems like ITS / SMMU etc. Since this is first draft is open to technical comments, modifications and suggestions. Please be open and feel free to add any missing points / additions. 1. What is IORT. What are its components ? 2. Current Support in Xen 3. IORT for Dom0 4. IORT for DomU 5. Parsing of IORT in Xen 6. Generation of IORT 7. Future Work and TODOs 1. What is IORT. What are its components ? IORT refers to Input Output remapping table. It is essentially used to find information about the IO topology (PCIRC-SMMU-ITS) and relationships between devices. A general structure of IORT is has nodes which have information about PCI RC, SMMU, ITS and Platform devices. Using an IORT table relationship between RID -> StreamID -> DeviceId can be obtained. More specifically which device is behind which SMMU and which interrupt controller, this topology is described in IORT Table. RID is a requester ID in PCI context, StreamID is the ID of the device in SMMU context, DeviceID is the ID programmed in ITS. For a non-pci device RID could be simply an ID. Each iort_node contains an ID map array to translate from one ID into another. IDmap Entry {input_range, output_range, output_node_ref, id_count} This array is present in PCI RC node,SMMU node, Named component node etc and can reference to a SMMU or ITS node. 2. Current Support of IORT --- Currently Xen passes host IORT table to dom0 without any modifications. For DomU no IORT table is passed. 3. IORT for Dom0 - IORT for Dom0 is prepared by xen and it is fairly similar to the host iort. However few nodes could be removed removed or modified. For instance - host SMMU nodes should not be present - ITS group nodes are same as host iort but, no stage2 mapping is done for them. - platform nodes (named components) may be selectively present depending on the case where xen is using some. This could be controlled by xen command line. - More items : TODO 4. IORT for DomU - IORT for DomU is generated by the toolstack. IORT topology is different when DomU supports device passthrough. At a minimum domU IORT should include a single PCIRC and ITS Group. Similar PCIRC can be added in DSDT. Additional node can be added if platform device is assigned to domU. No extra node should be required for PCI device pass-through. It is proposed that the idrange of PCIRC and ITS group be constant for domUs. In case if PCI PT,using a domctl toolstack can communicate physical RID: virtual RID, deviceID: virtual deviceID to xen. It is assumed that domU PCI Config access would be trapped in Xen. The RID at which assigned device is enumerated would be the one provided by the domctl, domctl_set_deviceid_mapping TODO: device assign domctl i/f. Note: This should suffice the virtual deviceID support pointed by Andre. [4] We might not need this domctl if assign_device hypercall is extended to provide this information. 5. Parsing of IORT in Xen -- IORT nodes can be saved in structures so that IORT table parsing can be done once and is reused by all xen subsystems like ITS / SMMU etc, domain creation. Proposed are the structures to hold IORT information, very similar to ACPI structures. iort_id_map { range_t input_range; range_t output_range; void *output_reference; ... } =>output_reference points to object of iort_node. struct iort_node { struct list_head id_map; void *context; struct list_head list; } => context could be a reference to acpi_iort_node. struct iort_table_struct { struct list_head pci_rc_nodes; struct list_head smmu_nodes; struct list_head plat_devices; struct list_head its_group; } This structure is created at the point IORT table is parsed say from acpi_iort_init. It is proposed to use this structure information in iort_init_platform_devices. [2] [RFC v2 4/7] ACPI: arm: Support for IORT 6. IORT Generation --- There would be a common code to generate IORT table from iort_table_struct. a. For Dom0 the structure (iort_table_struct) be modified to remove smmu nodes and update id_mappings. PCIRC idmap -> output refrence to ITS group. (RID -> DeviceID). TODO: Describe algo in update_id_mapping function to map RID -> DeviceID used in my earlier patch [3] b. For DomU - iort_table_struct would have minimal 2 nodes (1 PCIRC an
Re: [Xen-devel] [PATCH 2/2] x86/boot: rename send_chr to print_err
On 12/10/2017 21:50, Doug Goldstein wrote: > From: David Esler > > The send_chr function sends an entire C-string and not one character and > doesn't necessarily just send it over the serial UART anymore so rename > it to print_err so that its closer in name to what it does. > > Reviewed-by: Doug Goldstein > Signed-off-by: David Esler Reviewed-by: Andrew Cooper This should also be included in 4.10 IMO. > --- > xen/arch/x86/boot/head.S | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S > index f48bbbd2e5..22348b1bbe 100644 > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -161,7 +161,7 @@ not_multiboot: > */ > add $sym_offs(.Lbad_ldr_nbs),%esi # Error message > xor %edi,%edi # No VGA text buffer > -jmp .Lsend_chr > +jmp .Lprint_err > .Lmb2_efi_ia_32: > /* > * Here we are on EFI IA-32 platform. Then reliable vga_text_buffer > zap is > @@ -169,10 +169,10 @@ not_multiboot: > */ > add $sym_offs(.Lbad_efi_msg),%esi # Error message > xor %edi,%edi # No VGA text buffer > -jmp .Lsend_chr > +jmp .Lprint_err > .Lget_vtb: > mov sym_esi(vga_text_buffer),%edi > -.Lsend_chr: > +.Lprint_err: > mov (%esi),%bl > inc %esi > test%bl,%bl# Terminate on '\0' sentinel > @@ -185,11 +185,11 @@ not_multiboot: > mov %bl,%al > out %al,%dx# Send a character over the serial line > test%edi,%edi # Is the VGA text buffer available? > -jz .Lsend_chr > +jz .Lprint_err > movsb # Write a character to the VGA text buffer > mov $7,%al > stosb # Write an attribute to the VGA text buffer > -jmp .Lsend_chr > +jmp .Lprint_err > .Lhalt: hlt > jmp .Lhalt > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/boot: fix early error display
On 12/10/2017 21:50, Doug Goldstein wrote: > From: David Esler > > In 9180f5365524 a change was made to the send_chr function to take in > C-strings and print out a character at a time until a NULL was > encountered. However there is no code to increment the current character > position resulting in an endless loop of the first character. This adds > a simple increment. > > Reviewed-by: Doug Goldstein > Signed-off-by: David Esler Reviewed-by: Andrew Cooper CC'ing Julien as release manager. This should be included in 4.10 IMO, and is a backport candidate. > --- > xen/arch/x86/boot/head.S | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S > index fd6fc337fe..f48bbbd2e5 100644 > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -174,6 +174,7 @@ not_multiboot: > mov sym_esi(vga_text_buffer),%edi > .Lsend_chr: > mov (%esi),%bl > +inc %esi > test%bl,%bl# Terminate on '\0' sentinel > je .Lhalt > mov $0x3f8+5,%dx # UART Line Status Register ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86/boot: fix early error display
From: David Esler In 9180f5365524 a change was made to the send_chr function to take in C-strings and print out a character at a time until a NULL was encountered. However there is no code to increment the current character position resulting in an endless loop of the first character. This adds a simple increment. Reviewed-by: Doug Goldstein Signed-off-by: David Esler --- xen/arch/x86/boot/head.S | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index fd6fc337fe..f48bbbd2e5 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -174,6 +174,7 @@ not_multiboot: mov sym_esi(vga_text_buffer),%edi .Lsend_chr: mov (%esi),%bl +inc %esi test%bl,%bl# Terminate on '\0' sentinel je .Lhalt mov $0x3f8+5,%dx # UART Line Status Register -- 2.13.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/boot: rename send_chr to print_err
From: David Esler The send_chr function sends an entire C-string and not one character and doesn't necessarily just send it over the serial UART anymore so rename it to print_err so that its closer in name to what it does. Reviewed-by: Doug Goldstein Signed-off-by: David Esler --- xen/arch/x86/boot/head.S | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index f48bbbd2e5..22348b1bbe 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -161,7 +161,7 @@ not_multiboot: */ add $sym_offs(.Lbad_ldr_nbs),%esi # Error message xor %edi,%edi # No VGA text buffer -jmp .Lsend_chr +jmp .Lprint_err .Lmb2_efi_ia_32: /* * Here we are on EFI IA-32 platform. Then reliable vga_text_buffer zap is @@ -169,10 +169,10 @@ not_multiboot: */ add $sym_offs(.Lbad_efi_msg),%esi # Error message xor %edi,%edi # No VGA text buffer -jmp .Lsend_chr +jmp .Lprint_err .Lget_vtb: mov sym_esi(vga_text_buffer),%edi -.Lsend_chr: +.Lprint_err: mov (%esi),%bl inc %esi test%bl,%bl# Terminate on '\0' sentinel @@ -185,11 +185,11 @@ not_multiboot: mov %bl,%al out %al,%dx# Send a character over the serial line test%edi,%edi # Is the VGA text buffer available? -jz .Lsend_chr +jz .Lprint_err movsb # Write a character to the VGA text buffer mov $7,%al stosb # Write an attribute to the VGA text buffer -jmp .Lsend_chr +jmp .Lprint_err .Lhalt: hlt jmp .Lhalt -- 2.13.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 15/27] compiler: Option to default to hidden symbols
On Wed, Oct 11, 2017 at 01:30:15PM -0700, Thomas Garnier wrote: > Provide an option to default visibility to hidden except for key > symbols. This option is disabled by default and will be used by x86_64 > PIE support to remove errors between compilation units. > > The default visibility is also enabled for external symbols that are > compared as they maybe equals (start/end of sections). In this case, > older versions of GCC will remove the comparison if the symbols are > hidden. This issue exists at least on gcc 4.9 and before. > > Signed-off-by: Thomas Garnier <-- snip --> > diff --git a/arch/x86/kernel/cpu/microcode/core.c > b/arch/x86/kernel/cpu/microcode/core.c > index 86e8f0b2537b..8f021783a929 100644 > --- a/arch/x86/kernel/cpu/microcode/core.c > +++ b/arch/x86/kernel/cpu/microcode/core.c > @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void) > return *res; > } > > -extern struct builtin_fw __start_builtin_fw[]; > -extern struct builtin_fw __end_builtin_fw[]; > +extern struct builtin_fw __start_builtin_fw[] __default_visibility; > +extern struct builtin_fw __end_builtin_fw[] __default_visibility; > > bool get_builtin_firmware(struct cpio_data *cd, const char *name) > { <-- snip --> > diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h > index e5da44eddd2f..1aa5d6dac9e1 100644 > --- a/include/asm-generic/sections.h > +++ b/include/asm-generic/sections.h > @@ -30,6 +30,9 @@ > * __irqentry_text_start, __irqentry_text_end > * __softirqentry_text_start, __softirqentry_text_end > */ > +#ifdef CONFIG_DEFAULT_HIDDEN > +#pragma GCC visibility push(default) > +#endif > extern char _text[], _stext[], _etext[]; > extern char _data[], _sdata[], _edata[]; > extern char __bss_start[], __bss_stop[]; > @@ -46,6 +49,9 @@ extern char __softirqentry_text_start[], > __softirqentry_text_end[]; > > /* Start and end of .ctors section - used for constructor calls. */ > extern char __ctors_start[], __ctors_end[]; > +#ifdef CONFIG_DEFAULT_HIDDEN > +#pragma GCC visibility pop > +#endif > > extern __visible const void __nosave_begin, __nosave_end; > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > index e95a2631e545..6997716f73bf 100644 > --- a/include/linux/compiler.h > +++ b/include/linux/compiler.h > @@ -78,6 +78,14 @@ extern void __chk_io_ptr(const volatile void __iomem *); > #include > #endif > > +/* Useful for Position Independent Code to reduce global references */ > +#ifdef CONFIG_DEFAULT_HIDDEN > +#pragma GCC visibility push(hidden) > +#define __default_visibility __attribute__((visibility ("default"))) Does this still work with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION ? > +#else > +#define __default_visibility > +#endif > + > /* > * Generic compiler-dependent macros required for kernel > * build go below this comment. Actual compiler/compiler version > diff --git a/init/Kconfig b/init/Kconfig > index ccb1d8daf241..b640201fcff7 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1649,6 +1649,13 @@ config PROFILING > config TRACEPOINTS > bool > > +# > +# Default to hidden visibility for all symbols. > +# Useful for Position Independent Code to reduce global references. > +# > +config DEFAULT_HIDDEN > + bool Note it is default. Has 0-day ran through this git tree? It should be easy to get it added for testing. Also, even though most changes are x86 based there are some generic changes and I'd love a warm fuzzy this won't break odd / random builds. Although 0-day does cover a lot of test cases, it only has limited run time tests. There are some other test beds which also cover some more obscure architectures. Having a test pass on Guenter's test bed would be nice to see. For that please coordinate with Guenter if he's willing to run this a test for you. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On 10/12/2017 03:27 PM, Andrew Cooper wrote: > On 12/10/17 20:11, Boris Ostrovsky wrote: >> On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >>> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: > #ifdef CONFIG_PARAVIRT > +/* > + * Paravirt alternatives are applied much earlier than normal > alternatives. > + * They are only applied when running on a hypervisor. They replace some > + * native instructions with calls to pv ops. > + */ > +void __init apply_pv_alternatives(void) > +{ > + setup_force_cpu_cap(X86_FEATURE_PV_OPS); Not for Xen HVM guests. >>> From what I can tell, HVM guests still use pv_time_ops and >>> pv_mmu_ops.exit_mmap, right? >>> > + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end); > +} This is a problem (at least for Xen PV guests): apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death. >>> Ah, right. >>> It might be possible not to turn off/on the interrupts in this particular case since the guest probably won't be able to handle an interrupt at this point anyway. >>> Yeah, that should work. For Xen and for the other hypervisors, this is >>> called well before irq init, so interrupts can't be handled yet anyway. >> There is also another problem: >> >> [1.312425] general protection fault: [#1] SMP >> [1.312901] Modules linked in: >> [1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6 >> [1.313878] task: 88003e2c task.stack: c938c000 >> [1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5 >> [1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046 >> [1.315336] RAX: 000c RBX: 55f550168040 RCX: >> 7fcfc959f59a >> [1.315827] RDX: RSI: RDI: >> >> [1.316315] RBP: 000a R08: 037f R09: >> 0064 >> [1.316805] R10: 1f89cbf5 R11: 88003e2c R12: >> 7fcfc958ad60 >> [1.317300] R13: R14: 55f550185954 R15: >> 1000 >> [1.317801] FS: () GS:88003f80() >> knlGS: >> [1.318267] CS: e033 DS: ES: CR0: 80050033 >> [1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4: >> 00042660 >> [1.319235] Call Trace: >> [1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48 >> 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00 >> 00 50 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5 >> [1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: c938ff50 >> [1.344255] ---[ end trace d7cb8cd6cd7c294c ]--- >> [1.345009] Kernel panic - not syncing: Attempted to kill init! >> exitcode=0x000b >> >> >> All code >> >>0:51 push %rcx >>1:50 push %rax >>2:57 push %rdi >>3:56 push %rsi >>4:52 push %rdx >>5:51 push %rcx >>6:6a dapushq $0xffda >>8:41 50push %r8 >>a:41 51push %r9 >>c:41 52push %r10 >>e:41 53push %r11 >> 10:48 83 ec 30 sub$0x30,%rsp >> 14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11 >> 1b:00 00 >> 1d:41 f7 03 df 39 08 90 testl $0x900839df,(%r11) >> 24:0f 85 a5 00 00 00jne0xcf >> 2a:50 push %rax >> 2b:*ff 15 9c 95 d0 ffcallq *-0x2f6a64(%rip)# >> 0xffd095cd<-- trapping instruction >> 31:58 pop%rax >> 32:48 3d 4c 01 00 00cmp$0x14c,%rax >> 38:77 0fja 0x49 >> 3a:4c 89 d1 mov%r10,%rcx >> 3d:ff .byte 0xff >> 3e:14 c5adc$0xc5,%al >> >> >> so the original 'cli' was replaced with the pv call but to me the offset >> looks a bit off, no? Shouldn't it always be positive? > callq takes a 32bit signed displacement, so jumping back by up to 2G is > perfectly legitimate. Yes, but ostr@workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath 817365dd t entry_SYSCALL_64_fastpath ostr@workbase> nm vmlinux | grep " pv_irq_ops" 81c2dbc0 D pv_irq_ops ostr@workbase> so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I didn't mean that x86 instruction set doesn't allow negative displacement, I was trying to say that pv_irq_ops always live further down) > > The #GP[0] however means that whatever 8 byte value was found at > -0x2f6a64(%rip) was a non-canonical address. > > One option is that the pvops structure hasn't been initialised
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On 12/10/17 20:11, Boris Ostrovsky wrote: > On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: #ifdef CONFIG_PARAVIRT +/* + * Paravirt alternatives are applied much earlier than normal alternatives. + * They are only applied when running on a hypervisor. They replace some + * native instructions with calls to pv ops. + */ +void __init apply_pv_alternatives(void) +{ + setup_force_cpu_cap(X86_FEATURE_PV_OPS); >>> Not for Xen HVM guests. >> From what I can tell, HVM guests still use pv_time_ops and >> pv_mmu_ops.exit_mmap, right? >> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end); +} >>> This is a problem (at least for Xen PV guests): >>> apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death. >> Ah, right. >> >>> It might be possible not to turn off/on the interrupts in this >>> particular case since the guest probably won't be able to handle an >>> interrupt at this point anyway. >> Yeah, that should work. For Xen and for the other hypervisors, this is >> called well before irq init, so interrupts can't be handled yet anyway. > There is also another problem: > > [1.312425] general protection fault: [#1] SMP > [1.312901] Modules linked in: > [1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6 > [1.313878] task: 88003e2c task.stack: c938c000 > [1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5 > [1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046 > [1.315336] RAX: 000c RBX: 55f550168040 RCX: > 7fcfc959f59a > [1.315827] RDX: RSI: RDI: > > [1.316315] RBP: 000a R08: 037f R09: > 0064 > [1.316805] R10: 1f89cbf5 R11: 88003e2c R12: > 7fcfc958ad60 > [1.317300] R13: R14: 55f550185954 R15: > 1000 > [1.317801] FS: () GS:88003f80() > knlGS: > [1.318267] CS: e033 DS: ES: CR0: 80050033 > [1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4: > 00042660 > [1.319235] Call Trace: > [1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48 > 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00 > 00 50 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5 > [1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: c938ff50 > [1.344255] ---[ end trace d7cb8cd6cd7c294c ]--- > [1.345009] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x000b > > > All code > >0:51 push %rcx >1:50 push %rax >2:57 push %rdi >3:56 push %rsi >4:52 push %rdx >5:51 push %rcx >6:6a dapushq $0xffda >8:41 50push %r8 >a:41 51push %r9 >c:41 52push %r10 >e:41 53push %r11 > 10:48 83 ec 30 sub$0x30,%rsp > 14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11 > 1b:00 00 > 1d:41 f7 03 df 39 08 90 testl $0x900839df,(%r11) > 24:0f 85 a5 00 00 00jne0xcf > 2a:50 push %rax > 2b:*ff 15 9c 95 d0 ffcallq *-0x2f6a64(%rip)# > 0xffd095cd<-- trapping instruction > 31:58 pop%rax > 32:48 3d 4c 01 00 00cmp$0x14c,%rax > 38:77 0fja 0x49 > 3a:4c 89 d1 mov%r10,%rcx > 3d:ff .byte 0xff > 3e:14 c5adc$0xc5,%al > > > so the original 'cli' was replaced with the pv call but to me the offset > looks a bit off, no? Shouldn't it always be positive? callq takes a 32bit signed displacement, so jumping back by up to 2G is perfectly legitimate. The #GP[0] however means that whatever 8 byte value was found at -0x2f6a64(%rip) was a non-canonical address. One option is that the pvops structure hasn't been initialised properly, but an alternative is that the relocation wasn't processed correctly, and the code is trying to reference something which isn't a function pointer. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.10 v2 2/5] tools/dombuilder: Remove clear_page() from xc_dom_boot.c
pfn 0 is a legitimate (albeit unlikely) frame to use, so skipping it is wrong. This behaviour appears to exists simply to cover the fact that zero is the default value of an uninitialised field in dom. ARM already clears the frames at the point that the pfns are allocated, meaning that the added clear_page() is wasteful. Alter x86 to match ARM and clear the page when it is allocated. Signed-off-by: Andrew Cooper Acked-by: Wei Liu Tested-by: Julien Grall --- CC: Ian Jackson CC: Julien Grall --- tools/libxc/xc_dom_arm.c | 3 ++- tools/libxc/xc_dom_boot.c | 26 -- tools/libxc/xc_dom_x86.c | 8 3 files changed, 10 insertions(+), 27 deletions(-) diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index 7c4997a..fce151d 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -91,7 +91,8 @@ static int alloc_magic_pages(struct xc_dom_image *dom) xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn); xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn); xc_clear_domain_page(dom->xch, dom->guest_domid, base + MEMACCESS_PFN_OFFSET); -xc_clear_domain_page(dom->xch, dom->guest_domid, base + VUART_PFN_OFFSET); +xc_clear_domain_page(dom->xch, dom->guest_domid, dom->vuart_gfn); + xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN, dom->console_pfn); xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN, diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c index 40eb518..2e5681d 100644 --- a/tools/libxc/xc_dom_boot.c +++ b/tools/libxc/xc_dom_boot.c @@ -62,25 +62,6 @@ static int setup_hypercall_page(struct xc_dom_image *dom) return rc; } -static int clear_page(struct xc_dom_image *dom, xen_pfn_t pfn) -{ -xen_pfn_t dst; -int rc; - -if ( pfn == 0 ) -return 0; - -dst = xc_dom_p2m(dom, pfn); -DOMPRINTF("%s: pfn 0x%" PRIpfn ", mfn 0x%" PRIpfn "", - __FUNCTION__, pfn, dst); -rc = xc_clear_domain_page(dom->xch, dom->guest_domid, dst); -if ( rc != 0 ) -xc_dom_panic(dom->xch, XC_INTERNAL_ERROR, - "%s: xc_clear_domain_page failed (pfn 0x%" PRIpfn - ", rc=%d)", __FUNCTION__, pfn, rc); -return rc; -} - /* */ @@ -222,13 +203,6 @@ int xc_dom_boot_image(struct xc_dom_image *dom) if ( (rc = dom->arch_hooks->setup_pgtables(dom)) != 0 ) return rc; -if ( (rc = clear_page(dom, dom->console_pfn)) != 0 ) -return rc; -if ( (rc = clear_page(dom, dom->xenstore_pfn)) != 0 ) -return rc; -if ( (rc = clear_page(dom, dom->vuart_gfn)) != 0 ) -return rc; - /* start info page */ if ( dom->arch_hooks->start_info ) dom->arch_hooks->start_info(dom); diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c index 47db218..bff68a0 100644 --- a/tools/libxc/xc_dom_x86.c +++ b/tools/libxc/xc_dom_x86.c @@ -543,10 +543,14 @@ static int alloc_magic_pages_pv(struct xc_dom_image *dom) dom->xenstore_pfn = xc_dom_alloc_page(dom, "xenstore"); if ( dom->xenstore_pfn == INVALID_PFN ) return -1; +xc_clear_domain_page(dom->xch, dom->guest_domid, + xc_dom_p2m(dom, dom->xenstore_pfn)); dom->console_pfn = xc_dom_alloc_page(dom, "console"); if ( dom->console_pfn == INVALID_PFN ) return -1; +xc_clear_domain_page(dom->xch, dom->guest_domid, + xc_dom_p2m(dom, dom->console_pfn)); dom->alloc_bootstack = 1; @@ -696,7 +700,11 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom) special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT); dom->console_pfn = special_pfn(SPECIALPAGE_CONSOLE); +xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn); + dom->xenstore_pfn = special_pfn(SPECIALPAGE_XENSTORE); +xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn); + dom->parms.virt_hypercall = -1; rc = 0; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.10 v2 4/5] tools/dombuilder: Fix asymmetry when setting up console and xenstore rings
libxl always uses xc_dom_gnttab_init(), which internally calls xc_dom_gnttab{_hvm,}_seed() to set up the grants point at the console and xenstore rings. For HVM guests, libxl then asks Xen for the information set up previously, and calls xc_dom_gnttab_hvm_seed() a second time, which is wasteful. ARM construction expects libxl to have set up dom->{console,xenstore}_evtchn earlier, so only actually functions because of this second call. Rationalise everything and make it consistent for all guests. 1) Users of the domain builder are expected to provide dom->{console,xenstore}_{evtchn,domid} unconditionally. This is checked by setting invalid values in xc_dom_allocate(), and checking in xc_dom_boot_image(). 2) For x86 HVM and ARM guests, the event channels are given to Xen at the same time as the ring gfns. ARM already did this, but x86 is updated to match. x86 PV already provides this information in the start_info page. 3) Libxl is updated to drop all relevant functionality from hvm_build_set_params(), and behave consistently with PV guests when it comes to the handling of dom->{console,xenstore}_{evtchn,domid,gfn}. This removes several redundant hypercalls (including a foreign mapping) from the x86 HVM and ARM construction paths. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Acked-by: Wei Liu Tested-by: Julien Grall --- CC: Ian Jackson CC: Julien Grall v2: * use ~0 for INVALID_DOMID to avoid [-Werror,-Wtautological-constant-out-of-range-compare] from Clang * Set errno to EINVAL in xc_dom_check_required_fields() --- tools/libxc/include/xc_dom.h | 12 tools/libxc/xc_dom_arm.c | 2 +- tools/libxc/xc_dom_boot.c | 39 +++ tools/libxc/xc_dom_compat_linux.c | 2 ++ tools/libxc/xc_dom_core.c | 5 + tools/libxc/xc_dom_x86.c | 4 tools/libxl/libxl_dom.c | 28 ++-- tools/libxl/libxl_internal.h | 1 - 8 files changed, 69 insertions(+), 24 deletions(-) diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h index 5907559..a1c3de2 100644 --- a/tools/libxc/include/xc_dom.h +++ b/tools/libxc/include/xc_dom.h @@ -20,6 +20,8 @@ #include #define INVALID_PFN ((xen_pfn_t)-1) +#define INVALID_EVTCHN (~0u) +#define INVALID_DOMID (~0) #define X86_HVM_NR_SPECIAL_PAGES8 #define X86_HVM_END_SPECIAL_REGION 0xff000u @@ -104,10 +106,16 @@ struct xc_dom_image { * Details for the toolstack-prepared rings. * * *_gfn fields are allocated by the domain builder. + * *_{evtchn,domid} fields must be provided by the caller. */ xen_pfn_t console_gfn; xen_pfn_t xenstore_gfn; +unsigned int console_evtchn; +unsigned int xenstore_evtchn; +uint32_t console_domid; +uint32_t xenstore_domid; + /* * initrd parameters as specified in start_info page * Depending on capabilities of the booted kernel this may be a virtual @@ -165,10 +173,6 @@ struct xc_dom_image { /* misc xen domain config stuff */ unsigned long flags; -unsigned int console_evtchn; -unsigned int xenstore_evtchn; -uint32_t console_domid; -uint32_t xenstore_domid; xen_pfn_t shared_info_mfn; xc_interface *xch; diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index 2fe75cd..2134ce4 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -99,7 +99,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom) dom->xenstore_gfn); xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN, base + MEMACCESS_PFN_OFFSET); -/* allocated by toolstack */ + xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_EVTCHN, dom->console_evtchn); xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN, diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c index bbf98b6..75836bd 100644 --- a/tools/libxc/xc_dom_boot.c +++ b/tools/libxc/xc_dom_boot.c @@ -163,6 +163,42 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn, return ptr; } +static int xc_dom_check_required_fields(struct xc_dom_image *dom) +{ +int rc = 0; + +if ( dom->console_evtchn == INVALID_EVTCHN ) +{ +xc_dom_panic(dom->xch, XC_INVALID_PARAM, + "%s: Caller didn't set dom->console_evtchn", __func__); +rc = -1; +} +if ( dom->console_domid == INVALID_DOMID ) +{ +xc_dom_panic(dom->xch, XC_INVALID_PARAM, + "%s: Caller didn't set dom->console_domid", __func__); +rc = -1; +} + +if ( dom->xenstore_evtchn == INVALID_EVTCHN ) +{ +xc_dom_panic(dom->xch, XC_INVALID_PARAM, + "%s: Caller didn't set dom->xenstore_evtchn", __func__); +rc = -1; +} +if ( dom->xenstore_domid == INVALID_DOMID ) +{ +xc_dom_p
[Xen-devel] [PATCH for-4.10 v2 1/5] tools/dombuilder: Drop more PVH v1 leftovers
alloc_magic_pages() is renamed to alloc_magic_pages_pv() to mirror its alloc_magic_pages_hvm() counterpart. Delete a redundant comment, introduce some newlines clarity, and remove a logically dead allocation of shared info. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Acked-by: Wei Liu Tested-by: Julien Grall --- CC: Ian Jackson CC: Julien Grall --- tools/libxc/xc_dom_x86.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c index bac584f..47db218 100644 --- a/tools/libxc/xc_dom_x86.c +++ b/tools/libxc/xc_dom_x86.c @@ -534,24 +534,20 @@ static int alloc_p2m_list_x86_64(struct xc_dom_image *dom) /* */ -static int alloc_magic_pages(struct xc_dom_image *dom) +static int alloc_magic_pages_pv(struct xc_dom_image *dom) { -/* allocate special pages */ dom->start_info_pfn = xc_dom_alloc_page(dom, "start info"); if ( dom->start_info_pfn == INVALID_PFN ) return -1; + dom->xenstore_pfn = xc_dom_alloc_page(dom, "xenstore"); if ( dom->xenstore_pfn == INVALID_PFN ) return -1; + dom->console_pfn = xc_dom_alloc_page(dom, "console"); if ( dom->console_pfn == INVALID_PFN ) return -1; -if ( xc_dom_translated(dom) ) -{ -dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared info"); -if ( dom->shared_info_pfn == INVALID_PFN ) -return -1; -} + dom->alloc_bootstack = 1; return 0; @@ -1756,7 +1752,7 @@ static struct xc_dom_arch xc_dom_32_pae = { .sizeof_pfn = 4, .p2m_base_supported = 0, .arch_private_size = sizeof(struct xc_dom_image_x86), -.alloc_magic_pages = alloc_magic_pages, +.alloc_magic_pages = alloc_magic_pages_pv, .alloc_pgtables = alloc_pgtables_x86_32_pae, .alloc_p2m_list = alloc_p2m_list_x86_32, .setup_pgtables = setup_pgtables_x86_32_pae, @@ -1775,7 +1771,7 @@ static struct xc_dom_arch xc_dom_64 = { .sizeof_pfn = 8, .p2m_base_supported = 1, .arch_private_size = sizeof(struct xc_dom_image_x86), -.alloc_magic_pages = alloc_magic_pages, +.alloc_magic_pages = alloc_magic_pages_pv, .alloc_pgtables = alloc_pgtables_x86_64, .alloc_p2m_list = alloc_p2m_list_x86_64, .setup_pgtables = setup_pgtables_x86_64, -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.10 v2 0/5] tools/dombuilder: Fixes and improvements to grant handling
A git tree version is available: http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/dombuilder-gnt-v2 Changes in v2: Mainly a rebase over c/s 5b42c82f "tools/libxc: Fix domid parameter types", and fixup from review comments. See individual patches for details Andrew Cooper (5): tools/dombuilder: Drop more PVH v1 leftovers tools/dombuilder: Remove clear_page() from xc_dom_boot.c tools/dombuilder: Switch to using gfn terminology for console and xenstore rings tools/dombuilder: Fix asymmetry when setting up console and xenstore rings tools/dombuilder: Prevent failures of xc_dom_gnttab_init() tools/libxc/include/xc_dom.h | 26 ++-- tools/libxc/xc_dom_arm.c | 17 ++--- tools/libxc/xc_dom_boot.c | 126 +++--- tools/libxc/xc_dom_compat_linux.c | 6 +- tools/libxc/xc_dom_core.c | 8 +++ tools/libxc/xc_dom_x86.c | 57 + tools/libxl/libxl_dom.c | 51 ++- tools/libxl/libxl_internal.h | 1 - 8 files changed, 169 insertions(+), 123 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.10 v2 5/5] tools/dombuilder: Prevent failures of xc_dom_gnttab_init()
Recent changes in grant table configuration have caused calls to xc_dom_gnttab_init() to fail if not proceeded with a call to xc_domain_set_gnttab_limits(). This is backwards from the point of view of 3rd party dombuilder users. Add max_{grant,maptrack}_frames parameters to struct xc_dom_image, and require them to be set by callers using xc_dom_gnttab_init(). Libxl, which uses xc_dom_gnttab_init() itself is updated appropriately. Signed-off-by: Andrew Cooper Acked-by: Wei Liu Tested-by: Julien Grall --- CC: Ian Jackson CC: Julien Grall v2: * Set errno to EINVAL if max_{grant,maptrack}_frames are not provided --- tools/libxc/include/xc_dom.h | 4 tools/libxc/xc_dom_boot.c| 16 tools/libxc/xc_dom_core.c| 3 +++ tools/libxl/libxl_dom.c | 12 ++-- 4 files changed, 29 insertions(+), 6 deletions(-) diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h index a1c3de2..5292424 100644 --- a/tools/libxc/include/xc_dom.h +++ b/tools/libxc/include/xc_dom.h @@ -116,6 +116,10 @@ struct xc_dom_image { uint32_t console_domid; uint32_t xenstore_domid; +/* Grant limit configuration; mandatory if calling xc_dom_gnttab_init(). */ +unsigned int max_grant_frames; +unsigned int max_maptrack_frames; + /* * initrd parameters as specified in start_info page * Depending on capabilities of the booted kernel this may be a virtual diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c index 75836bd..7c21fea 100644 --- a/tools/libxc/xc_dom_boot.c +++ b/tools/libxc/xc_dom_boot.c @@ -420,6 +420,22 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid, int xc_dom_gnttab_init(struct xc_dom_image *dom) { +int rc; + +if ( dom->max_grant_frames == -1 || dom->max_maptrack_frames == -1 ) +{ +xc_dom_panic(dom->xch, XC_INVALID_PARAM, + "%s: Caller didn't set grant limit information", __func__); +errno = EINVAL; + +return -1; +} + +if ( (rc = xc_domain_set_gnttab_limits(dom->xch, dom->guest_domid, + dom->max_grant_frames, + dom->max_maptrack_frames)) != 0 ) +return rc; + if ( xc_dom_translated(dom) ) { return xc_dom_gnttab_hvm_seed(dom->xch, dom->guest_domid, dom->console_gfn, dom->xenstore_gfn, diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c index 7087c50..d660651 100644 --- a/tools/libxc/xc_dom_core.c +++ b/tools/libxc/xc_dom_core.c @@ -784,6 +784,9 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch, dom->console_domid = INVALID_DOMID; dom->xenstore_domid = INVALID_DOMID; +dom->max_grant_frames = -1; +dom->max_maptrack_frames = -1; + dom->flags = SIF_VIRT_P2M_4TOOLS; dom->alloc_malloc += sizeof(*dom); diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index fcdeef0..fa5319d 100644 --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -358,12 +358,6 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid, return ERROR_FAIL; } -if (xc_domain_set_gnttab_limits(ctx->xch, domid, info->max_grant_frames, -info->max_maptrack_frames) != 0) { -LOG(ERROR, "Couldn't set grant table limits"); -return ERROR_FAIL; -} - /* * Check if the domain has any CPU or node affinity already. If not, try * to build up the latter via automatic NUMA placement. In fact, in case @@ -815,6 +809,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid, dom->xenstore_domid = state->store_domid; dom->claim_enabled = libxl_defbool_val(info->claim_mode); +dom->max_grant_frames= info->max_grant_frames; +dom->max_maptrack_frames = info->max_maptrack_frames; + if (info->num_vnuma_nodes != 0) { unsigned int i; @@ -1151,6 +1148,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid, dom->xenstore_evtchn = state->store_port; dom->xenstore_domid = state->store_domid; +dom->max_grant_frames= info->max_grant_frames; +dom->max_maptrack_frames = info->max_maptrack_frames; + /* The params from the configuration file are in Mb, which are then * multiplied by 1 Kb. This was then divided off when calling * the old xc_hvm_build_target_mem() which then turned them to bytes. -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.10 v2 3/5] tools/dombuilder: Switch to using gfn terminology for console and xenstore rings
The sole use of xc_dom_translated() and xc_dom_p2m() outside of the domain builder is for libxl_dom() to translate the console and xenstore pfns back into useful values. PV guest pfns are only interesting to the domain builder, and gfns are the address space used by all other hypercalls. Renaming the fields in xc_dom_image is deliberate, as it will cause out-of-tree users of the dombuilder to notice the different semantics. Correct the terminology throughout xc_dom_gnttab{_hvm,}_seed(), which are all using gfns despite the existing variable names. Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Acked-by: Wei Liu Tested-by: Julien Grall --- CC: Ian Jackson CC: Julien Grall v2: * More style fixes --- tools/libxc/include/xc_dom.h | 10 +++-- tools/libxc/xc_dom_arm.c | 12 +-- tools/libxc/xc_dom_boot.c | 45 ++- tools/libxc/xc_dom_compat_linux.c | 4 ++-- tools/libxc/xc_dom_x86.c | 45 --- tools/libxl/libxl_dom.c | 11 +++--- 6 files changed, 63 insertions(+), 64 deletions(-) diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h index cdcdd07..5907559 100644 --- a/tools/libxc/include/xc_dom.h +++ b/tools/libxc/include/xc_dom.h @@ -94,8 +94,6 @@ struct xc_dom_image { struct xc_dom_seg devicetree_seg; struct xc_dom_seg start_info_seg; /* HVMlite only */ xen_pfn_t start_info_pfn; -xen_pfn_t console_pfn; -xen_pfn_t xenstore_pfn; xen_pfn_t shared_info_pfn; xen_pfn_t bootstack_pfn; xen_pfn_t pfn_alloc_end; @@ -103,6 +101,14 @@ struct xc_dom_image { xen_vaddr_t bsd_symtab_start; /* + * Details for the toolstack-prepared rings. + * + * *_gfn fields are allocated by the domain builder. + */ +xen_pfn_t console_gfn; +xen_pfn_t xenstore_gfn; + +/* * initrd parameters as specified in start_info page * Depending on capabilities of the booted kernel this may be a virtual * address or a pfn. Type is neutral and large enough to hold a virtual diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index fce151d..2fe75cd 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -84,19 +84,19 @@ static int alloc_magic_pages(struct xc_dom_image *dom) if ( rc < 0 ) return rc; -dom->console_pfn = base + CONSOLE_PFN_OFFSET; -dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET; +dom->console_gfn = base + CONSOLE_PFN_OFFSET; +dom->xenstore_gfn = base + XENSTORE_PFN_OFFSET; dom->vuart_gfn = base + VUART_PFN_OFFSET; -xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn); -xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn); +xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_gfn); +xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_gfn); xc_clear_domain_page(dom->xch, dom->guest_domid, base + MEMACCESS_PFN_OFFSET); xc_clear_domain_page(dom->xch, dom->guest_domid, dom->vuart_gfn); xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN, -dom->console_pfn); +dom->console_gfn); xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN, -dom->xenstore_pfn); +dom->xenstore_gfn); xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN, base + MEMACCESS_PFN_OFFSET); /* allocated by toolstack */ diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c index 2e5681d..bbf98b6 100644 --- a/tools/libxc/xc_dom_boot.c +++ b/tools/libxc/xc_dom_boot.c @@ -257,24 +257,23 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid) } int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid, - xen_pfn_t console_gmfn, - xen_pfn_t xenstore_gmfn, + xen_pfn_t console_gfn, + xen_pfn_t xenstore_gfn, uint32_t console_domid, uint32_t xenstore_domid) { - -xen_pfn_t gnttab_gmfn; +xen_pfn_t gnttab_gfn; grant_entry_v1_t *gnttab; -gnttab_gmfn = xc_dom_gnttab_setup(xch, domid); -if ( gnttab_gmfn == -1 ) +gnttab_gfn = xc_dom_gnttab_setup(xch, domid); +if ( gnttab_gfn == -1 ) return -1; gnttab = xc_map_foreign_range(xch, domid, PAGE_SIZE, PROT_READ|PROT_WRITE, - gnttab_gmfn); + gnttab_gfn); if ( gnttab == NULL ) { xc_dom_panic(xch, XC_INTERNAL_ERROR, @@ -284,17 +283,17 @@ int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid, return -1; } -if ( domid != console_domid && console_gmfn != -1) +if ( domid != console_domid && console_gfn !=
Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: > On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: >>> #ifdef CONFIG_PARAVIRT >>> +/* >>> + * Paravirt alternatives are applied much earlier than normal alternatives. >>> + * They are only applied when running on a hypervisor. They replace some >>> + * native instructions with calls to pv ops. >>> + */ >>> +void __init apply_pv_alternatives(void) >>> +{ >>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS); >> Not for Xen HVM guests. > From what I can tell, HVM guests still use pv_time_ops and > pv_mmu_ops.exit_mmap, right? > >>> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end); >>> +} >> >> This is a problem (at least for Xen PV guests): >> apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death. > Ah, right. > >> It might be possible not to turn off/on the interrupts in this >> particular case since the guest probably won't be able to handle an >> interrupt at this point anyway. > Yeah, that should work. For Xen and for the other hypervisors, this is > called well before irq init, so interrupts can't be handled yet anyway. There is also another problem: [1.312425] general protection fault: [#1] SMP [1.312901] Modules linked in: [1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6 [1.313878] task: 88003e2c task.stack: c938c000 [1.314360] RIP: 1e030:entry_SYSCALL_64_fastpath+0x1/0xa5 [1.314854] RSP: e02b:c938ff50 EFLAGS: 00010046 [1.315336] RAX: 000c RBX: 55f550168040 RCX: 7fcfc959f59a [1.315827] RDX: RSI: RDI: [1.316315] RBP: 000a R08: 037f R09: 0064 [1.316805] R10: 1f89cbf5 R11: 88003e2c R12: 7fcfc958ad60 [1.317300] R13: R14: 55f550185954 R15: 1000 [1.317801] FS: () GS:88003f80() knlGS: [1.318267] CS: e033 DS: ES: CR0: 80050033 [1.318750] CR2: 7fcfc97ab218 CR3: 3c88e000 CR4: 00042660 [1.319235] Call Trace: [1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00 00 50 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5 [1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: c938ff50 [1.344255] ---[ end trace d7cb8cd6cd7c294c ]--- [1.345009] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b All code 0:51 push %rcx 1:50 push %rax 2:57 push %rdi 3:56 push %rsi 4:52 push %rdx 5:51 push %rcx 6:6a dapushq $0xffda 8:41 50push %r8 a:41 51push %r9 c:41 52push %r10 e:41 53push %r11 10:48 83 ec 30 sub$0x30,%rsp 14:65 4c 8b 1c 25 c0 d2 mov%gs:0xd2c0,%r11 1b:00 00 1d:41 f7 03 df 39 08 90 testl $0x900839df,(%r11) 24:0f 85 a5 00 00 00jne0xcf 2a:50 push %rax 2b:*ff 15 9c 95 d0 ffcallq *-0x2f6a64(%rip)# 0xffd095cd<-- trapping instruction 31:58 pop%rax 32:48 3d 4c 01 00 00cmp$0x14c,%rax 38:77 0fja 0x49 3a:4c 89 d1 mov%r10,%rcx 3d:ff .byte 0xff 3e:14 c5adc$0xc5,%al so the original 'cli' was replaced with the pv call but to me the offset looks a bit off, no? Shouldn't it always be positive? -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] ARM32 - build-issues with xen/arm: vpl011: Add a new vuart node in the xenstore
On 12/10/17 19:54, Bhupinder Thakur wrote: > On 5 October 2017 at 15:07, Wei Liu wrote: >> On Wed, Oct 04, 2017 at 09:58:32PM -0400, Konrad Rzeszutek Wilk wrote: >>> I get this when compiling under ARM32 (Ubuntu 15.04, >>> gcc (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2): >>> >>> libxl_console.c: In function ‘libxl__device_vuart_add’: >>> libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long >>> unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=] >>> flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn)); >>> ^ >>> ; >> My Wheezy 32bit chroot didn't catch this, sigh. >> >> Does the following patch work? >> >> From ae531197382bf0bc003606a9712075bdd22cfc24 Mon Sep 17 00:00:00 2001 >> From: Wei Liu >> Date: Thu, 5 Oct 2017 10:35:28 +0100 >> Subject: [PATCH] libxl: use correct type modifier for vuart_gfn >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: 8bit >> >> Fixes compilation error like: >> >> libxl_console.c: In function ‘libxl__device_vuart_add’: >> libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long >> unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=] >> flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn)); >> >> Reported-by: Konrad Rzeszutek Wilk >> Signed-off-by: Wei Liu >> --- >> tools/libxl/libxl_console.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c >> index 13ecf128e2..c05dc28b99 100644 >> --- a/tools/libxl/libxl_console.c >> +++ b/tools/libxl/libxl_console.c >> @@ -376,7 +376,7 @@ int libxl__device_vuart_add(libxl__gc *gc, uint32_t >> domid, >> flexarray_append(ro_front, "port"); >> flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->vuart_port)); >> flexarray_append(ro_front, "ring-ref"); >> -flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn)); >> +flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn)); > Unfortunately, this is causing an issue as PRI_xen_pfn formats the > value as a hexadecimal value but xenconsole later reads it as a > decimal value and tries to map it, which fails and therefore vuart > console initialization fails. > > Earlier, I verified only 32-bit compilation but did not test the > change. It was a miss from my side. I have tested now with the format > string changed to PRIu64 and the vuart console is working fine. That however, would break x86. andrewcoop@andrewcoop:/local/xen.git/xen$ git grep 'define PRI_xen_pfn' -- :/ include/public/arch-arm.h:276:#define PRI_xen_pfn PRIx64 include/public/arch-x86/xen.h:77:#define PRI_xen_pfn "lx" The best way to fix this is to introduce a new define for both architectures which is PRIu64 and "lu" as appropriate. Suggestions: PRI_xen_pfn_dec PRIu_xen_pfn Neither are great, but the latter does follow the PRI nomenclature. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] ARM32 - build-issues with xen/arm: vpl011: Add a new vuart node in the xenstore
On 5 October 2017 at 15:07, Wei Liu wrote: > On Wed, Oct 04, 2017 at 09:58:32PM -0400, Konrad Rzeszutek Wilk wrote: >> I get this when compiling under ARM32 (Ubuntu 15.04, >> gcc (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2): >> >> libxl_console.c: In function ‘libxl__device_vuart_add’: >> libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long >> unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=] >> flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn)); >> ^ >> ; > > My Wheezy 32bit chroot didn't catch this, sigh. > > Does the following patch work? > > From ae531197382bf0bc003606a9712075bdd22cfc24 Mon Sep 17 00:00:00 2001 > From: Wei Liu > Date: Thu, 5 Oct 2017 10:35:28 +0100 > Subject: [PATCH] libxl: use correct type modifier for vuart_gfn > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Fixes compilation error like: > > libxl_console.c: In function ‘libxl__device_vuart_add’: > libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long > unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=] > flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn)); > > Reported-by: Konrad Rzeszutek Wilk > Signed-off-by: Wei Liu > --- > tools/libxl/libxl_console.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c > index 13ecf128e2..c05dc28b99 100644 > --- a/tools/libxl/libxl_console.c > +++ b/tools/libxl/libxl_console.c > @@ -376,7 +376,7 @@ int libxl__device_vuart_add(libxl__gc *gc, uint32_t domid, > flexarray_append(ro_front, "port"); > flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->vuart_port)); > flexarray_append(ro_front, "ring-ref"); > -flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn)); > +flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn)); Unfortunately, this is causing an issue as PRI_xen_pfn formats the value as a hexadecimal value but xenconsole later reads it as a decimal value and tries to map it, which fails and therefore vuart console initialization fails. Earlier, I verified only 32-bit compilation but did not test the change. It was a miss from my side. I have tested now with the format string changed to PRIu64 and the vuart console is working fine. Regards, Bhupinder ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] preparations for 4.9.1 and 4.7.4
On Fri, Oct 6, 2017 at 6:54 AM, Andrew Cooper wrote: > On 06/10/17 14:33, Jan Beulich wrote: >> All, >> >> with the goal of releasing around the end of the month, please point >> out backport candidates you find missing from the respective staging >> branches, but which you consider relevant. Note that commits >> >> 1c2ea5ee05 x86/hvm/dmop: fix EFAULT condition >> 4e383df865 x86/PV: fix/generalize guest nul selector handling > > dbc4b6e13a5 x86/msr: Correct the definition of MSR_IA32_APICBASE_BASE > 3164f2f9db1 x86/svm: Fix a livelock when trying to run shadowed unpaged > guests 88bfbf90e3 tools/libxc/xc_dom_arm: add missing variable initialization thanks Christopher ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 114426: tolerable all pass - PUSHED
flight 114426 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/114426/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen cc08c73c8c1f5ba5ed0f8274548db6725e1c3157 baseline version: xen 3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a Last test of basis 114299 2017-10-10 21:02:54 Z1 days Failing since114308 2017-10-10 23:01:10 Z1 days 17 attempts Testing same since 114421 2017-10-12 14:02:25 Z0 days2 attempts People who touched revisions under test: Alexandru Isaila Andre Przywara Andrew Cooper Boris Ostrovsky George Dunlap Ian Jackson Jan Beulich Julien Grall Julien Grall Konrad Rzeszutek Wilk Meng Xu Ross Lagerwall Stefano Stabellini Tim Deegan Vitaly Kuznetsov Volodymyr Babchuk Wei Liu Yi Sun jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable-smoke + revision=cc08c73c8c1f5ba5ed0f8274548db6725e1c3157 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig export PERLLIB=.:. PERLLIB=.:. +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke cc08c73c8c1f5ba5ed0f8274548db6725e1c3157 + branch=xen-unstable-smoke + revision=cc08c73c8c1f5ba5ed0f8274548db6725e1c3157 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig export PERLLIB=.:.:. PERLLIB=.:.:. +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig +++ export PERLLIB=.:.:.:. +++ PERLLIB=.:.:.:. ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable-smoke + qemuubranch=qemu-upstream-unstable + '[' xxen = xlinux ']' + linuxbranch= + '[' xqemu-upstream-unstable = x ']' + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable-smoke + prevxenbranch=xen-4.9-testing + '[' xcc08c73c8c1f5ba5ed0f8274548db6725e1c3157 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/xtf.git ++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git ++ : git://xenbits.xen.org/xtf.git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/osstest/rumprun.git ++ : git ++ : git://xenbits.xen.org/osstest/rumprun.git ++ : osst...@xenbits.xen.org:/home/xen/gi
Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest
On Thu, Oct 12, 2017 at 08:45:44PM +0800, Haozhong Zhang wrote: > On 10/10/17 12:05 -0400, Konrad Rzeszutek Wilk wrote: > > On Tue, Sep 12, 2017 at 11:15:09AM +0800, Haozhong Zhang wrote: > > > On 09/11/17 11:52 -0700, Stefano Stabellini wrote: > > > > CC'ing xen-devel, and the Xen tools and x86 maintainers. > > > > > > > > On Mon, 11 Sep 2017, Igor Mammedov wrote: > > > > > On Mon, 11 Sep 2017 12:41:47 +0800 > > > > > Haozhong Zhang wrote: > > > > > > > > > > > This is the QEMU part patches that works with the associated Xen > > > > > > patches to enable vNVDIMM support for Xen HVM domains. Xen relies on > > > > > > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate > > > > > > guest address space for vNVDIMM devices. > > > > > > > > > > > > All patches can be found at > > > > > > Xen: https://github.com/hzzhan9/xen.git nvdimm-rfc-v3 > > > > > > QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v3 > > > > > > > > > > > > Patch 1 is to avoid dereferencing the NULL pointer to non-existing > > > > > > label data, as the Xen side support for labels is not implemented > > > > > > yet. > > > > > > > > > > > > Patch 2 & 3 add a memory backend dedicated for Xen usage and a > > > > > > hotplug > > > > > > memory region for Xen guest, in order to make the existing nvdimm > > > > > > device plugging path work on Xen. > > > > > > > > > > > > Patch 4 - 10 build and cooy NFIT from QEMU to Xen guest, when QEMU > > > > > > is > > > > > > used as the Xen device model. > > > > > > > > > > I've skimmed over patch-set and can't say that I'm happy with > > > > > number of xen_enabled() invariants it introduced as well as > > > > > with partial blobs it creates. > > > > > > > > I have not read the series (Haozhong, please CC me, Anthony and > > > > xen-devel to the whole series next time), but yes, indeed. Let's not add > > > > more xen_enabled() if possible. > > > > > > > > Haozhong, was there a design document thread on xen-devel about this? If > > > > so, did it reach a conclusion? Was the design accepted? If so, please > > > > add a link to the design doc in the introductory email, so that > > > > everybody can read it and be on the same page. > > > > > > Yes, there is a design [1] discussed and reviewed. Section 4.3 discussed > > > the guest ACPI. > > > > > > [1] > > > https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01921.html > > > > Igor, did you have a chance to read it? > > > > .. see below > > > > > > > > > > > > > > > > I'd like to reduce above and a way to do this might be making xen > > > > > 1. use fw_cfg > > > > > 2. fetch QEMU build acpi tables from fw_cfg > > > > > 3. extract nvdim tables (which is trivial) and use them > > > > > > > > > > looking at xen_load_linux(), it seems possible to use fw_cfg. > > > > > > > > > > So what's stopping xen from using it elsewhere?, > > > > > instead of adding more xen specific code to do 'the same' > > > > > job and not reusing/sharing common code with tcg/kvm. > > > > > > > > So far, ACPI tables have not been generated by QEMU. Xen HVM machines > > > > rely on a firmware-like application called "hvmloader" that runs in > > > > guest context and generates the ACPI tables. I have no opinions on > > > > hvmloader and I'll let the Xen maintainers talk about it. However, keep > > > > in mind that with an HVM guest some devices are emulated by Xen and/or > > > > by other device emulators that can run alongside QEMU. QEMU doesn't have > > > > a full few of the system. > > > > > > > > Here the question is: does it have to be QEMU the one to generate the > > > > ACPI blobs for the nvdimm? It would be nicer if it was up to hvmloader > > > > like the rest, instead of introducing this split-brain design about > > > > ACPI. We need to see a design doc to fully understand this. > > > > > > > > > > hvmloader runs in the guest and is responsible to build/load guest > > > ACPI. However, it's not capable to build AML at runtime (for the lack > > > of AML builder). If any guest ACPI object is needed (e.g. by guest > > > DSDT), it has to be generated from ASL by iasl at Xen compile time and > > > then be loaded by hvmloader at runtime. > > > > > > Xen includes an OperationRegion "BIOS" in the static generated guest > > > DSDT, whose address is hardcoded and which contains a list of values > > > filled by hvmloader at runtime. Other ACPI objects can refer to those > > > values (e.g., the number of vCPUs). But it's not enough for generating > > > guest NVDIMM ACPI objects at compile time and then being customized > > > and loaded by hvmload, because its structure (i.e., the number of > > > namespace devices) cannot be decided util the guest config is known. > > > > > > Alternatively, we may introduce an AML builder in hvmloader and build > > > all guest ACPI completely in hvmloader. Looking at the similar > > > implementation in QEMU, it would not be small, compared to the current > > > size of hvmloader. Besides, I'm
Re: [Xen-devel] [PATCH v1] x86/hvm: Add MSR old value
On Thu, Oct 12, 2017 at 3:10 AM, Alexandru Isaila wrote: > This patch adds the old value param and the onchangeonly option > to the VM_EVENT_REASON_MOV_TO_MSR event. > > The param was added to the vm_event_mov_to_msr struct and to the > hvm_monitor_msr function. Finally I've changed the bool_t param > to a bool for the hvm_msr_write_intercept function. > > Signed-off-by: Alexandru Isaila Acked-by: Tamas K Lengyel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3 v4] xenfb: Add [feature|request]-raw-pointer
On Thu, 12 Oct 2017, Paul Durrant wrote: > > -Original Message- > > From: Gerd Hoffmann [mailto:kra...@redhat.com] > > Sent: 12 October 2017 10:26 > > To: Paul Durrant ; 'Stefano Stabellini' > > ; Anthony Perard > > Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Owen Smith > > > > Subject: Re: [Xen-devel] [PATCH 3/3 v4] xenfb: Add [feature|request]-raw- > > pointer > > > > Hi, > > > > > It's probably OS specific though. I guess the behaviour changed > > > because the OS favours absolute pointing devices over relative ones > > > and how it has two absolute ones to choose from. How it reconciles > > > those, who knows? > > > > Typically hid emulation calls qemu_input_handler_activate() when the > > guest initializes the device, which moves the device to the top of the > > priority list. > > > > Visible effect on a typical guest with ps/2 mouse and usb-tablet is > > that qemu switches from relative mode (mouse) to absolute mode (tablet) > > when the guest loads the usb hid driver. > > > > I suspect pvmouse is doing the same thing. So it may simply depend on > > guest driver load order whenever pvmouse or usb-tablet is used. > > > > Simplest fix is probably to only attach the device you plan to use to > > the guest. If you can't turn off pvmouse for xen guests then you might > > want drop the qemu_input_handler_activate() call, so it behaves simliar > > to the ps/2 mouse (is used in case no other pointer device is present). > > Avoiding the activate call sounds reasonable and should avoid the behavioural > change. +1 Owen, are you up for resubmitting the series with this small change? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] preparations for 4.9.1 and 4.7.4
Hi all, for 4.9.1 the XSA status is XSA 226 : Some patches not applied => check There is an extra chunk in the tree: see xsa226.png XSA 227 : All patches found (no need to check) XSA 228 : All patches found (no need to check) XSA 229 : No patch found => check Linux only => no issue XSA 230 : All patches found (no need to check) XSA 231 : All patches found (no need to check) XSA 232 : All patches found (no need to check) XSA 233 : All patches found (no need to check) XSA 234 : All patches found (no need to check) XSA 235 : All patches found (no need to check) XSA 237 : No patch found => check XSA 238 : No patch found => check XSA 239 : No patch found => check XSA 240 : No patch found => check XSA 241 : No patch found => check XSA 242 : No patch found => check XSA 243 : No patch found => check XSA 244 : No patch found => check These have only been released today and have not yet been applied XSA 245 : Some patches not applied => check This is a minor change to a comment at check-in => no issue For 4.7.4 the XSA status is XSA 226 : Some patches not applied => check There is an extra chunk in the tree: see xsa226.png XSA 227 : All patches found (no need to check) XSA 228 : All patches found (no need to check) XSA 229 : No patch found => check XSA 229 : No patch found => check Linux only => no issue XSA 230 : All patches found (no need to check) XSA 231 : All patches found (no need to check) XSA 232 : All patches found (no need to check) XSA 233 : All patches found (no need to check) XSA 234 : No patch found => check ISSUE: This is genuinely missing (aka xsa234-4.8.patch) XSA 235 : All patches found (no need to check) XSA 237 : No patch found => check XSA 238 : No patch found => check XSA 239 : No patch found => check XSA 240 : No patch found => check XSA 241 : No patch found => check XSA 242 : No patch found => check XSA 243 : No patch found => check XSA 244 : No patch found => check These have only been released today and have not yet been applied XSA 245 : Some patches not applied => check This is missing xsa245/0002-xen-arm-Correctly-report-the-memory-region-in-the-du.patch Best Regards Lars On 06/10/2017, 14:33, "Jan Beulich" wrote: All, with the goal of releasing around the end of the month, please point out backport candidates you find missing from the respective staging branches, but which you consider relevant. Note that commits 1c2ea5ee05 x86/hvm/dmop: fix EFAULT condition 4e383df865 x86/PV: fix/generalize guest nul selector handling are already on my list. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] UEFI Secure Boot Xen 4.9
Hi What is the status of creating a shim to abstract secure boot signing for Xen (to leverage MSFT 3rd party, e.g)? Thanks -Bill > -Original Message- > From: Daniel Kiper [mailto:daniel.ki...@oracle.com] > Sent: Tuesday, May 16, 2017 4:05 AM > To: Bill Jacobs (billjac) > Cc: george.dun...@citrix.com; xen-devel@lists.xen.org; xen- > us...@lists.xen.org > Subject: Re: [Xen-users] UEFI Secure Boot Xen 4.9 > > On Mon, May 15, 2017 at 07:09:54PM +, Bill Jacobs (billjac) wrote: > > > -Original Message- > > > From: Daniel Kiper [mailto:daniel.ki...@oracle.com] > > > Sent: Monday, May 15, 2017 6:13 AM > > > To: Bill Jacobs (billjac) ; > > > george.dun...@citrix.com > > > Cc: xen-devel@lists.xen.org; xen-us...@lists.xen.org > > > Subject: Re: [Xen-users] UEFI Secure Boot Xen 4.9 > > > > > > Hey, > > > > > > CC-ing Xen-devel to spread some knowledge about the issue. > > > > > > On Mon, May 15, 2017 at 10:42:23AM +0100, George Dunlap wrote: > > > > On Wed, May 10, 2017 at 11:36 PM, Bill Jacobs (billjac) > > > > wrote: > > > > > Hi all > > > > > > > > > > I gather that with 4.9, UEFI secure boot of Xen should be possible. > > > > > > > > > > Is this true? > > > > > > > > > > If so, what are the options for utilizing UEFI secure boot? Do I > > > > > need a MSFT-signed shim or grub? Any special changes required > > > > > for Xen kernel > > > > > (signing?) or has that been done? > > > > > > > > Bill, > > > > > > > > I guess in part it depends on what you mean by "utilizing UEFI > > > > secure boot". If you simply want to boot an unsigned Xen on a > > > > UEFI system with SecureBoot enabled, then grub would probably > > > > work. If you want to actually do the full SecureBoot thing -- > > > > where you have grub check Xen's signature and that of the kernel > > > > and initrd, you probably need a bit more. > > > > > > > > Daniel, > > > > > > > > Is there any good documentation on this? The Xen EFI guide > > > > (https://wiki.xenproject.org/wiki/Xen_EFI) mentions the shim, but > > > > doesn't go into detail about how to sign a binary &c. > > > > > > Unfortunately I do not know anything like that. As you said in > > > general shim is supported. Sadly, it works only if you load xen.efi > > > directly > from EFI. > > > __Upstream__ GRUB2 has not have support for shim yet. I am working > > > on it (shim support via GRUB2 requires also some changes in Xen). I > > > hope that I will have something which works before Xen conf in Budapest. > > > > > > If you wish to use shim with xen.efi then you have to sign xen.efi > > > and vmlinux with your key using sbsign or pesign. The process works > > > in the same way like in case vmlinux alone. Of course you have to > > > install your public key into MOK before enabling secure boot. > > > > > > Daniel > > > > Yes, there are options in how this is achievable, and the solutions may be > different. > > > > We are targeting a secure boot chain from UEFI fw to .ko, using same > > signing. > > In our case would skip shim and reduce attack surface, but it appears > > that the mechanisms 'out there' for passing pub key (cert) from UEFI > > db to Linux chainring require shim to do the work. Is that accurate? Does it > have to be the case? I don't see why. > > AIUI, if EFI secure boot is enabled then EFI verifies signatures of every > loaded/executed PE file. Unfortunately, you are not able to use secure boot > protocol directly to verify yourself PE's loaded from your app. So, this is > one of > reasons why shim was introduced. It exposes protocol which can be used by > you to do verification. > > > For us, ideal case is : > > UEFI fw -> (signed)GRUB2.efi->Multiboot2->Xen(signed .ko) > > AFAICT, it is not possible. We should do following thing: > > UEFI -> shim -> GRUB2 -> Multiboot2 -> Xen/Linux/etc. > > UEFI will verify shim secure boot signature then shim will verify GRUB2 > signature then GRUB2 will verify (with shim protocol) Xen signature and > finally > Xen will verify (with shim protocol) Linux kernel signature. Then your kernel > can verify modules using whatever you want. > > > I would be happy to work to help achieve this. > > There is a chance that I will have something very raw at the beginning of > June. > If you wish to do tests drop me a line. > > Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v2 7/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver
Hi Sameer, Given this is all Arm specific. I am not sure why people like Andrew, Jan have been added. Please use scripts/get_maintainers to find the list of maintainers per patches and avoid to CC all of them on each patches. On 21/09/17 01:37, Sameer Goel wrote: This driver follows an approach similar to smmu driver. The intent here is to reuse as much Linux code as possible. - Glue code has been introduced to bridge the API calls. - Called Linux functions from the Xen IOMMU function calls. - Xen modifications are preceded by /*Xen: comment */ Signed-off-by: Sameer Goel --- xen/drivers/passthrough/arm/Makefile | 1 + xen/drivers/passthrough/arm/smmu-v3.c | 853 +- This is based on an old SMMUv3 version and I have been told there are some changes may benefits Xen (such as increasing the timeout for sync) and some optimisations also exist on the ML and will be queued soon. So maybe you want to re-sync at least to master. 2 files changed, 738 insertions(+), 116 deletions(-) diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile index f4cd26e..57a6da6 100644 --- a/xen/drivers/passthrough/arm/Makefile +++ b/xen/drivers/passthrough/arm/Makefile @@ -1,2 +1,3 @@ obj-y += iommu.o obj-y += smmu.o +obj-y += smmu-v3.o Do we want SMMUv3 to be built on Arm32? Maybe we should introduce a new Kconfig to let the user select. diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c index 380969a..8f3b43d 100644 --- a/xen/drivers/passthrough/arm/smmu-v3.c +++ b/xen/drivers/passthrough/arm/smmu-v3.c @@ -18,28 +18,266 @@ * Author: Will Deacon * * This driver is powered by bad coffee and bombay mix. + * + * + * Based on Linux drivers/iommu/arm-smmu-v3.c + * => commit bdf95923086fb359ccb44c815724c3ace1611c90 + * + * Xen modifications: + * Sameer Goel + * Copyright (C) 2017, The Linux Foundation, All rights reserved. + * */ -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include - -#include "io-pgtable.h" +#include This is not necessary. +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include Please order the includes alphabetically with xen/* first then asm/* + +typedef paddr_t phys_addr_t; +typedef paddr_t dma_addr_t; + +/* Alias to Xen device tree helpers */ +#define device_node dt_device_node +#define of_phandle_args dt_phandle_args +#define of_device_id dt_device_match +#define of_match_node dt_match_node +#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, out)) +#define of_property_read_bool dt_property_read_bool +#define of_parse_phandle_with_args dt_parse_phandle_with_args +#define mutex spinlock_t +#define mutex_init spin_lock_init +#define mutex_lock spin_lock +#define mutex_unlock spin_unlock mutex and spinlock are not the same. The former is sleeping whilst the later is not. Can you please explain why this is fine and possibly add that in a comment? + +/* Xen: Helpers to get device MMIO and IRQs */ +struct resource { + u64 addr; + u64 size; + unsigned int type; +}; Likely we want a compat header for defining Linux helpers. This would avoid replicating it everywhere. + +#define resource_size(res) ((res)->size) + +#define platform_device device + +#define IORESOURCE_MEM 0 +#define IORESOURCE_IRQ 1 + +static struct resource *platform_get_resource(struct platform_device *pdev, + unsigned int type, + unsigned int num) +{ + /* +* The resource is only used between 2 calls of platform_get_resource. +* It's quite ugly but it's avoid to add too much code in the part +* imported from Linux +*/ + static struct resource res; + struct acpi_iort_node *iort_node; + struct acpi_iort_smmu_v3 *node_smmu_data; + int ret = 0; + + res.type = type; + + switch (type) { + case IORESOURCE_MEM: + if (pdev->type == DEV_ACPI) { + ret = 1; + iort_node = pdev->acpi_node; + node_smmu_data = + (struct acpi_iort_smmu_v3 *)iort_node->node_data; + + if (node_smmu_data != NULL) { + res.addr = node_smmu_data->base_address; + res.size = SZ_128K; + ret = 0; + } + } else { + ret = dt_device_get_address(dev_to_dt(pdev), num, + &res.addr, &res.size); + } + + return ((ret)
Re: [Xen-devel] [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
On 10/12/2017 10:34 AM, Thomas Garnier wrote: On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky wrote: On 10/11/2017 3:30 PM, Thomas Garnier wrote: Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends module space from 1 to 2G maximum. - Support for XEN PVH as 32-bit relocations can be ignored with --emit-relocs. - Support for GOT relocations previously done automatically with -pie. - Remove need for dynamic PLT in modules. - Support dymamic GOT for modules. - rfc v2: - Add support for global stack cookie while compiler default to fs without mcmodel=kernel - Change patch 7 to correctly jump out of the identity mapping on kexec load preserve. These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Hi Thomas, I've applied your patches so that I can verify that SME works with PIE. Unfortunately, I'm running into build warnings and errors when I enable PIE. With CONFIG_STACK_VALIDATION=y I receive lots of messages like this: drivers/scsi/libfc/fc_exch.o: warning: objtool: fc_destroy_exch_mgr()+0x0: call without frame pointer save/setup Disabling CONFIG_STACK_VALIDATION suppresses those. I ran into that, I plan to fix it in the next iteration. But near the end of the build, I receive errors like this: arch/x86/kernel/setup.o: In function `dump_kernel_offset': .../arch/x86/kernel/setup.c:801:(.text+0x32): relocation truncated to fit: R_X86_64_32S against symbol `_text' defined in .text section in .tmp_vmlinux1 . . about 10 more of the above type messages . make: *** [vmlinux] Error 1 Error building kernel, exiting Are there any config options that should or should not be enabled when building with PIE enabled? Is there a compiler requirement for PIE (I'm using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))? I never ran into these ones and I tested compilers older and newer. What was your exact configuration? I'll send you the config in a separate email. Thanks, Tom Thanks, Tom Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to Roland McGrath on his feedback for using -pie versus --emit-relocs and details on compiler code generation. The patches: - 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant. - 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically. - 14: Adapt percpu design to work correctly when PIE is enabled. - 15: Provide an option to default visibility to hidden except for key symbols. It removes errors between compilation units. - 16: Adapt relocation tool to handle PIE binary correctly. - 19: Add support for global cookie. - 20: Support ftrace with PIE (used on Ubuntu config). - 21: Fix incorrect address marker on dump_pagetables. - 22: Add option to move the module section just after the kernel. - 23: Adapt module loading to support PIE with dynamic GOT. - 24: Make the GOT read-only. - 25: Add the CONFIG_X86_PIE option (off by default). - 26: Adapt relocation tool to generate a 64-bit relocation table. - 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range from 1G to 3G (off by default). Performance/Size impact: Size of vmlinux (Default configuration): File size: - PIE disabled: +0.31% - PIE enabled: -3.210% (less relocations) .text section: - PIE disabled: +0.000644% - PIE enabled: +0.837% Size of vmlinux (Ubuntu configuration): File size: - PIE disabled: -0.201% - PIE enabled: -0.082% .text section: - PIE disabled: same - PIE enabled: +1.319% Size of vmlinux (Default configuration + ORC): File size: - PIE enabled: -3.167% .text section: - PIE enabled: +0.814% Size of vmlinux (Ubuntu configuration + ORC): File size: - PIE enabled: -3.167% .text section: - PIE enabled: +1.26% The size increase is mainly due to not having access to the 32-bit signed relocation that can be used with mcmodel=kernel. A small part is due to reduced optimization for PIE code. This bug [1] was opened with gcc to provide a better code generation for kernel PIE. Hackbench (50% and 1600% on thread/process for pipe/sockets): - PIE disabled: no significant change (avg +0.1% on latest test). - PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config). slab_test (averag
[Xen-devel] [PATCH v11 11/11] tools/libxenctrl: use new xenforeignmemory API to seed grant table
A previous patch added support for priv-mapping guest resources directly (rather than having to foreign-map, which requires P2M modification for HVM guests). This patch makes use of the new API to seed the guest grant table unless the underlying infrastructure (i.e. privcmd) doesn't support it, in which case the old scheme is used. NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was actually unnecessary, as the grant table has already been seeded by a prior call to xc_dom_gnttab_init() made by libxl__build_dom(). Signed-off-by: Paul Durrant Acked-by: Marek Marczykowski-Górecki Reviewed-by: Roger Pau Monné Acked-by: Wei Liu --- Cc: Ian Jackson v10: - Use new id constant for grant table. v4: - Minor cosmetic fix suggested by Roger. v3: - Introduced xc_dom_set_gnttab_entry() to avoid duplicated code. --- tools/libxc/include/xc_dom.h| 8 +-- tools/libxc/xc_dom_boot.c | 114 +--- tools/libxc/xc_sr_restore_x86_hvm.c | 10 ++-- tools/libxc/xc_sr_restore_x86_pv.c | 2 +- tools/libxl/libxl_dom.c | 1 - tools/python/xen/lowlevel/xc/xc.c | 6 +- 6 files changed, 92 insertions(+), 49 deletions(-) diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h index 6e06ef1dec..4216d63462 100644 --- a/tools/libxc/include/xc_dom.h +++ b/tools/libxc/include/xc_dom.h @@ -325,12 +325,8 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn, int xc_dom_boot_image(struct xc_dom_image *dom); int xc_dom_compat_check(struct xc_dom_image *dom); int xc_dom_gnttab_init(struct xc_dom_image *dom); -int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid, - xen_pfn_t console_gmfn, - xen_pfn_t xenstore_gmfn, - domid_t console_domid, - domid_t xenstore_domid); -int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid, +int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid, + bool is_hvm, xen_pfn_t console_gmfn, xen_pfn_t xenstore_gmfn, domid_t console_domid, diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c index 8a376d097c..0fe94aa255 100644 --- a/tools/libxc/xc_dom_boot.c +++ b/tools/libxc/xc_dom_boot.c @@ -282,11 +282,29 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, domid_t domid) return gmfn; } -int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid, - xen_pfn_t console_gmfn, - xen_pfn_t xenstore_gmfn, - domid_t console_domid, - domid_t xenstore_domid) +static void xc_dom_set_gnttab_entry(xc_interface *xch, +grant_entry_v1_t *gnttab, +unsigned int idx, +domid_t guest_domid, +domid_t backend_domid, +xen_pfn_t backend_gmfn) +{ +if ( guest_domid == backend_domid || backend_gmfn == -1) +return; + +xc_dom_printf(xch, "%s: [%u] -> 0x%"PRI_xen_pfn, + __FUNCTION__, idx, backend_gmfn); + +gnttab[idx].flags = GTF_permit_access; +gnttab[idx].domid = backend_domid; +gnttab[idx].frame = backend_gmfn; +} + +static int compat_gnttab_seed(xc_interface *xch, domid_t domid, + xen_pfn_t console_gmfn, + xen_pfn_t xenstore_gmfn, + domid_t console_domid, + domid_t xenstore_domid) { xen_pfn_t gnttab_gmfn; @@ -310,18 +328,10 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid, return -1; } -if ( domid != console_domid && console_gmfn != -1) -{ -gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access; -gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid; -gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn; -} -if ( domid != xenstore_domid && xenstore_gmfn != -1) -{ -gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access; -gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid; -gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn; -} +xc_dom_set_gnttab_entry(xch, gnttab, GNTTAB_RESERVED_CONSOLE, +domid, console_domid, console_gmfn); +xc_dom_set_gnttab_entry(xch, gnttab, GNTTAB_RESERVED_XENSTORE, +domid, xenstore_domid, xenstore_gmfn); if ( munmap(gnttab, PAGE_SIZE) == -1 ) { @@ -339,11 +349,11 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid, return 0; } -int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid, - xen_pfn_t console_gpfn, - xen_pfn_t xenstore_gpfn, -
[Xen-devel] [PATCH v11 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table
This patch allows grant table frames to be mapped using the XENMEM_acquire_resource memory op. Signed-off-by: Paul Durrant --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu v10: - Addressed comments from Jan. v8: - The functionality was originally incorporated into the earlier patch "x86/mm: add HYPERVISOR_memory_op to acquire guest resources". --- xen/common/grant_table.c | 63 ++- xen/common/memory.c | 44 +- xen/include/public/memory.h | 6 + xen/include/xen/grant_table.h | 4 +++ 4 files changed, 110 insertions(+), 7 deletions(-) diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c index 6d20b17739..e42c1b6bf3 100644 --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -1608,7 +1608,8 @@ fault: } static int -gnttab_populate_status_frames(struct domain *d, struct grant_table *gt, +gnttab_populate_status_frames(struct domain *d, + struct grant_table *gt, unsigned int req_nr_frames) { unsigned i; @@ -3756,13 +3757,12 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref, } #endif -int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn, - mfn_t *mfn) +/* Caller must hold write lock as version may change and table may grow */ +static int gnttab_get_frame(struct domain *d, unsigned long idx, +mfn_t *mfn) { -int rc = 0; struct grant_table *gt = d->grant_table; - -grant_write_lock(gt); +int rc = 0; if ( gt->gt_version == 0 ) gt->gt_version = 1; @@ -3787,6 +3787,19 @@ int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn, rc = -EINVAL; } +return rc; +} + +int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn, + mfn_t *mfn) +{ +struct grant_table *gt = d->grant_table; +int rc; + +grant_write_lock(gt); + +rc = gnttab_get_frame(d, idx, mfn); + if ( !rc ) gnttab_set_frame_gfn(gt, idx, gfn); @@ -3795,6 +3808,44 @@ int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn, return rc; } +int gnttab_get_grant_frame(struct domain *d, unsigned long idx, + mfn_t *mfn) +{ +struct grant_table *gt = d->grant_table; +int rc; + +/* write lock required as version may change and/or table may grow */ +grant_write_lock(gt); + +rc = (gt->gt_version == 2 && + idx > XENMAPIDX_grant_table_status) ? +-EINVAL : +gnttab_get_frame(d, idx, mfn); + +grant_write_unlock(gt); + +return rc; +} + +int gnttab_get_status_frame(struct domain *d, unsigned long idx, +mfn_t *mfn) +{ +struct grant_table *gt = d->grant_table; +int rc; + +/* write lock required as version may change and/or table may grow */ +grant_write_lock(gt); + +rc = (gt->gt_version != 2 || + idx > XENMAPIDX_grant_table_status) ? +-EINVAL : +gnttab_get_frame(d, idx & XENMAPIDX_grant_table_status, mfn); + +grant_write_unlock(gt); + +return rc; +} + static void gnttab_usage_print(struct domain *rd) { int first = 1; diff --git a/xen/common/memory.c b/xen/common/memory.c index 1a9872b75c..a50d93d006 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include #include @@ -965,11 +966,47 @@ static long xatp_permission_check(struct domain *d, unsigned int space) return xsm_add_to_physmap(XSM_TARGET, current->domain, d); } +static int acquire_grant_table(struct domain *d, unsigned int id, + unsigned long frame, + unsigned int nr_frames, + unsigned long mfn_list[]) +{ +unsigned int i = nr_frames; + +while ( i-- != 0 ) +{ +mfn_t mfn = INVALID_MFN; +int rc; + +switch ( id ) +{ +case XENMEM_resource_grant_table_id_grant: +rc = gnttab_get_grant_frame(d, frame + i, &mfn); +break; + +case XENMEM_resource_grant_table_id_status: +rc = gnttab_get_status_frame(d, frame + i, &mfn); +break; + +default: +rc = -EINVAL; +break; +} + +if ( rc ) +return rc; + +mfn_list[i] = mfn_x(mfn); +} + +return 0; +} + static int acquire_resource(XEN_GUEST_HANDLE_PARAM(void) arg) { struct domain *d, *currd = current->domain; xen_mem_acquire_resource_t xmar; -unsigned long mfn_list[2]; +unsigned long mfn_list[32]; int rc; if ( copy_from_guest(&xmar, arg, 1) ) @@ -1005,6 +1042,11 @@ static int acquire_resource(XEN_GUEST_HANDLE_PARAM(vo
[Xen-devel] [PATCH v11 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list
A subsequent patch will remove the current implicit limitation on creation of ioreq servers which is due to the allocation of gfns for the ioreq structures and buffered ioreq ring. It will therefore be necessary to introduce an explicit limit and, since this limit should be small, it simplifies the code to maintain an array of that size rather than using a list. Also, by reserving an array slot for the default server and populating array slots early in create, the need to pass an 'is_default' boolean to sub-functions can be avoided. Some function return values are changed by this patch: Specifically, in the case where the id of the default ioreq server is passed in, -EOPNOTSUPP is now returned rather than -ENOENT. Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Cc: Andrew Cooper v10: - modified FOR_EACH... macro as suggested by Jan. - check for NULL in IS_DEFAULT macro as suggested by Jan. v9: - modified FOR_EACH... macro as requested by Andrew. v8: - Addressed various comments from Jan. v7: - Fixed assertion failure found in testing. v6: - Updated according to comments made by Roger on v4 that I'd missed. v5: - Switched GET/SET_IOREQ_SERVER() macros to get/set_ioreq_server() functions to avoid possible double-evaluation issues. v4: - Introduced more helper macros and relocated them to the top of the code. v3: - New patch (replacing "move is_default into struct hvm_ioreq_server") in response to review comments. --- xen/arch/x86/hvm/ioreq.c | 502 +++ xen/include/asm-x86/hvm/domain.h | 10 +- 2 files changed, 245 insertions(+), 267 deletions(-) diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index f2e0b3f74a..e6ccc7572a 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -33,6 +33,37 @@ #include +static void set_ioreq_server(struct domain *d, unsigned int id, + struct hvm_ioreq_server *s) +{ +ASSERT(id < MAX_NR_IOREQ_SERVERS); +ASSERT(!s || !d->arch.hvm_domain.ioreq_server.server[id]); + +d->arch.hvm_domain.ioreq_server.server[id] = s; +} + +#define GET_IOREQ_SERVER(d, id) \ +(d)->arch.hvm_domain.ioreq_server.server[id] + +static struct hvm_ioreq_server *get_ioreq_server(const struct domain *d, + unsigned int id) +{ +if ( id >= MAX_NR_IOREQ_SERVERS ) +return NULL; + +return GET_IOREQ_SERVER(d, id); +} + +#define IS_DEFAULT(s) \ +((s) && (s) == GET_IOREQ_SERVER((s)->domain, DEFAULT_IOSERVID)) + +/* Iterate over all possible ioreq servers */ +#define FOR_EACH_IOREQ_SERVER(d, id, s) \ +for ( (id) = 0; (id) < MAX_NR_IOREQ_SERVERS; (id)++ ) \ +if ( !(s = GET_IOREQ_SERVER(d, id)) ) \ +continue; \ +else + static ioreq_t *get_ioreq(struct hvm_ioreq_server *s, struct vcpu *v) { shared_iopage_t *p = s->ioreq.va; @@ -47,10 +78,9 @@ bool hvm_io_pending(struct vcpu *v) { struct domain *d = v->domain; struct hvm_ioreq_server *s; +unsigned int id; -list_for_each_entry ( s, - &d->arch.hvm_domain.ioreq_server.list, - list_entry ) +FOR_EACH_IOREQ_SERVER(d, id, s) { struct hvm_ioreq_vcpu *sv; @@ -127,10 +157,9 @@ bool handle_hvm_io_completion(struct vcpu *v) struct hvm_vcpu_io *vio = &v->arch.hvm_vcpu.hvm_io; struct hvm_ioreq_server *s; enum hvm_io_completion io_completion; +unsigned int id; - list_for_each_entry ( s, - &d->arch.hvm_domain.ioreq_server.list, - list_entry ) +FOR_EACH_IOREQ_SERVER(d, id, s) { struct hvm_ioreq_vcpu *sv; @@ -243,13 +272,12 @@ static int hvm_map_ioreq_page( bool is_ioreq_server_page(struct domain *d, const struct page_info *page) { const struct hvm_ioreq_server *s; +unsigned int id; bool found = false; spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock); -list_for_each_entry ( s, - &d->arch.hvm_domain.ioreq_server.list, - list_entry ) +FOR_EACH_IOREQ_SERVER(d, id, s) { if ( (s->ioreq.va && s->ioreq.page == page) || (s->bufioreq.va && s->bufioreq.page == page) ) @@ -302,7 +330,7 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server *s, } static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s, - bool is_default, struct vcpu *v) + struct vcpu *v) { struct hvm_ioreq_vcpu *sv; int rc; @@ -331,7 +359,7 @@ static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s, goto fail3; s->bufioreq_evtchn = rc; -if ( is_default ) +if ( IS_DEFAULT(s) ) d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN] = s->bufioreq_evtchn;
[Xen-devel] [PATCH v11 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources
Certain memory resources associated with a guest are not necessarily present in the guest P2M. This patch adds the boilerplate for new memory op to allow such a resource to be priv-mapped directly, by either a PV or HVM tools domain. NOTE: Whilst the new op is not intrinsicly specific to the x86 architecture, I have no means to test it on an ARM platform and so cannot verify that it functions correctly. Hence it is currently only implemented for x86. Signed-off-by: Paul Durrant --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu v11: - Addressed more comments from Jan. v9: - Addressed more comments from Jan. v8: - Move the code into common as requested by Jan. - Make the gmfn_list handle a 64-bit type to avoid limiting the MFN range for a 32-bit tools domain. - Add missing pad. - Add compat code. - Make this patch deal with purely boilerplate. - Drop George's A-b and Wei's R-b because the changes are non-trivial, and update Cc list now the boilerplate is common. v5: - Switched __copy_to/from_guest_offset() to copy_to/from_guest_offset(). --- tools/flask/policy/modules/xen.if | 4 +- xen/arch/x86/mm/p2m.c | 3 +- xen/common/compat/memory.c | 145 ++-- xen/common/memory.c | 90 ++ xen/include/asm-x86/p2m.h | 3 + xen/include/public/memory.h | 43 ++- xen/include/xlat.lst| 1 + xen/include/xsm/dummy.h | 6 ++ xen/include/xsm/xsm.h | 6 ++ xen/xsm/dummy.c | 1 + xen/xsm/flask/hooks.c | 6 ++ xen/xsm/flask/policy/access_vectors | 2 + 12 files changed, 300 insertions(+), 10 deletions(-) diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if index 55437496f6..07cba8a15d 100644 --- a/tools/flask/policy/modules/xen.if +++ b/tools/flask/policy/modules/xen.if @@ -52,7 +52,8 @@ define(`create_domain_common', ` settime setdomainhandle getvcpucontext set_misc_info }; allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim set_max_evtchn set_vnumainfo get_vnumainfo cacheflush - psr_cmt_op psr_cat_op soft_reset set_gnttab_limits }; + psr_cmt_op psr_cat_op soft_reset set_gnttab_limits + resource_map }; allow $1 $2:security check_context; allow $1 $2:shadow enable; allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp }; @@ -152,6 +153,7 @@ define(`device_model', ` allow $1 $2_target:domain { getdomaininfo shutdown }; allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack }; allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr dm }; + allow $1 $2_target:domain2 resource_map; ') # make_device_model(priv, dm_dom, hvm_dom) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index c72a3cdebb..71bb9b4f93 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1132,8 +1132,7 @@ static int set_typed_p2m_entry(struct domain *d, unsigned long gfn_l, } /* Set foreign mfn in the given guest's p2m table. */ -static int set_foreign_p2m_entry(struct domain *d, unsigned long gfn, - mfn_t mfn) +int set_foreign_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn) { return set_typed_p2m_entry(d, gfn, mfn, PAGE_ORDER_4K, p2m_map_foreign, p2m_get_hostp2m(d)->default_access); diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c index 35bb259808..031d1a48ae 100644 --- a/xen/common/compat/memory.c +++ b/xen/common/compat/memory.c @@ -71,6 +71,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat) struct xen_remove_from_physmap *xrfp; struct xen_vnuma_topology_info *vnuma; struct xen_mem_access_op *mao; +struct xen_mem_acquire_resource *mar; } nat; union { struct compat_memory_reservation rsrv; @@ -79,6 +80,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat) struct compat_add_to_physmap_batch atpb; struct compat_vnuma_topology_info vnuma; struct compat_mem_access_op mao; +struct compat_mem_acquire_resource mar; } cmp; set_xen_guest_handle(nat.hnd, COMPAT_ARG_XLAT_VIRT_BASE); @@ -395,6 +397,71 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat) } #endif +case XENMEM_acquire_resource: +{ +xen_ulong_t *xen_frame_list = (xen_ulong_t *)(nat.mar + 1); +unsigned int max_nr_frames; + +if ( copy_from_gues
[Xen-devel] [PATCH v11 02/11] x86/hvm/ioreq: simplify code and use consistent naming
This patch re-works much of the ioreq server initialization and teardown code: - The hvm_map/unmap_ioreq_gfn() functions are expanded to call through to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called separately by outer functions. - Several functions now test the validity of the hvm_ioreq_page gfn value to determine whether they need to act. This means can be safely called for the bufioreq page even when it is not used. - hvm_add/remove_ioreq_gfn() simply return in the case of the default IOREQ server so callers no longer need to test before calling. - hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages() to mirror the existing hvm_ioreq_server_unmap_pages(). All of this significantly shortens the code. Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Reviewed-by: Wei Liu Acked-by: Jan Beulich --- Cc: Andrew Cooper v3: - Rebased on top of 's->is_default' to 'IS_DEFAULT(s)' changes. - Minor updates in response to review comments from Roger. --- xen/arch/x86/hvm/ioreq.c | 182 ++- 1 file changed, 69 insertions(+), 113 deletions(-) diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index e6ccc7572a..6d81018369 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -210,63 +210,75 @@ bool handle_hvm_io_completion(struct vcpu *v) return true; } -static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn) +static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s) { +struct domain *d = s->domain; unsigned int i; -int rc; -rc = -ENOMEM; +ASSERT(!IS_DEFAULT(s)); + for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ ) { if ( test_and_clear_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask) ) -{ -*gfn = d->arch.hvm_domain.ioreq_gfn.base + i; -rc = 0; -break; -} +return d->arch.hvm_domain.ioreq_gfn.base + i; } -return rc; +return gfn_x(INVALID_GFN); } -static void hvm_free_ioreq_gfn(struct domain *d, unsigned long gfn) +static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, + unsigned long gfn) { +struct domain *d = s->domain; unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base; -if ( gfn != gfn_x(INVALID_GFN) ) -set_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask); +ASSERT(!IS_DEFAULT(s)); +ASSERT(gfn != gfn_x(INVALID_GFN)); + +set_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask); } -static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool buf) +static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) { struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; +if ( iorp->gfn == gfn_x(INVALID_GFN) ) +return; + destroy_ring_for_helper(&iorp->va, iorp->page); +iorp->page = NULL; + +if ( !IS_DEFAULT(s) ) +hvm_free_ioreq_gfn(s, iorp->gfn); + +iorp->gfn = gfn_x(INVALID_GFN); } -static int hvm_map_ioreq_page( -struct hvm_ioreq_server *s, bool buf, unsigned long gfn) +static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) { struct domain *d = s->domain; struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; -struct page_info *page; -void *va; int rc; -if ( (rc = prepare_ring_for_helper(d, gfn, &page, &va)) ) -return rc; - -if ( (iorp->va != NULL) || d->is_dying ) -{ -destroy_ring_for_helper(&va, page); +if ( d->is_dying ) return -EINVAL; -} -iorp->va = va; -iorp->page = page; -iorp->gfn = gfn; +if ( IS_DEFAULT(s) ) +iorp->gfn = buf ? +d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] : +d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN]; +else +iorp->gfn = hvm_alloc_ioreq_gfn(s); -return 0; +if ( iorp->gfn == gfn_x(INVALID_GFN) ) +return -ENOMEM; + +rc = prepare_ring_for_helper(d, iorp->gfn, &iorp->page, &iorp->va); + +if ( rc ) +hvm_unmap_ioreq_gfn(s, buf); + +return rc; } bool is_ioreq_server_page(struct domain *d, const struct page_info *page) @@ -279,8 +291,7 @@ bool is_ioreq_server_page(struct domain *d, const struct page_info *page) FOR_EACH_IOREQ_SERVER(d, id, s) { -if ( (s->ioreq.va && s->ioreq.page == page) || - (s->bufioreq.va && s->bufioreq.page == page) ) +if ( (s->ioreq.page == page) || (s->bufioreq.page == page) ) { found = true; break; @@ -292,20 +303,30 @@ bool is_ioreq_server_page(struct domain *d, const struct page_info *page) return found; } -static void hvm_remove_ioreq_gfn( -struct domain *d, struct hvm_ioreq_page *iorp) +static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) + { +struct domain *d = s->domain; +struct hvm_ioreq_page *iorp = buf
[Xen-devel] [PATCH v11 06/11] x86/hvm/ioreq: add a new mappable resource type...
... XENMEM_resource_ioreq_server This patch adds support for a new resource type that can be mapped using the XENMEM_acquire_resource memory op. If an emulator makes use of this resource type then, instead of mapping gfns, the IOREQ server will allocate pages from the heap. These pages will never be present in the P2M of the guest at any point and so are not vulnerable to any direct attack by the guest. They are only ever accessible by Xen and any domain that has mapping privilege over the guest (which may or may not be limited to the domain running the emulator). NOTE: Use of the new resource type is not compatible with use of XEN_DMOP_get_ioreq_server_info unless the XEN_DMOP_no_gfns flag is set. Signed-off-by: Paul Durrant Acked-by: George Dunlap Reviewed-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan v11: - Addressed more comments from Jan. v10: - Addressed comments from Jan. v8: - Re-base on new boilerplate. - Adjust function signature of hvm_get_ioreq_server_frame(), and test whether the bufioreq page is present. v5: - Use get_ioreq_server() function rather than indexing array directly. - Add more explanation into comments to state than mapping guest frames and allocation of pages for ioreq servers are not simultaneously permitted. - Add a comment into asm/ioreq.h stating the meaning of the index value passed to hvm_get_ioreq_server_frame(). --- xen/arch/x86/hvm/ioreq.c| 154 xen/arch/x86/mm.c | 22 ++ xen/common/memory.c | 5 ++ xen/include/asm-x86/hvm/ioreq.h | 2 + xen/include/asm-x86/mm.h| 5 ++ xen/include/public/hvm/dm_op.h | 4 ++ xen/include/public/memory.h | 9 +++ 7 files changed, 201 insertions(+) diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index f654e7796c..ff41312455 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -259,6 +259,19 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; int rc; +if ( iorp->page ) +{ +/* + * If a page has already been allocated (which will happen on + * demand if hvm_get_ioreq_server_frame() is called), then + * mapping a guest frame is not permitted. + */ +if ( gfn_eq(iorp->gfn, INVALID_GFN) ) +return -EPERM; + +return 0; +} + if ( d->is_dying ) return -EINVAL; @@ -281,6 +294,69 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) return rc; } +static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf) +{ +struct domain *currd = current->domain; +struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; + +if ( iorp->page ) +{ +/* + * If a guest frame has already been mapped (which may happen + * on demand if hvm_get_ioreq_server_info() is called), then + * allocating a page is not permitted. + */ +if ( !gfn_eq(iorp->gfn, INVALID_GFN) ) +return -EPERM; + +return 0; +} + +/* + * Allocated IOREQ server pages are assigned to the emulating + * domain, not the target domain. This is because the emulator is + * likely to be destroyed after the target domain has been torn + * down, and we must use MEMF_no_refcount otherwise page allocation + * could fail if the emulating domain has already reached its + * maximum allocation. + */ +iorp->page = alloc_domheap_page(currd, MEMF_no_refcount); +if ( !iorp->page ) +return -ENOMEM; + +if ( !get_page_type(iorp->page, PGT_writable_page) ) +{ +put_page(iorp->page); +iorp->page = NULL; +return -ENOMEM; +} + +iorp->va = __map_domain_page_global(iorp->page); +if ( !iorp->va ) +{ +put_page_and_type(iorp->page); +iorp->page = NULL; +return -ENOMEM; +} + +clear_page(iorp->va); +return 0; +} + +static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool buf) +{ +struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; + +if ( !iorp->page ) +return; + +unmap_domain_page_global(iorp->va); +iorp->va = NULL; + +put_page_and_type(iorp->page); +iorp->page = NULL; +} + bool is_ioreq_server_page(struct domain *d, const struct page_info *page) { const struct hvm_ioreq_server *s; @@ -484,6 +560,27 @@ static void hvm_ioreq_server_unmap_pages(struct hvm_ioreq_server *s) hvm_unmap_ioreq_gfn(s, false); } +static int hvm_ioreq_server_alloc_pages(struct hvm_ioreq_server *s) +{ +int rc; + +rc = hvm_alloc_ioreq_mfn(s, false); + +if ( !rc && (s->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF) ) +rc = hvm_alloc_ioreq_mfn(s, true); + +if ( rc ) +hvm_fre
[Xen-devel] [PATCH v11 08/11] tools/libxenforeignmemory: add support for resource mapping
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest resources for direct priv-mapping. This patch adds new functionality into libxenforeignmemory to make use of a new privcmd ioctl [1] that uses the new memory op to make such resources available via mmap(2). [1] http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=ce59a05e6712 Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Reviewed-by: Wei Liu --- Cc: Ian Jackson v4: - Fixed errno and removed single-use label - The unmap call now returns a status - Use C99 initialization for ioctl struct v2: - Bump minor version up to 3. --- tools/include/xen-sys/Linux/privcmd.h | 11 + tools/libs/foreignmemory/Makefile | 2 +- tools/libs/foreignmemory/core.c| 53 ++ .../libs/foreignmemory/include/xenforeignmemory.h | 41 + tools/libs/foreignmemory/libxenforeignmemory.map | 5 ++ tools/libs/foreignmemory/linux.c | 45 ++ tools/libs/foreignmemory/private.h | 31 + 7 files changed, 187 insertions(+), 1 deletion(-) diff --git a/tools/include/xen-sys/Linux/privcmd.h b/tools/include/xen-sys/Linux/privcmd.h index 732ff7c15a..9531b728f9 100644 --- a/tools/include/xen-sys/Linux/privcmd.h +++ b/tools/include/xen-sys/Linux/privcmd.h @@ -86,6 +86,15 @@ typedef struct privcmd_dm_op { const privcmd_dm_op_buf_t __user *ubufs; } privcmd_dm_op_t; +typedef struct privcmd_mmap_resource { + domid_t dom; + __u32 type; + __u32 id; + __u32 idx; + __u64 num; + __u64 addr; +} privcmd_mmap_resource_t; + /* * @cmd: IOCTL_PRIVCMD_HYPERCALL * @arg: &privcmd_hypercall_t @@ -103,5 +112,7 @@ typedef struct privcmd_dm_op { _IOC(_IOC_NONE, 'P', 5, sizeof(privcmd_dm_op_t)) #define IOCTL_PRIVCMD_RESTRICT \ _IOC(_IOC_NONE, 'P', 6, sizeof(domid_t)) +#define IOCTL_PRIVCMD_MMAP_RESOURCE\ + _IOC(_IOC_NONE, 'P', 7, sizeof(privcmd_mmap_resource_t)) #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */ diff --git a/tools/libs/foreignmemory/Makefile b/tools/libs/foreignmemory/Makefile index ab7f873f26..5c7f78f61d 100644 --- a/tools/libs/foreignmemory/Makefile +++ b/tools/libs/foreignmemory/Makefile @@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../.. include $(XEN_ROOT)/tools/Rules.mk MAJOR= 1 -MINOR= 2 +MINOR= 3 SHLIB_LDFLAGS += -Wl,--version-script=libxenforeignmemory.map CFLAGS += -Werror -Wmissing-prototypes diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c index a6897dc561..8d3f9f178f 100644 --- a/tools/libs/foreignmemory/core.c +++ b/tools/libs/foreignmemory/core.c @@ -17,6 +17,8 @@ #include #include +#include + #include "private.h" xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger *logger, @@ -120,6 +122,57 @@ int xenforeignmemory_restrict(xenforeignmemory_handle *fmem, return osdep_xenforeignmemory_restrict(fmem, domid); } +xenforeignmemory_resource_handle *xenforeignmemory_map_resource( +xenforeignmemory_handle *fmem, domid_t domid, unsigned int type, +unsigned int id, unsigned long frame, unsigned long nr_frames, +void **paddr, int prot, int flags) +{ +xenforeignmemory_resource_handle *fres; +int rc; + +/* Check flags only contains POSIX defined values */ +if ( flags & ~(MAP_SHARED | MAP_PRIVATE) ) +{ +errno = EINVAL; +return NULL; +} + +fres = calloc(1, sizeof(*fres)); +if ( !fres ) +{ +errno = ENOMEM; +return NULL; +} + +fres->domid = domid; +fres->type = type; +fres->id = id; +fres->frame = frame; +fres->nr_frames = nr_frames; +fres->addr = *paddr; +fres->prot = prot; +fres->flags = flags; + +rc = osdep_xenforeignmemory_map_resource(fmem, fres); +if ( rc ) +{ +free(fres); +fres = NULL; +} else +*paddr = fres->addr; + +return fres; +} + +int xenforeignmemory_unmap_resource( +xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres) +{ +int rc = osdep_xenforeignmemory_unmap_resource(fmem, fres); + +free(fres); +return rc; +} + /* * Local variables: * mode: C diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h b/tools/libs/foreignmemory/include/xenforeignmemory.h index f4814c390f..d594be8df0 100644 --- a/tools/libs/foreignmemory/include/xenforeignmemory.h +++ b/tools/libs/foreignmemory/include/xenforeignmemory.h @@ -138,6 +138,47 @@ int xenforeignmemory_unmap(xenforeignmemory_handle *fmem, int xenforeignmemory_restrict(xenforeignmemory_handle *fmem, domid_t domid); +typedef struct xenforeignmemory_resource_handle xenforeignmemory_resource_handle; + +/** + * This function maps a guest resource. + * + * @parm fmem handle to the open foreignmemory interfac
[Xen-devel] [PATCH v11 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...
...to allow the calling domain to prevent translation of specified l1e value. Despite what the comment in public/xen.h might imply, specifying a command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with the specified value. Instead, mod_l1_entry() tests whether foreign_dom has PG_translate set in its paging mode and, if it does, assumes that the the pfn value in the l1e is a gfn rather than an mfn. To allow PV tools domain to map mfn values from a previously issued HYPERVISOR_memory_op:XENMEM_acquire_resource, there needs to be a way to tell HYPERVISOR_mmu_update that the specific l1e value does not require translation regardless of the paging mode of foreign_dom. This patch therefore defines a new command value, MMU_PT_UPDATE_NO_TRANSLATE, which has the same semantics as MMU_NORMAL_PT_UPDATE except that the paging mode of foreign_dom is ignored and the l1e value is used verbatim. Signed-off-by: Paul Durrant Reviewed-by: Jan Beulich --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu v8: - New in this version, replacing "allow a privileged PV domain to map guest mfns". --- xen/arch/x86/mm.c| 17 ++--- xen/include/public/xen.h | 12 +--- 2 files changed, 19 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index c9bc4a4e92..3dd5b2c00f 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1619,9 +1619,10 @@ void page_unlock(struct page_info *page) /* Update the L1 entry at pl1e to new value nl1e. */ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, -unsigned long gl1mfn, int preserve_ad, +unsigned long gl1mfn, unsigned int cmd, struct vcpu *pt_vcpu, struct domain *pg_dom) { +bool preserve_ad = (cmd == MMU_PT_UPDATE_PRESERVE_AD); l1_pgentry_t ol1e; struct domain *pt_dom = pt_vcpu->domain; int rc = 0; @@ -1643,7 +1644,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, return -EINVAL; } -if ( paging_mode_translate(pg_dom) ) +if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE && + paging_mode_translate(pg_dom) ) { page = get_page_from_gfn(pg_dom, l1e_get_pfn(nl1e), NULL, P2M_ALLOC); if ( !page ) @@ -3258,6 +3260,7 @@ long do_mmu_update( */ case MMU_NORMAL_PT_UPDATE: case MMU_PT_UPDATE_PRESERVE_AD: +case MMU_PT_UPDATE_NO_TRANSLATE: { p2m_type_t p2mt; @@ -3323,7 +3326,8 @@ long do_mmu_update( p2m_query_t q = (l1e_get_flags(l1e) & _PAGE_RW) ? P2M_UNSHARE : P2M_ALLOC; -if ( paging_mode_translate(pg_owner) ) +if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE && + paging_mode_translate(pg_owner) ) target = get_page_from_gfn(pg_owner, l1e_get_pfn(l1e), &l1e_p2mt, q); @@ -3350,9 +3354,7 @@ long do_mmu_update( break; } -rc = mod_l1_entry(va, l1e, mfn, - cmd == MMU_PT_UPDATE_PRESERVE_AD, v, - pg_owner); +rc = mod_l1_entry(va, l1e, mfn, cmd, v, pg_owner); if ( target ) put_page(target); } @@ -3630,7 +3632,8 @@ static int __do_update_va_mapping( goto out; } -rc = mod_l1_entry(pl1e, val, mfn_x(gl1mfn), 0, v, pg_owner); +rc = mod_l1_entry(pl1e, val, mfn_x(gl1mfn), MMU_NORMAL_PT_UPDATE, v, + pg_owner); page_unlock(gl1pg); put_page(gl1pg); diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 2ac6b1e24d..d2014a39eb 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -268,6 +268,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed * with those in @val. * + * ptr[1:0] == MMU_PT_UPDATE_NO_TRANSLATE: + * As MMU_NORMAL_PT_UPDATE above, but @val is not translated though FD + * page tables. + * * @val is usually the machine frame number along with some attributes. * The attributes by default follow the architecture defined bits. Meaning that * if this is a X86_64 machine and four page table layout is used, the layout @@ -334,9 +338,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t); * * PAT (bit 7 on) --> PWT (bit 3 on) and clear bit 7. */ -#define MMU_NORMAL_PT_UPDATE 0 /* checked '*ptr = val'. ptr is MA. */ -#define MMU_MACHPHYS_UPDATE 1 /* ptr = MA of frame to modify entry for */ -#define MMU_PT_UPDATE_PRESERVE_AD 2 /* atomically: *ptr = val | (*ptr&(A|D)) */ +#define MMU_NORMAL_PT_UPDATE 0
[Xen-devel] [PATCH v11 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requsted
A subsequent patch will introduce a new scheme to allow an emulator to map ioreq server pages directly from Xen rather than the guest P2M. This patch lays the groundwork for that change by deferring mapping of gfns until their values are requested by an emulator. To that end, the pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid requesting the gfn values. Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Acked-by: Wei Liu Reviewed-by: Jan Beulich --- Cc: Ian Jackson Cc: Andrew Cooper Cc: George Dunlap Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan v8: - For safety make all of the pointers passed to hvm_get_ioreq_server_info() optional. - Shrink bufioreq_handling down to a uint8_t. v3: - Updated in response to review comments from Wei and Roger. - Added a HANDLE_BUFIOREQ macro to make the code neater. - This patch no longer introduces a security vulnerability since there is now an explicit limit on the number of ioreq servers that may be created for any one domain. --- tools/libs/devicemodel/core.c | 8 + tools/libs/devicemodel/include/xendevicemodel.h | 6 ++-- xen/arch/x86/hvm/dm.c | 9 +++-- xen/arch/x86/hvm/ioreq.c| 47 ++--- xen/include/asm-x86/hvm/domain.h| 2 +- xen/include/public/hvm/dm_op.h | 32 ++--- 6 files changed, 63 insertions(+), 41 deletions(-) diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c index 0f2c1a791f..91c69d103b 100644 --- a/tools/libs/devicemodel/core.c +++ b/tools/libs/devicemodel/core.c @@ -188,6 +188,14 @@ int xendevicemodel_get_ioreq_server_info( data->id = id; +/* + * If the caller is not requesting gfn values then instruct the + * hypercall not to retrieve them as this may cause them to be + * mapped. + */ +if (!ioreq_gfn && !bufioreq_gfn) +data->flags |= XEN_DMOP_no_gfns; + rc = xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); if (rc) return rc; diff --git a/tools/libs/devicemodel/include/xendevicemodel.h b/tools/libs/devicemodel/include/xendevicemodel.h index 13216db04a..d73a76da35 100644 --- a/tools/libs/devicemodel/include/xendevicemodel.h +++ b/tools/libs/devicemodel/include/xendevicemodel.h @@ -61,11 +61,11 @@ int xendevicemodel_create_ioreq_server( * @parm domid the domain id to be serviced * @parm id the IOREQ Server id. * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq - * gfn + * gfn. (May be NULL if not required) * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq - *gfn + *gfn. (May be NULL if not required) * @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered - * ioreq event channel + * ioreq event channel. (May be NULL if not required) * @return 0 on success, -1 on failure. */ int xendevicemodel_get_ioreq_server_info( diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c index 9cf53b551c..22fa5b51e3 100644 --- a/xen/arch/x86/hvm/dm.c +++ b/xen/arch/x86/hvm/dm.c @@ -416,16 +416,19 @@ static int dm_op(const struct dmop_args *op_args) { struct xen_dm_op_get_ioreq_server_info *data = &op.u.get_ioreq_server_info; +const uint16_t valid_flags = XEN_DMOP_no_gfns; const_op = false; rc = -EINVAL; -if ( data->pad ) +if ( data->flags & ~valid_flags ) break; rc = hvm_get_ioreq_server_info(d, data->id, - &data->ioreq_gfn, - &data->bufioreq_gfn, + (data->flags & XEN_DMOP_no_gfns) ? + NULL : &data->ioreq_gfn, + (data->flags & XEN_DMOP_no_gfns) ? + NULL : &data->bufioreq_gfn, &data->bufioreq_port); break; } diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index 64bb13cec9..f654e7796c 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -350,6 +350,9 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server *s, } } +#define HANDLE_BUFIOREQ(s) \ +((s)->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF) + static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s, struct vcpu *v) { @@ -371,7 +374,7 @@ static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s, sv->ioreq_evtchn = rc; -if ( v->vcpu_id == 0 && s->bufioreq.va != NULL ) +if ( v->vcpu_id
[Xen-devel] [PATCH v11 00/11] x86: guest resource mapping
This series introduces support for direct mapping of guest resources. The resources are: - IOREQ server pages - Grant tables v10: - Responded to comments from Jan. v9: - Change to patch #1 only. v8: - Re-ordered series and dropped two patches that have already been committed. v7: - Fixed assertion failure hit during domain destroy. v6: - Responded to missed comments from Roger. v5: - Responded to review comments from Wei. v4: - Responded to further review comments from Roger. v3: - Dropped original patch #1 since it is covered by Juergen's patch. - Added new xenforeignmemorycleanup patch (#4). - Replaced the patch introducing the ioreq server 'is_default' flag with one that changes the ioreq server list into an array (#8). Paul Durrant (11): x86/hvm/ioreq: maintain an array of ioreq servers rather than a list x86/hvm/ioreq: simplify code and use consistent naming x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page x86/hvm/ioreq: defer mapping gfns until they are actually requsted x86/mm: add HYPERVISOR_memory_op to acquire guest resources x86/hvm/ioreq: add a new mappable resource type... x86/mm: add an extra command to HYPERVISOR_mmu_update... tools/libxenforeignmemory: add support for resource mapping tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint common: add a new mappable resource type: XENMEM_resource_grant_table tools/libxenctrl: use new xenforeignmemory API to seed grant table tools/flask/policy/modules/xen.if | 4 +- tools/include/xen-sys/Linux/privcmd.h | 11 + tools/libs/devicemodel/core.c | 8 + tools/libs/devicemodel/include/xendevicemodel.h| 6 +- tools/libs/foreignmemory/Makefile | 2 +- tools/libs/foreignmemory/core.c| 53 ++ tools/libs/foreignmemory/freebsd.c | 7 - .../libs/foreignmemory/include/xenforeignmemory.h | 41 + tools/libs/foreignmemory/libxenforeignmemory.map | 5 + tools/libs/foreignmemory/linux.c | 45 ++ tools/libs/foreignmemory/minios.c | 7 - tools/libs/foreignmemory/netbsd.c | 7 - tools/libs/foreignmemory/private.h | 43 +- tools/libs/foreignmemory/solaris.c | 7 - tools/libxc/include/xc_dom.h | 8 +- tools/libxc/xc_dom_boot.c | 114 ++- tools/libxc/xc_sr_restore_x86_hvm.c| 10 +- tools/libxc/xc_sr_restore_x86_pv.c | 2 +- tools/libxl/libxl_dom.c| 1 - tools/python/xen/lowlevel/xc/xc.c | 6 +- xen/arch/x86/hvm/dm.c | 9 +- xen/arch/x86/hvm/ioreq.c | 829 - xen/arch/x86/mm.c | 39 +- xen/arch/x86/mm/p2m.c | 3 +- xen/common/compat/memory.c | 145 +++- xen/common/grant_table.c | 63 +- xen/common/memory.c| 137 xen/include/asm-x86/hvm/domain.h | 14 +- xen/include/asm-x86/hvm/ioreq.h| 2 + xen/include/asm-x86/mm.h | 5 + xen/include/asm-x86/p2m.h | 3 + xen/include/public/hvm/dm_op.h | 36 +- xen/include/public/memory.h| 58 +- xen/include/public/xen.h | 12 +- xen/include/xen/grant_table.h | 4 + xen/include/xlat.lst | 1 + xen/include/xsm/dummy.h| 6 + xen/include/xsm/xsm.h | 6 + xen/xsm/dummy.c| 1 + xen/xsm/flask/hooks.c | 6 + xen/xsm/flask/policy/access_vectors| 2 + 41 files changed, 1267 insertions(+), 501 deletions(-) --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page
This patch adjusts the ioreq server code to use type-safe gfn_t values where possible. No functional change. Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Reviewed-by: Wei Liu Acked-by: Jan Beulich --- Cc: Andrew Cooper --- xen/arch/x86/hvm/ioreq.c | 44 xen/include/asm-x86/hvm/domain.h | 2 +- 2 files changed, 23 insertions(+), 23 deletions(-) diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index 6d81018369..64bb13cec9 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -210,7 +210,7 @@ bool handle_hvm_io_completion(struct vcpu *v) return true; } -static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s) +static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s) { struct domain *d = s->domain; unsigned int i; @@ -220,20 +220,19 @@ static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s) for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ ) { if ( test_and_clear_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask) ) -return d->arch.hvm_domain.ioreq_gfn.base + i; +return _gfn(d->arch.hvm_domain.ioreq_gfn.base + i); } -return gfn_x(INVALID_GFN); +return INVALID_GFN; } -static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, - unsigned long gfn) +static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, gfn_t gfn) { struct domain *d = s->domain; -unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base; +unsigned int i = gfn_x(gfn) - d->arch.hvm_domain.ioreq_gfn.base; ASSERT(!IS_DEFAULT(s)); -ASSERT(gfn != gfn_x(INVALID_GFN)); +ASSERT(!gfn_eq(gfn, INVALID_GFN)); set_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask); } @@ -242,7 +241,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) { struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; -if ( iorp->gfn == gfn_x(INVALID_GFN) ) +if ( gfn_eq(iorp->gfn, INVALID_GFN) ) return; destroy_ring_for_helper(&iorp->va, iorp->page); @@ -251,7 +250,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) if ( !IS_DEFAULT(s) ) hvm_free_ioreq_gfn(s, iorp->gfn); -iorp->gfn = gfn_x(INVALID_GFN); +iorp->gfn = INVALID_GFN; } static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) @@ -264,16 +263,17 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) return -EINVAL; if ( IS_DEFAULT(s) ) -iorp->gfn = buf ? -d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] : -d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN]; +iorp->gfn = _gfn(buf ? + d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] : + d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN]); else iorp->gfn = hvm_alloc_ioreq_gfn(s); -if ( iorp->gfn == gfn_x(INVALID_GFN) ) +if ( gfn_eq(iorp->gfn, INVALID_GFN) ) return -ENOMEM; -rc = prepare_ring_for_helper(d, iorp->gfn, &iorp->page, &iorp->va); +rc = prepare_ring_for_helper(d, gfn_x(iorp->gfn), &iorp->page, + &iorp->va); if ( rc ) hvm_unmap_ioreq_gfn(s, buf); @@ -309,10 +309,10 @@ static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) struct domain *d = s->domain; struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; -if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) ) +if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) ) return; -if ( guest_physmap_remove_page(d, _gfn(iorp->gfn), +if ( guest_physmap_remove_page(d, iorp->gfn, _mfn(page_to_mfn(iorp->page)), 0) ) domain_crash(d); clear_page(iorp->va); @@ -324,12 +324,12 @@ static int hvm_add_ioreq_gfn(struct hvm_ioreq_server *s, bool buf) struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; int rc; -if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) ) +if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) ) return 0; clear_page(iorp->va); -rc = guest_physmap_add_page(d, _gfn(iorp->gfn), +rc = guest_physmap_add_page(d, iorp->gfn, _mfn(page_to_mfn(iorp->page)), 0); if ( rc == 0 ) paging_mark_dirty(d, _mfn(page_to_mfn(iorp->page))); @@ -590,8 +590,8 @@ static int hvm_ioreq_server_init(struct hvm_ioreq_server *s, INIT_LIST_HEAD(&s->ioreq_vcpu_list); spin_lock_init(&s->bufioreq_lock); -s->ioreq.gfn = gfn_x(INVALID_GFN); -s->bufioreq.gfn = gfn_x(INVALID_GFN); +s->ioreq.gfn = INVALID_GFN; +s->bufioreq.gfn = INVALID_GFN; rc = hvm_ioreq_server_alloc_rangesets(s, id); if ( rc ) @@ -757,11 +757,11 @@ int hvm_get_ioreq_server_info(struct domain *d, ioservid_t id,
[Xen-devel] [PATCH v11 09/11] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint
By using a static inline stub in private.h for OS where this functionality is not implemented, the various duplicate stubs in the OS-specific source modules can be avoided. Signed-off-by: Paul Durrant Reviewed-by: Roger Pau Monné Acked-by: Wei Liu --- Cc: Ian Jackson v4: - Removed extraneous freebsd code. v3: - Patch added in response to review comments. --- tools/libs/foreignmemory/freebsd.c | 7 --- tools/libs/foreignmemory/minios.c | 7 --- tools/libs/foreignmemory/netbsd.c | 7 --- tools/libs/foreignmemory/private.h | 12 +--- tools/libs/foreignmemory/solaris.c | 7 --- 5 files changed, 9 insertions(+), 31 deletions(-) diff --git a/tools/libs/foreignmemory/freebsd.c b/tools/libs/foreignmemory/freebsd.c index dec447485a..6e6bc4b11f 100644 --- a/tools/libs/foreignmemory/freebsd.c +++ b/tools/libs/foreignmemory/freebsd.c @@ -95,13 +95,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem, return munmap(addr, num << PAGE_SHIFT); } -int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem, -domid_t domid) -{ -errno = -EOPNOTSUPP; -return -1; -} - /* * Local variables: * mode: C diff --git a/tools/libs/foreignmemory/minios.c b/tools/libs/foreignmemory/minios.c index 75f340122e..43341ca301 100644 --- a/tools/libs/foreignmemory/minios.c +++ b/tools/libs/foreignmemory/minios.c @@ -58,13 +58,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem, return munmap(addr, num << PAGE_SHIFT); } -int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem, -domid_t domid) -{ -errno = -EOPNOTSUPP; -return -1; -} - /* * Local variables: * mode: C diff --git a/tools/libs/foreignmemory/netbsd.c b/tools/libs/foreignmemory/netbsd.c index 9bf95ef4f0..54a418ebd6 100644 --- a/tools/libs/foreignmemory/netbsd.c +++ b/tools/libs/foreignmemory/netbsd.c @@ -100,13 +100,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem, return munmap(addr, num*XC_PAGE_SIZE); } -int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem, -domid_t domid) -{ -errno = -EOPNOTSUPP; -return -1; -} - /* * Local variables: * mode: C diff --git a/tools/libs/foreignmemory/private.h b/tools/libs/foreignmemory/private.h index 80b22bdbfc..b5d5f0a354 100644 --- a/tools/libs/foreignmemory/private.h +++ b/tools/libs/foreignmemory/private.h @@ -32,9 +32,6 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem, int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem, void *addr, size_t num); -int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem, -domid_t domid); - #if defined(__NetBSD__) || defined(__sun__) /* Strictly compat for those two only only */ void *compat_mapforeign_batch(xenforeignmem_handle *fmem, uint32_t dom, @@ -54,6 +51,13 @@ struct xenforeignmemory_resource_handle { }; #ifndef __linux__ +static inline int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem, + domid_t domid) +{ +errno = EOPNOTSUPP; +return -1; +} + static inline int osdep_xenforeignmemory_map_resource( xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres) { @@ -67,6 +71,8 @@ static inline int osdep_xenforeignmemory_unmap_resource( return 0; } #else +int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem, +domid_t domid); int osdep_xenforeignmemory_map_resource( xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres); int osdep_xenforeignmemory_unmap_resource( diff --git a/tools/libs/foreignmemory/solaris.c b/tools/libs/foreignmemory/solaris.c index a33decb4ae..ee8aae4fbd 100644 --- a/tools/libs/foreignmemory/solaris.c +++ b/tools/libs/foreignmemory/solaris.c @@ -97,13 +97,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem, return munmap(addr, num*XC_PAGE_SIZE); } -int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem, -domid_t domid) -{ -errno = -EOPNOTSUPP; -return -1; -} - /* * Local variables: * mode: C -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-next 2/3] xen/x86: Introduce static inline wrappers for l{idt, gdt, ldt, tr}()
On 12/10/17 16:53, Jan Beulich wrote: On 02.10.17 at 18:13, wrote: >> The triple-fault reboot method stays as is, to avoid the int3 possibly >> getting >> moved relative to the lidt. > Aren't asm volatile()s ordered wrt to one another? >From the docs "Note that the compiler can move even volatile |asm| instructions relative to other code, including across jump instructions." Also, I seem to recall Tim finding an example where GCC 6 did reorder two asm volatiles relative to each other, due to their output operands not being causally linked. On that note however, these should gain memory clobbers to make them full barriers. l{i,g}dt() are serialising, while nothing good will come of having a segment register access reordered with respect to l{g,l}dt(). > >> --- a/xen/include/asm-x86/desc.h >> +++ b/xen/include/asm-x86/desc.h >> @@ -197,6 +197,26 @@ DECLARE_PER_CPU(struct desc_struct *, compat_gdt_table); >> >> extern void load_TR(void); >> >> +static inline void lgdt(const struct desc_ptr *gdtr) >> +{ >> +asm volatile ("lgdt %0" :: "m" (*gdtr)); >> +} >> + >> +static inline void lidt(const struct desc_ptr *idtr) >> +{ >> +asm volatile ("lidt %0" :: "m" (*idtr)); >> +} >> + >> +static inline void lldt(unsigned int sel) >> +{ >> +asm volatile ("lldt %w0" :: "rm" (sel)); >> +} >> + >> +static inline void ltr(unsigned int sel) >> +{ >> +asm volatile ("ltr %w0" :: "rm" (sel)); >> +} > As can be seen from the code you replace in ldt.h, in headers we > generally prefer to use __asm__ (and __volatile__ where needed). > I'm sure this isn't consistent, so I won't insist. However, style-wise > please add blanks immediately inside the parentheses. With at least > this last point taken care of Will do. > Reviewed-by: Jan Beulich Does this still stand in light of the barrier change above? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-next 3/3] x86/ldt: Alter how invalidate_shadow_ldt() deals with TLB flushes
>>> On 02.10.17 at 18:13, wrote: > @@ -518,26 +522,29 @@ static void invalidate_shadow_ldt(struct vcpu *v, int > flush) > if ( v->arch.pv_vcpu.shadow_ldt_mapcnt == 0 ) > goto out; > > -v->arch.pv_vcpu.shadow_ldt_mapcnt = 0; > pl1e = pv_ldt_ptes(v); > > for ( i = 0; i < 16; i++ ) > { > if ( !(l1e_get_flags(pl1e[i]) & _PAGE_PRESENT) ) > continue; > + > page = l1e_get_page(pl1e[i]); > l1e_write(&pl1e[i], l1e_empty()); > +mappings_dropped++; > + > ASSERT_PAGE_IS_TYPE(page, PGT_seg_desc_page); > ASSERT_PAGE_IS_DOMAIN(page, v->domain); > put_page_and_type(page); > } > > -/* Rid TLBs of stale mappings (guest mappings and shadow mappings). */ > -if ( flush ) > -flush_tlb_mask(v->vcpu_dirty_cpumask); > +ASSERT(v->arch.pv_vcpu.shadow_ldt_mapcnt == mappings_dropped); > +v->arch.pv_vcpu.shadow_ldt_mapcnt = 0; > > out: > spin_unlock(&v->arch.pv_vcpu.shadow_ldt_lock); > + > +return !!mappings_dropped; You don't need the !! here. With that Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-next 2/3] xen/x86: Introduce static inline wrappers for l{idt, gdt, ldt, tr}()
>>> On 02.10.17 at 18:13, wrote: > The triple-fault reboot method stays as is, to avoid the int3 possibly getting > moved relative to the lidt. Aren't asm volatile()s ordered wrt to one another? > --- a/xen/include/asm-x86/desc.h > +++ b/xen/include/asm-x86/desc.h > @@ -197,6 +197,26 @@ DECLARE_PER_CPU(struct desc_struct *, compat_gdt_table); > > extern void load_TR(void); > > +static inline void lgdt(const struct desc_ptr *gdtr) > +{ > +asm volatile ("lgdt %0" :: "m" (*gdtr)); > +} > + > +static inline void lidt(const struct desc_ptr *idtr) > +{ > +asm volatile ("lidt %0" :: "m" (*idtr)); > +} > + > +static inline void lldt(unsigned int sel) > +{ > +asm volatile ("lldt %w0" :: "rm" (sel)); > +} > + > +static inline void ltr(unsigned int sel) > +{ > +asm volatile ("ltr %w0" :: "rm" (sel)); > +} As can be seen from the code you replace in ldt.h, in headers we generally prefer to use __asm__ (and __volatile__ where needed). I'm sure this isn't consistent, so I won't insist. However, style-wise please add blanks immediately inside the parentheses. With at least this last point taken care of Reviewed-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
On 2017.10.12 at 08:34 -0700, Thomas Garnier wrote: > On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky wrote: > > On 10/11/2017 3:30 PM, Thomas Garnier wrote: > >> Changes: > >> - patch v1: > >> - Simplify ftrace implementation. > >> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. > >> - rfc v3: > >> - Use --emit-relocs instead of -pie to reduce dynamic relocation space > >> on > >> mapped memory. It also simplifies the relocation process. > >> - Move the start the module section next to the kernel. Remove the > >> need for > >> -mcmodel=large on modules. Extends module space from 1 to 2G maximum. > >> - Support for XEN PVH as 32-bit relocations can be ignored with > >> --emit-relocs. > >> - Support for GOT relocations previously done automatically with -pie. > >> - Remove need for dynamic PLT in modules. > >> - Support dymamic GOT for modules. > >> - rfc v2: > >> - Add support for global stack cookie while compiler default to fs > >> without > >> mcmodel=kernel > >> - Change patch 7 to correctly jump out of the identity mapping on > >> kexec load > >> preserve. > >> > >> These patches make the changes necessary to build the kernel as Position > >> Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below > >> the top 2G of the virtual address space. It allows to optionally extend the > >> KASLR randomization range from 1G to 3G. > > > > Hi Thomas, > > > > I've applied your patches so that I can verify that SME works with PIE. > > Unfortunately, I'm running into build warnings and errors when I enable > > PIE. > > > > With CONFIG_STACK_VALIDATION=y I receive lots of messages like this: > > > > drivers/scsi/libfc/fc_exch.o: warning: objtool: > > fc_destroy_exch_mgr()+0x0: call without frame pointer save/setup > > > > Disabling CONFIG_STACK_VALIDATION suppresses those. > > I ran into that, I plan to fix it in the next iteration. > > > > > But near the end of the build, I receive errors like this: > > > > arch/x86/kernel/setup.o: In function `dump_kernel_offset': > > .../arch/x86/kernel/setup.c:801:(.text+0x32): relocation truncated to > > fit: R_X86_64_32S against symbol `_text' defined in .text section in > > .tmp_vmlinux1 > > . > > . about 10 more of the above type messages > > . > > make: *** [vmlinux] Error 1 > > Error building kernel, exiting > > > > Are there any config options that should or should not be enabled when > > building with PIE enabled? Is there a compiler requirement for PIE (I'm > > using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))? > > I never ran into these ones and I tested compilers older and newer. > What was your exact configuration? I get with gcc trunk and CONFIG_RANDOMIZE_BASE_LARGE=y: ... MODPOST vmlinux.o ld: failed to convert GOTPCREL relocation; relink with --no-relax and after adding --no-relax to vmlinux_link() in scripts/link-vmlinux.sh: MODPOST vmlinux.o virt/kvm/vfio.o: In function `kvm_vfio_update_coherency.isra.4': vfio.c:(.text+0x63): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_external_check_extension' virt/kvm/vfio.o: In function `kvm_vfio_destroy': vfio.c:(.text+0xf7): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_set_kvm' vfio.c:(.text+0x10a): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_put_external_user' virt/kvm/vfio.o: In function `kvm_vfio_set_attr': vfio.c:(.text+0x2bc): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_external_group_match_file' vfio.c:(.text+0x307): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_set_kvm' vfio.c:(.text+0x31a): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_put_external_user' vfio.c:(.text+0x3b9): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_get_external_user' vfio.c:(.text+0x462): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_set_kvm' vfio.c:(.text+0x4bd): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_put_external_user' make: *** [Makefile:1000: vmlinux] Error 1 Works fine with CONFIG_RANDOMIZE_BASE_LARGE unset. -- Markus config.gz Description: application/gunzip ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest
On 12/10/2017 14:45, Haozhong Zhang wrote: > Basically, QEMU builds two ROMs for guest, /rom@etc/acpi/tables and > /rom@etc/table-loader. The former is unstructured to guest, and > contains all data of guest ACPI. The latter is a BIOSLinkerLoader > organized as a set of commands, which direct the guest (e.g., SeaBIOS > on KVM/QEMU) to relocate data in the former file, recalculate checksum > of specified area, and fill guest address in specified ACPI field. > > One part of my patches is to implement a mechanism to tell Xen which > part of ACPI data is a table (NFIT), and which part defines a > namespace device and what the device name is. I can add two new loader > commands for them respectively. > > Because they just provide information and SeaBIOS in non-xen > environment ignores unrecognized commands, they will not break SeaBIOS > in non-xen environment. > > On QEMU side, most Xen-specific hacks in ACPI builder could be > dropped, and replaced by adding the new loader commands (though they > may be used only by Xen). > > On Xen side, a fw_cfg driver and a BIOSLinkerLoader command executor > are needed in, perhaps, hvmloader. If Xen has to parse BIOSLinkerLoader, it can use the existing commands to process a reduced set of ACPI tables. In other words, etc/acpi/tables would only include the NFIT, the SSDT with namespace devices, and the XSDT. etc/acpi/rsdp would include the RSDP table as usual. hvmloader can then: 1) allocate some memory for where the XSDT will go 2) process the BIOSLinkerLoader like SeaBIOS would do 3) find the RSDP in low memory, since the loader script must have placed it there. If it cannot find it, allocate some low memory, fill it with the RSDP header and revision, and and jump to step 6 4) If it found QEMU's RSDP, use it to find QEMU's XSDT 5) Copy ACPI table pointers from QEMU to hvmloader's RSDT and/or XSDT. 6) build hvmloader tables and link them into the RSDT and/or XSDT as usual. 7) overwrite the RSDP in low memory with a pointer to hvmloader's own RSDT and/or XSDT, and updated the checksums QEMU's XSDT remains there somewhere in memory, unused but harmless. Paolo ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-next 1/3] x86/smp: Rework cpu_smpboot_alloc() to cope with more than just -ENOMEM
>>> On 02.10.17 at 18:13, wrote: > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()
>>> On 12.10.17 at 17:24, wrote: > On 12/10/17 16:08, Jan Beulich wrote: > On 12.10.17 at 15:54, wrote: >>> --- a/xen/arch/x86/mm/hap/hap.c >>> +++ b/xen/arch/x86/mm/hap/hap.c >>> @@ -391,41 +391,24 @@ int hap_set_allocation(struct domain *d, unsigned int > pages, bool *preempted) >>> return 0; >>> } >>> >>> -static void hap_install_xen_entries_in_l4(struct vcpu *v, mfn_t l4mfn) >>> -{ >>> -struct domain *d = v->domain; >>> -l4_pgentry_t *l4e; >>> - >>> -l4e = map_domain_page(l4mfn); >>> - >>> -/* Copy the common Xen mappings from the idle domain */ >>> -memcpy(&l4e[ROOT_PAGETABLE_FIRST_XEN_SLOT], >>> - &idle_pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT], >>> - ROOT_PAGETABLE_XEN_SLOTS * sizeof(l4_pgentry_t)); >>> - >>> -/* Install the per-domain mappings for this domain */ >>> -l4e[l4_table_offset(PERDOMAIN_VIRT_START)] = >>> -l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW); >>> - >>> -/* Install a linear mapping */ >>> -l4e[l4_table_offset(LINEAR_PT_VIRT_START)] = >>> -l4e_from_mfn(l4mfn, __PAGE_HYPERVISOR_RW); >>> - >>> -unmap_domain_page(l4e); >>> -} >>> - >>> static mfn_t hap_make_monitor_table(struct vcpu *v) >>> { >>> struct domain *d = v->domain; >>> struct page_info *pg; >>> +l4_pgentry_t *l4e; >>> mfn_t m4mfn; >>> >>> ASSERT(pagetable_get_pfn(v->arch.monitor_table) == 0); >>> >>> if ( (pg = hap_alloc(d)) == NULL ) >>> goto oom; >>> + >>> m4mfn = page_to_mfn(pg); >>> -hap_install_xen_entries_in_l4(v, m4mfn); >>> +l4e = __map_domain_page(pg); >> If you obtain the MFN anyway, map_domain_page() is cheaper >> generated code wise. > > Ah yes. Given that __map_domain_page() is a define, I'd hope the > compiler can spot and optimise away the double page_to_mfn(). Considering this is a non-trivial operation, I'm afraid many (if not all) compiler versions won't be smart enough. >>> --- a/xen/arch/x86/pv/domain.c >>> +++ b/xen/arch/x86/pv/domain.c >>> @@ -35,7 +35,7 @@ static int setup_compat_l4(struct vcpu *v) >>> >>> l4tab = __map_domain_page(pg); >>> clear_page(l4tab); >>> -init_guest_l4_table(l4tab, v->domain, 1); >>> +init_xen_l4_slots(l4tab, page_to_mfn(pg), v->domain, INVALID_MFN, > false); >> Perhaps worth avoiding the double translation here too. >> >> In any event >> Reviewed-by: Jan Beulich > > Just to confirm, the additional delta is: Yes, looks fine, thanks. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 11/12] fuzz/x86_emulate: Set and fuzz more CPU state
>>> On 11.10.17 at 19:52, wrote: > The Intel manual claims that, "If [certain CPUID bits] are set, the > processor deprecates FCS and FDS, and the field is saved as h"; > but experimentally it would be more accurate to say, "the field is > occasionally saved as h". This causes the --rerun checking to > trip non-deterministically. Sanitize them to zero. I think we've meanwhile settled on the field being saved as zero being a side effect of using 32-bit fxsave plus a context switch in the OS kernel. > @@ -594,6 +595,75 @@ static const struct x86_emulate_ops all_fuzzer_ops = { > }; > #undef SET > > +/* > + * This funciton will read or write fxsave to the fpu. When writing, > + * it 'sanitizes' the state: It will mask off the appropriate bits in > + * the mxcsr, 'restore' the state to the fpu, then 'save' it again so > + * that the data in fxsave reflects what's actually in the FPU. > + * > + * TODO: Extend state beyond just FPU (ymm registers, &c) > + */ > +static void _set_fpu_state(char *fxsave, bool write) > +{ > +if ( cpu_has_fxsr ) > +{ > +static union __attribute__((__aligned__(16))) { > +char x[512]; > +struct { > +uint16_t cw, sw; > +uint8_t tw, _rsvd1; > +uint16_t op; > +uint32_t ip; > +uint16_t cs, _rsvd2; > +uint32_t dp; > +uint16_t ds, _rsvd3; > +uint32_t mxcsr; > +uint32_t mxcsr_mask; > +/* ... */ > +}; > +} *fxs; > + > +fxs = (typeof(fxs))fxsave; > + > +if ( write ) > +{ > +/* > + * Clear reserved bits to make sure we don't get any > + * exceptions > + */ > +fxs->mxcsr &= mxcsr_mask; > + > +/* > + * The Intel manual says that on newer models CS/DS are > + * deprecated and that these fields "are saved as h". > + * Experimentally, however, at least on my test box, > + * whether this saved as h or as the previously > + * written value is random; meaning that when run with > + * --rerun, we occasionally detect a "state mismatch" in these > + * bytes. Instead, simply sanitize them to zero. > + * > + * TODO Check CPUID as specified in the manual before > + * clearing > + */ > +fxs->cs = fxs->ds = 0; Shouldn't be needed anymore with ... > +asm volatile( "fxrstor %0" :: "m" (*fxs) ); rex64 (or fxrstor64) used here and ... > +} > + > +asm volatile( "fxsave %0" : "=m" (*fxs) ); ... here (of course the alternative here then is fxsave64). Also please add blanks before the opening parentheses. > @@ -732,6 +806,18 @@ static void setup_state(struct x86_emulate_ctxt *ctxt) > printf("Setting cpu_user_regs offset %x\n", offset); > continue; > } > +offset -= sizeof(struct cpu_user_regs); > + > +/* Fuzz fxsave state */ > +if ( offset < sizeof(s->fxsave) / 4 ) You've switched to sizeof() here but ... > +{ > +/* 32-bit size is arbitrary; see comment above */ > +if ( !input_read(s, s->fxsave + (offset * 4), 4) ) > +return; > +printf("Setting fxsave offset %x\n", offset * 4); > +continue; > +} > +offset -= 128; ... not here. > @@ -1008,6 +1098,16 @@ static void compare_states(struct fuzz_state state[2]) > if ( memcmp(&state[0].ops, &state[1].ops, sizeof(state[0].ops)) ) > printf("ops differ!\n"); > > +if ( memcmp(&state[0].fxsave, &state[1].fxsave, > sizeof(state[0].fxsave)) ) > +{ > +printf("fxsave differs!\n"); > +for ( i = 0; i < sizeof(state[0].fxsave)/sizeof(unsigned); i++ ) Blanks around / again please. > +{ > +printf("[%04lu] %08x %08x\n", I think I've indicated before that I consider leading zeros on decimal numbers misleading. Could I talk you into using %4lu instead (or really %4zu, considering the expression type) in places like this one (i.e. also in the earlier patch, where I notice only now the l -> z conversion wasn't done consistently either)? > +i * sizeof(unsigned), ((unsigned > *)&state[0].fxsave)[i], ((unsigned *)&state[1].fxsave)[i]); Long line. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 114421: trouble: blocked/broken/pass
flight 114421 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/114421/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf 4 host-install(4)broken REGR. vs. 114299 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass version targeted for testing: xen cc08c73c8c1f5ba5ed0f8274548db6725e1c3157 baseline version: xen 3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a Last test of basis 114299 2017-10-10 21:02:54 Z1 days Failing since114308 2017-10-10 23:01:10 Z1 days 16 attempts Testing same since 114421 2017-10-12 14:02:25 Z0 days1 attempts People who touched revisions under test: Alexandru Isaila Andre Przywara Andrew Cooper Boris Ostrovsky George Dunlap Ian Jackson Jan Beulich Julien Grall Julien Grall Konrad Rzeszutek Wilk Meng Xu Ross Lagerwall Stefano Stabellini Tim Deegan Vitaly Kuznetsov Volodymyr Babchuk Wei Liu Yi Sun jobs: build-amd64 pass build-armhf broken build-amd64-libvirt pass test-armhf-armhf-xl blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-armhf broken broken-step build-armhf host-install(4) Not pushing. (No revision log; it would be 1466 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky wrote: > On 10/11/2017 3:30 PM, Thomas Garnier wrote: >> Changes: >> - patch v1: >> - Simplify ftrace implementation. >> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. >> - rfc v3: >> - Use --emit-relocs instead of -pie to reduce dynamic relocation space on >> mapped memory. It also simplifies the relocation process. >> - Move the start the module section next to the kernel. Remove the need >> for >> -mcmodel=large on modules. Extends module space from 1 to 2G maximum. >> - Support for XEN PVH as 32-bit relocations can be ignored with >> --emit-relocs. >> - Support for GOT relocations previously done automatically with -pie. >> - Remove need for dynamic PLT in modules. >> - Support dymamic GOT for modules. >> - rfc v2: >> - Add support for global stack cookie while compiler default to fs >> without >> mcmodel=kernel >> - Change patch 7 to correctly jump out of the identity mapping on kexec >> load >> preserve. >> >> These patches make the changes necessary to build the kernel as Position >> Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below >> the top 2G of the virtual address space. It allows to optionally extend the >> KASLR randomization range from 1G to 3G. > > Hi Thomas, > > I've applied your patches so that I can verify that SME works with PIE. > Unfortunately, I'm running into build warnings and errors when I enable > PIE. > > With CONFIG_STACK_VALIDATION=y I receive lots of messages like this: > > drivers/scsi/libfc/fc_exch.o: warning: objtool: fc_destroy_exch_mgr()+0x0: > call without frame pointer save/setup > > Disabling CONFIG_STACK_VALIDATION suppresses those. I ran into that, I plan to fix it in the next iteration. > > But near the end of the build, I receive errors like this: > > arch/x86/kernel/setup.o: In function `dump_kernel_offset': > .../arch/x86/kernel/setup.c:801:(.text+0x32): relocation truncated to fit: > R_X86_64_32S against symbol `_text' defined in .text section in .tmp_vmlinux1 > . > . about 10 more of the above type messages > . > make: *** [vmlinux] Error 1 > Error building kernel, exiting > > Are there any config options that should or should not be enabled when > building with PIE enabled? Is there a compiler requirement for PIE (I'm > using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))? I never ran into these ones and I tested compilers older and newer. What was your exact configuration? > > Thanks, > Tom > >> >> Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler >> changes, PIE support and KASLR in general. Thanks to Roland McGrath on his >> feedback for using -pie versus --emit-relocs and details on compiler code >> generation. >> >> The patches: >> - 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant. >> - 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically. >> - 14: Adapt percpu design to work correctly when PIE is enabled. >> - 15: Provide an option to default visibility to hidden except for key >> symbols. >> It removes errors between compilation units. >> - 16: Adapt relocation tool to handle PIE binary correctly. >> - 19: Add support for global cookie. >> - 20: Support ftrace with PIE (used on Ubuntu config). >> - 21: Fix incorrect address marker on dump_pagetables. >> - 22: Add option to move the module section just after the kernel. >> - 23: Adapt module loading to support PIE with dynamic GOT. >> - 24: Make the GOT read-only. >> - 25: Add the CONFIG_X86_PIE option (off by default). >> - 26: Adapt relocation tool to generate a 64-bit relocation table. >> - 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation >> range >> from 1G to 3G (off by default). >> >> Performance/Size impact: >> >> Size of vmlinux (Default configuration): >> File size: >> - PIE disabled: +0.31% >> - PIE enabled: -3.210% (less relocations) >> .text section: >> - PIE disabled: +0.000644% >> - PIE enabled: +0.837% >> >> Size of vmlinux (Ubuntu configuration): >> File size: >> - PIE disabled: -0.201% >> - PIE enabled: -0.082% >> .text section: >> - PIE disabled: same >> - PIE enabled: +1.319% >> >> Size of vmlinux (Default configuration + ORC): >> File size: >> - PIE enabled: -3.167% >> .text section: >> - PIE enabled: +0.814% >> >> Size of vmlinux (Ubuntu configuration + ORC): >> File size: >> - PIE enabled: -3.167% >> .text section: >> - PIE enabled: +1.26% >> >> The size increase is mainly due to not having access to the 32-bit signed >> relocation that can be used with mcmodel=kernel. A small part is due to >> reduced >> optimization for PIE code. This bug [1] was opened with gcc to provide a >> better >> code generation for kernel PIE. >> >> Hackbench (50% and 1600% on thread/process for pipe/sockets): >> - PIE disabled: no sign
Re: [Xen-devel] [PATCH 3/3] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()
On 12/10/17 16:08, Jan Beulich wrote: On 12.10.17 at 15:54, wrote: >> --- a/xen/arch/x86/mm/hap/hap.c >> +++ b/xen/arch/x86/mm/hap/hap.c >> @@ -391,41 +391,24 @@ int hap_set_allocation(struct domain *d, unsigned int >> pages, bool *preempted) >> return 0; >> } >> >> -static void hap_install_xen_entries_in_l4(struct vcpu *v, mfn_t l4mfn) >> -{ >> -struct domain *d = v->domain; >> -l4_pgentry_t *l4e; >> - >> -l4e = map_domain_page(l4mfn); >> - >> -/* Copy the common Xen mappings from the idle domain */ >> -memcpy(&l4e[ROOT_PAGETABLE_FIRST_XEN_SLOT], >> - &idle_pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT], >> - ROOT_PAGETABLE_XEN_SLOTS * sizeof(l4_pgentry_t)); >> - >> -/* Install the per-domain mappings for this domain */ >> -l4e[l4_table_offset(PERDOMAIN_VIRT_START)] = >> -l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW); >> - >> -/* Install a linear mapping */ >> -l4e[l4_table_offset(LINEAR_PT_VIRT_START)] = >> -l4e_from_mfn(l4mfn, __PAGE_HYPERVISOR_RW); >> - >> -unmap_domain_page(l4e); >> -} >> - >> static mfn_t hap_make_monitor_table(struct vcpu *v) >> { >> struct domain *d = v->domain; >> struct page_info *pg; >> +l4_pgentry_t *l4e; >> mfn_t m4mfn; >> >> ASSERT(pagetable_get_pfn(v->arch.monitor_table) == 0); >> >> if ( (pg = hap_alloc(d)) == NULL ) >> goto oom; >> + >> m4mfn = page_to_mfn(pg); >> -hap_install_xen_entries_in_l4(v, m4mfn); >> +l4e = __map_domain_page(pg); > If you obtain the MFN anyway, map_domain_page() is cheaper > generated code wise. Ah yes. Given that __map_domain_page() is a define, I'd hope the compiler can spot and optimise away the double page_to_mfn(). Either way, fixed. > >> --- a/xen/arch/x86/pv/domain.c >> +++ b/xen/arch/x86/pv/domain.c >> @@ -35,7 +35,7 @@ static int setup_compat_l4(struct vcpu *v) >> >> l4tab = __map_domain_page(pg); >> clear_page(l4tab); >> -init_guest_l4_table(l4tab, v->domain, 1); >> +init_xen_l4_slots(l4tab, page_to_mfn(pg), v->domain, INVALID_MFN, >> false); > Perhaps worth avoiding the double translation here too. > > In any event > Reviewed-by: Jan Beulich Just to confirm, the additional delta is: andrewcoop@andrewcoop:/local/xen.git/xen$ git diff diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c index 1e7e8d0..41deb90 100644 --- a/xen/arch/x86/mm/hap/hap.c +++ b/xen/arch/x86/mm/hap/hap.c @@ -404,7 +404,7 @@ static mfn_t hap_make_monitor_table(struct vcpu *v) goto oom; m4mfn = page_to_mfn(pg); -l4e = __map_domain_page(pg); +l4e = map_domain_page(m4mfn); init_xen_l4_slots(l4e, m4mfn, d, INVALID_MFN, false); unmap_domain_page(l4e); diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index a242037..2fb1996 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -28,14 +28,16 @@ static int setup_compat_l4(struct vcpu *v) { struct page_info *pg; l4_pgentry_t *l4tab; +mfn_t mfn; pg = alloc_domheap_page(v->domain, MEMF_no_owner); if ( pg == NULL ) return -ENOMEM; -l4tab = __map_domain_page(pg); +mfn = page_to_mfn(pg); +l4tab = map_domain_page(mfn); clear_page(l4tab); -init_xen_l4_slots(l4tab, page_to_mfn(pg), v->domain, INVALID_MFN, false); +init_xen_l4_slots(l4tab, mfn, v->domain, INVALID_MFN, false); unmap_domain_page(l4tab); /* This page needs to look like a pagetable so that it can be shadowed */ ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 10/12] fuzz/x86_emulate: Add --rerun option to try to track down instability
>>> On 11.10.17 at 19:52, wrote: > @@ -884,20 +891,146 @@ int LLVMFuzzerInitialize(int *argc, char ***argv) > return 0; > } > > -int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t size) > +static void setup_fuzz_state(struct fuzz_state *state, const void *data_p, > size_t size) > { > -struct fuzz_state state = { > -.ops = all_fuzzer_ops, > -}; > -struct x86_emulate_ctxt ctxt = { > -.data = &state, > -.regs = &state.regs, > -.addr_size = 8 * sizeof(void *), > -.sp_size = 8 * sizeof(void *), > -}; > +memset(state, 0, sizeof(*state)); > +state->corpus = data_p; > +state->data_num = size; > +} > + > +static int runtest(struct fuzz_state *state) { > int rc; > > -if ( size <= fuzz_minimal_input_size() ) > +struct x86_emulate_ctxt *ctxt = &state->ctxt; Please don't leave a blank line between declarations. > +static void compare_states(struct fuzz_state state[2]) > +{ > +/* First zero any "internal" pointers */ > +state[0].corpus = state[1].corpus = NULL; > +state[0].ctxt.data = state[1].ctxt.data = NULL; > +state[0].ctxt.regs = state[1].ctxt.regs = NULL; > + > +if ( memcmp(&state[0], &state[1], sizeof(struct fuzz_state)) ) > +{ > +unsigned int i; > + > +printf("State mismatch\n"); > + > +for ( i = 0; i < ARRAY_SIZE(state[0].cr); i++ ) > +if ( state[0].cr[i] != state[1].cr[i] ) > +printf("cr[%u]: %lx != %lx\n", > + i, state[0].cr[i], state[1].cr[i]); > + > +for ( i = 0; i < ARRAY_SIZE(state[0].msr); i++ ) > +if ( state[0].msr[i] != state[1].msr[i] ) > +printf("msr[%u]: %lx != %lx\n", > + i, state[0].msr[i], state[1].msr[i]); > + > +for ( i = 0; i < ARRAY_SIZE(state[0].segments); i++ ) > +if ( memcmp(&state[0].segments[i], &state[1].segments[i], > +sizeof(state[0].segments[0])) ) > +printf("segments[%u]: [%x:%x:%x:%lx] != [%x:%x:%x:%lx]!\n", > i, > + (unsigned)state[0].segments[i].sel, > + (unsigned)state[0].segments[i].attr, > + state[0].segments[i].limit, > + state[0].segments[i].base, > + (unsigned)state[1].segments[i].sel, > + (unsigned)state[1].segments[i].attr, > + state[1].segments[i].limit, > + state[1].segments[i].base); > + > +if ( state[0].data_num != state[1].data_num ) > +printf("data_num: %lx != %lx\n", state[0].data_num, > + state[1].data_num); > +if ( state[0].data_index != state[1].data_index ) > +printf("data_index: %lx != %lx\n", state[0].data_index, > + state[1].data_index); > + > +if ( memcmp(&state[0].regs, &state[1].regs, sizeof(state[0].regs)) ) > +{ > +printf("registers differ!\n"); > +/* Print If Not Equal */ > +#define PRINT_NE(elem)\ > +if ( state[0].elem != state[1].elem ) \ > +printf(#elem " differ: %lx != %lx\n", \ > + (unsigned long)state[0].elem, \ > + (unsigned long)state[1].elem) > +PRINT_NE(regs.r15); > +PRINT_NE(regs.r14); > +PRINT_NE(regs.r13); > +PRINT_NE(regs.r12); > +PRINT_NE(regs.rbp); > +PRINT_NE(regs.rbx); > +PRINT_NE(regs.r10); > +PRINT_NE(regs.r11); > +PRINT_NE(regs.r9); > +PRINT_NE(regs.r8); > +PRINT_NE(regs.rax); > +PRINT_NE(regs.rcx); > +PRINT_NE(regs.rdx); > +PRINT_NE(regs.rsi); > +PRINT_NE(regs.rdi); Aren't these register fields all of the same type? If so, why do you need to casts to unsigned long in the macro? Additionally iirc Andrew had asked for eflags (and perhaps also selector register values) to be printed separately for ease of recognition - I support this request. > +for ( i = offsetof(struct cpu_user_regs, error_code) / > sizeof(unsigned); > + i < sizeof(state[1].regs)/sizeof(unsigned); i++ ) Blanks around binary operators please (also elsewhere). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 08/12] fuzz/x86_emulate: Move all state into fuzz_state
>>> On 11.10.17 at 19:52, wrote: > --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c > +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c > @@ -22,34 +22,31 @@ > > #define SEG_NUM x86_seg_none > > -/* Layout of data expected as fuzzing input. */ > -struct fuzz_corpus > +/* > + * State of the fuzzing harness and emulated cpu. Calculated > + * initially from the input corpus, and later mutated by the emulation > + * callbacks (and the emulator itself, in the case of regs). > + */ > +struct fuzz_state > { > +/* Emulated CPU state */ > +unsigned long options; > unsigned long cr[5]; > uint64_t msr[MSR_INDEX_MAX]; > -struct cpu_user_regs regs; > struct segment_register segments[SEG_NUM]; > -unsigned long options; > -unsigned char data[INPUT_SIZE]; > -} input; > -#define DATA_OFFSET offsetof(struct fuzz_corpus, data) > +struct cpu_user_regs regs; > > -/* > - * Internal state of the fuzzing harness. Calculated initially from the > input > - * corpus, and later mutates by the emulation callbacks. > - */ > -struct fuzz_state > -{ > /* Fuzzer's input data. */ > -struct fuzz_corpus *corpus; > +#define DATA_OFFSET offsetof(struct fuzz_state, corpus) > +const unsigned char * corpus; Stray blank after *. Also any reason this can't be uint8_t, matching LLVMFuzzerTestOneInput()'s parameter and making it possible to avoid the cast you currently use on that assignment? > @@ -646,11 +634,20 @@ static void set_sizes(struct x86_emulate_ctxt *ctxt) > ctxt->addr_size = ctxt->sp_size = 64; > else > { > -ctxt->addr_size = c->segments[x86_seg_cs].db ? 32 : 16; > -ctxt->sp_size = c->segments[x86_seg_ss].db ? 32 : 16; > +ctxt->addr_size = s->segments[x86_seg_cs].db ? 32 : 16; > +ctxt->sp_size = s->segments[x86_seg_ss].db ? 32 : 16; > } > } > > +static void setup_state(struct x86_emulate_ctxt *ctxt) > +{ > +struct fuzz_state *s = ctxt->data; > + > +/* Fuzz all of the emulated state in one go */ > +if (!input_read(s, s, DATA_OFFSET)) Missing blanks. > @@ -761,12 +757,11 @@ static void disable_hooks(struct x86_emulate_ctxt *ctxt) > static void sanitize_input(struct x86_emulate_ctxt *ctxt) > { > struct fuzz_state *s = ctxt->data; > -struct fuzz_corpus *c = s->corpus; > -struct cpu_user_regs *regs = &c->regs; > -unsigned long bitmap = c->options; > +struct cpu_user_regs *regs = ctxt->regs; > +unsigned long bitmap = s->options; > > /* Some hooks can't be disabled. */ > -c->options &= ~((1< +s->options &= ~((1< @@ -834,10 +826,10 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, > size_t size) > return 1; > } > > -memcpy(&input, data_p, size); > +state.corpus = (void*)data_p; If for any reason the suggested type change can't or shouldn't be done (and hence the cast needs to stay), then please add a blank before * and don't cast away const-ness. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 114342: regressions - trouble: blocked/broken/fail/pass
On Thu, Oct 12, 2017 at 02:24:23PM +, Ian Jackson wrote: > osstest service owner writes ("[osstest test] 114342: regressions - trouble: > blocked/broken/fail/pass"): > > flight 114342 osstest real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/114342/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > test-armhf-armhf-xl-vhd broken > > test-armhf-armhf-xl-vhd 4 host-install(4)broken REGR. vs. > > 114191 > > test-armhf-armhf-examine 4 host-install broken REGR. vs. > > 114191 > > test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. > > 114191 > > build-armhf-xsm 6 xen-buildfail REGR. vs. > > 114191 > > None of these are related to the only osstest patch under test, > > pvh: rename pvh tests to pvhv2 > > The armhf build failure looks like the armhf node crashing. > > I have therefore force pushed this: > > > version targeted for testing: > > osstest 2fe57c885d0290caf2d707893bb3bf3f5e8165f5 Thanks, hopefully this will unblock the branches stuck because of the pvh "regression". Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()
On Thu, Oct 12, 2017 at 02:54:22PM +0100, Andrew Cooper wrote: > There are currently three functions which write L4 pagetables for Xen, but > they all behave subtly differently. sh_install_xen_entries_in_l4() in > particular is catering for two different usecases, which makes the safety of > the linear mappings hard to follow. > > By consolidating the L4 pagetable writing in a single function, the resulting > setup of Xen's virtual layout is easier to understand. > > No practical changes to the resulting L4, although the logic has been > rearranged to avoid rewriting some slots. This changes the zap_ro_mpt > parameter to simply ro_mpt. > > Both {hap,sh}_install_xen_entries_in_l4() get folded into their callers. The > hap side only a single caller, while the shadow side has two. The shadow > split helps highlight the correctness of the linear slots. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()
>>> On 12.10.17 at 15:54, wrote: > --- a/xen/arch/x86/mm/hap/hap.c > +++ b/xen/arch/x86/mm/hap/hap.c > @@ -391,41 +391,24 @@ int hap_set_allocation(struct domain *d, unsigned int > pages, bool *preempted) > return 0; > } > > -static void hap_install_xen_entries_in_l4(struct vcpu *v, mfn_t l4mfn) > -{ > -struct domain *d = v->domain; > -l4_pgentry_t *l4e; > - > -l4e = map_domain_page(l4mfn); > - > -/* Copy the common Xen mappings from the idle domain */ > -memcpy(&l4e[ROOT_PAGETABLE_FIRST_XEN_SLOT], > - &idle_pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT], > - ROOT_PAGETABLE_XEN_SLOTS * sizeof(l4_pgentry_t)); > - > -/* Install the per-domain mappings for this domain */ > -l4e[l4_table_offset(PERDOMAIN_VIRT_START)] = > -l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW); > - > -/* Install a linear mapping */ > -l4e[l4_table_offset(LINEAR_PT_VIRT_START)] = > -l4e_from_mfn(l4mfn, __PAGE_HYPERVISOR_RW); > - > -unmap_domain_page(l4e); > -} > - > static mfn_t hap_make_monitor_table(struct vcpu *v) > { > struct domain *d = v->domain; > struct page_info *pg; > +l4_pgentry_t *l4e; > mfn_t m4mfn; > > ASSERT(pagetable_get_pfn(v->arch.monitor_table) == 0); > > if ( (pg = hap_alloc(d)) == NULL ) > goto oom; > + > m4mfn = page_to_mfn(pg); > -hap_install_xen_entries_in_l4(v, m4mfn); > +l4e = __map_domain_page(pg); If you obtain the MFN anyway, map_domain_page() is cheaper generated code wise. > --- a/xen/arch/x86/pv/domain.c > +++ b/xen/arch/x86/pv/domain.c > @@ -35,7 +35,7 @@ static int setup_compat_l4(struct vcpu *v) > > l4tab = __map_domain_page(pg); > clear_page(l4tab); > -init_guest_l4_table(l4tab, v->domain, 1); > +init_xen_l4_slots(l4tab, page_to_mfn(pg), v->domain, INVALID_MFN, false); Perhaps worth avoiding the double translation here too. In any event Reviewed-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] x86/mm: Consolidate all Xen L2 slot writing into init_xen_pae_l2_slots()
On Thu, Oct 12, 2017 at 02:54:21PM +0100, Andrew Cooper wrote: > Having all of this logic together makes it easier to follow Xen's virtual > setup across the whole system. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] x86/mm: Consolidate all Xen L2 slot writing into init_xen_pae_l2_slots()
>>> On 12.10.17 at 15:54, wrote: > Having all of this logic together makes it easier to follow Xen's virtual > setup across the whole system. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] Revert "x86/mm: move PV l4 table setup code" and "x86/mm: factor out pv_arch_init_memory"
>>> On 12.10.17 at 15:54, wrote: > This reverts commit f3b95fd07fdb55b1db091fede1b9a7c71f1eaa1b and > 1bd39738a5a34f529a610fb275cc83ee5ac7547a. > > The following patches (post XSA-243 fixes) requires init_guest_l4_table() > being common code. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 3/6] Introduce _xrealloc
On Thu, Oct 12, 2017 at 02:33:04PM +0100, Julien Grall wrote: > Hi, > > Bringing back this discussion. > > On 28/08/17 22:39, Goel, Sameer wrote: > > > > > > On 6/9/2017 3:44 AM, Wei Liu wrote: > > > On Thu, Jun 08, 2017 at 08:49:01PM +0100, Julien Grall wrote: > > > > CC the REST maintainers > > > > > > > > On 08/06/2017 20:30, Sameer Goel wrote: > > > > > Introduce a memory realloc function. > > > > > > > > > > Signed-off-by: Sameer Goel > > > > > --- > > > > > xen/common/xmalloc_tlsf.c | 13 + > > > > > xen/include/xen/xmalloc.h | 1 + > > > > > 2 files changed, 14 insertions(+) > > > > > > > > > > diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c > > > > > index b256dc5..52385a8 100644 > > > > > --- a/xen/common/xmalloc_tlsf.c > > > > > +++ b/xen/common/xmalloc_tlsf.c > > > > > @@ -612,6 +612,19 @@ void *_xzalloc(unsigned long size, unsigned long > > > > > align) > > > > > return p ? memset(p, 0, size) : p; > > > > > } > > > > > > > > > > +void *_xrealloc(void *p, unsigned long new_size, unsigned long align) > > > > > +{ > > > > > +void *new_p = _xmalloc(new_size, align); > > > > > + > > > > > +if(new_p && p) > > > > > > > > Coding style: if ( ... ) > > > > > > > > > +{ > > > > > +memcpy(new_p, p, new_size); > > > > > > This is wrong. How can you know if the area pointed to by p is at least > > > new_size bytes long? > > > > > Agreed, I revisited the code and will remove _xrealloc and use xfree and > > _xmalloc instead. > > I am not sure why you choose to drop it completely. xfree is able to know > the size of the buffer to free. > > So you could find out the size and copy the right amount of data. > > Note that having _xrealloc would be my preference over an open-coded version > in the code. I would vouch for a properly implemented _xrealloc. :-) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] Revert "x86/mm: move PV l4 table setup code" and "x86/mm: factor out pv_arch_init_memory"
On Thu, Oct 12, 2017 at 02:54:20PM +0100, Andrew Cooper wrote: > This reverts commit f3b95fd07fdb55b1db091fede1b9a7c71f1eaa1b and > 1bd39738a5a34f529a610fb275cc83ee5ac7547a. > > The following patches (post XSA-243 fixes) requires init_guest_l4_table() > being common code. > > Signed-off-by: Andrew Cooper Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 0/5] Towards work-conserving RTDS
On Thu, Oct 12, 2017 at 5:02 AM, Wei Liu wrote: > > FYI all patches except the xentrace one were committed yesterday. Thank you very much, Wei! Best, Meng -- Meng Xu Ph.D. Candidate in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 114342: regressions - trouble: blocked/broken/fail/pass
osstest service owner writes ("[osstest test] 114342: regressions - trouble: blocked/broken/fail/pass"): > flight 114342 osstest real [real] > http://logs.test-lab.xenproject.org/osstest/logs/114342/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-armhf-armhf-xl-vhd broken > test-armhf-armhf-xl-vhd 4 host-install(4)broken REGR. vs. > 114191 > test-armhf-armhf-examine 4 host-install broken REGR. vs. > 114191 > test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. > 114191 > build-armhf-xsm 6 xen-buildfail REGR. vs. > 114191 None of these are related to the only osstest patch under test, pvh: rename pvh tests to pvhv2 The armhf build failure looks like the armhf node crashing. I have therefore force pushed this: > version targeted for testing: > osstest 2fe57c885d0290caf2d707893bb3bf3f5e8165f5 Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v2 5/7] acpi:arm64: Add support for parsing IORT table
Hi Sameer, On 21/09/17 01:37, Sameer Goel wrote: @@ -583,14 +631,13 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev) u32 streamid = 0; if (dev_is_pci(dev)) { - struct pci_bus *bus = to_pci_dev(dev)->bus; + struct pci_dev *pci_device = to_pci_dev(dev); u32 rid; - pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, - &rid); + rid = PCI_BDF2(pci_device->bus, pci_device->devfn); I forgot to answer on this bit. On the previous it was mentioned this was wrong, but still there. Whilst I can understand that implementing pci_for_each_dma_alias could require some work in Xen, I don't want to see rid = PCI_BDF2(...) spreading the code. So what's the plan? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v2 5/7] acpi:arm64: Add support for parsing IORT table
Hi Sameer, On 21/09/17 01:37, Sameer Goel wrote: Add support for parsing IORT table to initialize SMMU devices. * The code for creating an SMMU device has been modified, so that the SMMU device can be initialized. * The NAMED NODE code has been commented out as this will need DOM0 kernel support. * ITS code has been included but it has not been tested. Signed-off-by: Sameer Goel --- xen/arch/arm/setup.c | 3 + xen/drivers/acpi/Makefile | 1 + xen/drivers/acpi/arm/Makefile | 1 + xen/drivers/acpi/arm/iort.c| 173 + xen/drivers/passthrough/arm/smmu.c | 1 + xen/include/acpi/acpi_iort.h | 17 ++-- xen/include/asm-arm/device.h | 2 + xen/include/xen/acpi.h | 21 + xen/include/xen/pci.h | 8 ++ 9 files changed, 146 insertions(+), 81 deletions(-) create mode 100644 xen/drivers/acpi/arm/Makefile diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 92f173b..4ba09b2 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -49,6 +49,7 @@ #include #include #include +#include struct bootinfo __initdata bootinfo; @@ -796,6 +797,8 @@ void __init start_xen(unsigned long boot_phys_offset, tasklet_subsys_init(); +/* Parse the ACPI iort data */ +acpi_iort_init(); xsm_dt_init(); diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile index 444b11d..e7ffd82 100644 --- a/xen/drivers/acpi/Makefile +++ b/xen/drivers/acpi/Makefile @@ -1,5 +1,6 @@ subdir-y += tables subdir-y += utilities +subdir-$(CONFIG_ARM) += arm subdir-$(CONFIG_X86) += apei obj-bin-y += tables.init.o diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile new file mode 100644 index 000..7c039bb --- /dev/null +++ b/xen/drivers/acpi/arm/Makefile @@ -0,0 +1 @@ +obj-y += iort.o diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c index 2e368a6..7f54062 100644 --- a/xen/drivers/acpi/arm/iort.c +++ b/xen/drivers/acpi/arm/iort.c @@ -14,17 +14,47 @@ * This file implements early detection/parsing of I/O mapping * reported to OS through firmware via I/O Remapping Table (IORT) * IORT document number: ARM DEN 0049A + * + * Based on Linux drivers/acpi/arm64/iort.c + * => commit ca78d3173cff3503bcd15723b049757f75762d15 + * + * Xen modification: + * Sameer Goel + * Copyright (C) 2017, The Linux Foundation, All rights reserved. + * */ -#define pr_fmt(fmt) "ACPI: IORT: " fmt - -#include -#include -#include -#include -#include -#include -#include +#include +#include Why do you need to include there? Can't this be done after all the ? +#include +#include +#include +#include +#include + +#include + +/* Xen: Define compatibility functions */ +#define FW_BUG "[Firmware Bug]: " +#define pr_err(fmt, ...) printk(XENLOG_ERR fmt, ## __VA_ARGS__) +#define pr_warn(fmt, ...) printk(XENLOG_WARNING fmt, ## __VA_ARGS__) + +/* Alias to Xen allocation helpers */ +#define kfree xfree +#define kmalloc(size, flags)_xmalloc(size, sizeof(void *)) +#define kzalloc(size, flags)_xzalloc(size, sizeof(void *)) Likely you would need the same macros in the SMMUv3 driver. Could we think of a common headers implementing the Linux compat layer? + +/* Redefine WARN macros */ +#undef WARN +#undef WARN_ON +#define WARN(condition, format...) ({ \ + int __ret_warn_on = !!(condition); \ + if (unlikely(__ret_warn_on))\ + printk(format); \ + unlikely(__ret_warn_on);\ +}) Again, you should at least try to modify the common code version before deciding to redefine it here. +#define WARN_TAINT(cond, taint, format...) WARN(cond, format) +#define WARN_ON(cond) (!!cond) #define IORT_TYPE_MASK(type) (1 << (type)) #define IORT_MSI_TYPE (1 << ACPI_IORT_NODE_ITS_GROUP) @@ -256,6 +286,13 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node, acpi_status status; if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) { + status = AE_NOT_IMPLEMENTED; +/* + * We need the namespace object name from dsdt to match the iort node, this Please add a "Xen: TODO:" in front. + * will need additions to the kernel xen bus notifiers. + * So, disabling the named node code till a proposal is approved. + */ +#if 0 struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL }; struct acpi_device *adev = to_acpi_device_node(dev->fwnode); struct acpi_iort_named_component *ncomp; @@ -275,11 +312,12 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node, status = !strcmp(ncomp->device_name, buf.pointer) ?
[Xen-devel] [PATCH 3/3] x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots()
There are currently three functions which write L4 pagetables for Xen, but they all behave subtly differently. sh_install_xen_entries_in_l4() in particular is catering for two different usecases, which makes the safety of the linear mappings hard to follow. By consolidating the L4 pagetable writing in a single function, the resulting setup of Xen's virtual layout is easier to understand. No practical changes to the resulting L4, although the logic has been rearranged to avoid rewriting some slots. This changes the zap_ro_mpt parameter to simply ro_mpt. Both {hap,sh}_install_xen_entries_in_l4() get folded into their callers. The hap side only a single caller, while the shadow side has two. The shadow split helps highlight the correctness of the linear slots. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Tim Deegan CC: George Dunlap CC: Wei Liu CC: Julien Grall --- xen/arch/x86/mm.c | 87 + xen/arch/x86/mm/hap/hap.c | 31 +++- xen/arch/x86/mm/shadow/multi.c | 106 ++--- xen/arch/x86/pv/dom0_build.c | 3 +- xen/arch/x86/pv/domain.c | 2 +- xen/include/asm-x86/mm.h | 4 +- 6 files changed, 105 insertions(+), 128 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index ea4af16..5097958 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1521,37 +1521,85 @@ void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d) } /* + * Fill an L4 with Xen entries. + * * This function must write all ROOT_PAGETABLE_PV_XEN_SLOTS, to clobber any * values a guest may have left there from alloc_l4_table(). + * + * l4t and l4mfn are mandatory, but l4mfn doesn't need to be the mfn under + * *l4t. All other parameters are optional and will either fill or zero the + * appropriate slots. Pagetables not shared with guests will gain the + * extended directmap. */ -void init_guest_l4_table(l4_pgentry_t l4tab[], const struct domain *d, - bool zap_ro_mpt) +void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn, + const struct domain *d, mfn_t sl4mfn, bool ro_mpt) { -/* Xen private mappings. */ -memcpy(&l4tab[ROOT_PAGETABLE_FIRST_XEN_SLOT], - &idle_pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT], - root_pgt_pv_xen_slots * sizeof(l4_pgentry_t)); +/* + * PV vcpus need a shortened directmap. HVM and Idle vcpus get the full + * directmap. + */ +bool short_directmap = d && !paging_mode_external(d); + +/* Slot 256: RO M2P (if applicable). */ +l4t[l4_table_offset(RO_MPT_VIRT_START)] = +ro_mpt ? idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)] + : l4e_empty(); + +/* Slot 257: PCI MMCFG. */ +l4t[l4_table_offset(PCI_MCFG_VIRT_START)] = +idle_pg_table[l4_table_offset(PCI_MCFG_VIRT_START)]; + +/* Slot 258: Self linear mappings. */ +ASSERT(!mfn_eq(l4mfn, INVALID_MFN)); +l4t[l4_table_offset(LINEAR_PT_VIRT_START)] = +l4e_from_mfn(l4mfn, __PAGE_HYPERVISOR_RW); + +/* Slot 259: Shadow linear mappings (if applicable) .*/ +l4t[l4_table_offset(SH_LINEAR_PT_VIRT_START)] = +mfn_eq(sl4mfn, INVALID_MFN) ? l4e_empty() : +l4e_from_mfn(sl4mfn, __PAGE_HYPERVISOR_RW); + +/* Slot 260: Per-domain mappings (if applicable). */ +l4t[l4_table_offset(PERDOMAIN_VIRT_START)] = +d ? l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW) + : l4e_empty(); + +/* Slot 261-: text/data/bss, RW M2P, vmap, frametable, directmap. */ #ifndef NDEBUG -if ( unlikely(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS) ) +if ( short_directmap && + unlikely(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS) ) { -l4_pgentry_t *next = &l4tab[ROOT_PAGETABLE_FIRST_XEN_SLOT + -root_pgt_pv_xen_slots]; +/* + * If using highmem-start=, artificially shorten the directmap to + * simulate very large machines. + */ +l4_pgentry_t *next; + +memcpy(&l4t[l4_table_offset(XEN_VIRT_START)], + &idle_pg_table[l4_table_offset(XEN_VIRT_START)], + (ROOT_PAGETABLE_FIRST_XEN_SLOT + root_pgt_pv_xen_slots - +l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t)); + +next = &l4t[ROOT_PAGETABLE_FIRST_XEN_SLOT + root_pgt_pv_xen_slots]; if ( l4e_get_intpte(split_l4e) ) *next++ = split_l4e; memset(next, 0, - _p(&l4tab[ROOT_PAGETABLE_LAST_XEN_SLOT + 1]) - _p(next)); + _p(&l4t[ROOT_PAGETABLE_LAST_XEN_SLOT + 1]) - _p(next)); } -#else -BUILD_BUG_ON(root_pgt_pv_xen_slots != ROOT_PAGETABLE_PV_XEN_SLOTS); +else #endif -l4tab[l4_table_offset(LINEAR_PT_VIRT_START)] = -l4e_from_pfn(domain_page_map_to_mfn(l4tab), __PAGE_HYPERVISOR_RW); -l4tab[l4_table_offset(PERDOMAIN_VIRT_START)] = -l4e_fro
[Xen-devel] [PATCH 1/3] Revert "x86/mm: move PV l4 table setup code" and "x86/mm: factor out pv_arch_init_memory"
This reverts commit f3b95fd07fdb55b1db091fede1b9a7c71f1eaa1b and 1bd39738a5a34f529a610fb275cc83ee5ac7547a. The following patches (post XSA-243 fixes) requires init_guest_l4_table() being common code. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Julien Grall These pagetable fixes have been pending for longer than the mm cleanup being reverted here. Had I been in the office when these patches were proposed, I would have quietly arranged for them not to be committed. --- xen/arch/x86/mm.c| 77 +++-- xen/arch/x86/pv/dom0_build.c | 2 -- xen/arch/x86/pv/domain.c | 5 --- xen/arch/x86/pv/mm.c | 82 xen/arch/x86/pv/mm.h | 3 -- xen/include/asm-x86/mm.h | 2 ++ xen/include/asm-x86/pv/mm.h | 4 --- 7 files changed, 77 insertions(+), 98 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 5628bc7..f90a42a 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -125,7 +125,6 @@ #include #include -#include #include "pv/mm.h" @@ -243,6 +242,14 @@ void __init init_frametable(void) memset(end_pg, -1, (unsigned long)top_pg - (unsigned long)end_pg); } +#ifndef NDEBUG +static unsigned int __read_mostly root_pgt_pv_xen_slots += ROOT_PAGETABLE_PV_XEN_SLOTS; +static l4_pgentry_t __read_mostly split_l4e; +#else +#define root_pgt_pv_xen_slots ROOT_PAGETABLE_PV_XEN_SLOTS +#endif + void __init arch_init_memory(void) { unsigned long i, pfn, rstart_pfn, rend_pfn, iostart_pfn, ioend_pfn; @@ -338,7 +345,39 @@ void __init arch_init_memory(void) mem_sharing_init(); -pv_arch_init_memory(); +#ifndef NDEBUG +if ( highmem_start ) +{ +unsigned long split_va = (unsigned long)__va(highmem_start); + +if ( split_va < HYPERVISOR_VIRT_END && + split_va - 1 == (unsigned long)__va(highmem_start - 1) ) +{ +root_pgt_pv_xen_slots = l4_table_offset(split_va) - +ROOT_PAGETABLE_FIRST_XEN_SLOT; +ASSERT(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS); +if ( l4_table_offset(split_va) == l4_table_offset(split_va - 1) ) +{ +l3_pgentry_t *l3tab = alloc_xen_pagetable(); + +if ( l3tab ) +{ +const l3_pgentry_t *l3idle = +l4e_to_l3e(idle_pg_table[l4_table_offset(split_va)]); + +for ( i = 0; i < l3_table_offset(split_va); ++i ) +l3tab[i] = l3idle[i]; +for ( ; i < L3_PAGETABLE_ENTRIES; ++i ) +l3tab[i] = l3e_empty(); +split_l4e = l4e_from_pfn(virt_to_mfn(l3tab), + __PAGE_HYPERVISOR_RW); +} +else +++root_pgt_pv_xen_slots; +} +} +} +#endif } int page_is_ram_type(unsigned long mfn, unsigned long mem_type) @@ -1479,6 +1518,40 @@ static int alloc_l3_table(struct page_info *page) return rc > 0 ? 0 : rc; } +/* + * This function must write all ROOT_PAGETABLE_PV_XEN_SLOTS, to clobber any + * values a guest may have left there from alloc_l4_table(). + */ +void init_guest_l4_table(l4_pgentry_t l4tab[], const struct domain *d, + bool zap_ro_mpt) +{ +/* Xen private mappings. */ +memcpy(&l4tab[ROOT_PAGETABLE_FIRST_XEN_SLOT], + &idle_pg_table[ROOT_PAGETABLE_FIRST_XEN_SLOT], + root_pgt_pv_xen_slots * sizeof(l4_pgentry_t)); +#ifndef NDEBUG +if ( unlikely(root_pgt_pv_xen_slots < ROOT_PAGETABLE_PV_XEN_SLOTS) ) +{ +l4_pgentry_t *next = &l4tab[ROOT_PAGETABLE_FIRST_XEN_SLOT + +root_pgt_pv_xen_slots]; + +if ( l4e_get_intpte(split_l4e) ) +*next++ = split_l4e; + +memset(next, 0, + _p(&l4tab[ROOT_PAGETABLE_LAST_XEN_SLOT + 1]) - _p(next)); +} +#else +BUILD_BUG_ON(root_pgt_pv_xen_slots != ROOT_PAGETABLE_PV_XEN_SLOTS); +#endif +l4tab[l4_table_offset(LINEAR_PT_VIRT_START)] = +l4e_from_pfn(domain_page_map_to_mfn(l4tab), __PAGE_HYPERVISOR_RW); +l4tab[l4_table_offset(PERDOMAIN_VIRT_START)] = +l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW); +if ( zap_ro_mpt || is_pv_32bit_domain(d) ) +l4tab[l4_table_offset(RO_MPT_VIRT_START)] = l4e_empty(); +} + bool fill_ro_mpt(mfn_t mfn) { l4_pgentry_t *l4tab = map_domain_page(mfn); diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c index dcbee43..ec7f96d 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -20,8 +20,6 @@ #include #include -#include "mm.h" - /* Allow ring-3 access in long mode as guest cannot use ring 1 ... */ #define BASE_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED|_PAGE_USER) #define L1_PROT (BASE_PROT|_PAGE_GUEST_K
[Xen-devel] [PATCH for 4.10 0/3] XSA-243 followup
The important change here is in patch 3, which is intended to remove the correct-but-dangerous-looking construction of linear pagetables slots for shadowed guests. Andrew Cooper (3): Revert "x86/mm: move PV l4 table setup code" and "x86/mm: factor out pv_arch_init_memory" x86/mm: Consolidate all Xen L2 slot writing into init_xen_pae_l2_slots() x86/mm: Consolidate all Xen L4 slot writing into init_xen_l4_slots() xen/arch/x86/mm.c | 144 --- xen/arch/x86/mm/hap/hap.c | 31 ++--- xen/arch/x86/mm/shadow/multi.c | 148 +++-- xen/arch/x86/pv/dom0_build.c | 5 +- xen/arch/x86/pv/domain.c | 7 +- xen/arch/x86/pv/mm.c | 82 --- xen/arch/x86/pv/mm.h | 3 - xen/include/asm-x86/mm.h | 3 + xen/include/asm-x86/pv/mm.h| 4 -- 9 files changed, 187 insertions(+), 240 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/3] x86/mm: Consolidate all Xen L2 slot writing into init_xen_pae_l2_slots()
Having all of this logic together makes it easier to follow Xen's virtual setup across the whole system. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Tim Deegan CC: George Dunlap CC: Wei Liu CC: Julien Grall --- xen/arch/x86/mm.c | 16 +--- xen/arch/x86/mm/shadow/multi.c | 42 +++--- xen/include/asm-x86/mm.h | 1 + 3 files changed, 25 insertions(+), 34 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index f90a42a..ea4af16 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1433,13 +1433,7 @@ static int alloc_l2_table(struct page_info *page, unsigned long type, } if ( rc >= 0 && (type & PGT_pae_xen_l2) ) -{ -/* Xen private mappings. */ -memcpy(&pl2e[COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(d)], - &compat_idle_pg_table_l2[ - l2_table_offset(HIRO_COMPAT_MPT_VIRT_START)], - COMPAT_L2_PAGETABLE_XEN_SLOTS(d) * sizeof(*pl2e)); -} +init_xen_pae_l2_slots(pl2e, d); unmap_domain_page(pl2e); return rc > 0 ? 0 : rc; @@ -1518,6 +1512,14 @@ static int alloc_l3_table(struct page_info *page) return rc > 0 ? 0 : rc; } +void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d) +{ +memcpy(&l2t[COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(d)], + &compat_idle_pg_table_l2[ + l2_table_offset(HIRO_COMPAT_MPT_VIRT_START)], + COMPAT_L2_PAGETABLE_XEN_SLOTS(d) * sizeof(*l2t)); +} + /* * This function must write all ROOT_PAGETABLE_PV_XEN_SLOTS, to clobber any * values a guest may have left there from alloc_l4_table(). diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c index d540af1..1b76e0c 100644 --- a/xen/arch/x86/mm/shadow/multi.c +++ b/xen/arch/x86/mm/shadow/multi.c @@ -1521,31 +1521,6 @@ void sh_install_xen_entries_in_l4(struct domain *d, mfn_t gl4mfn, mfn_t sl4mfn) } #endif -#if GUEST_PAGING_LEVELS >= 3 -// For 3-on-3 PV guests, we need to make sure the xen mappings are in -// place, which means that we need to populate the l2h entry in the l3 -// table. - -static void sh_install_xen_entries_in_l2h(struct domain *d, mfn_t sl2hmfn) -{ -shadow_l2e_t *sl2e; - -if ( !is_pv_32bit_domain(d) ) -return; - -sl2e = map_domain_page(sl2hmfn); -BUILD_BUG_ON(sizeof (l2_pgentry_t) != sizeof (shadow_l2e_t)); - -/* Copy the common Xen mappings from the idle domain */ -memcpy( -&sl2e[COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(d)], -&compat_idle_pg_table_l2[l2_table_offset(HIRO_COMPAT_MPT_VIRT_START)], -COMPAT_L2_PAGETABLE_XEN_SLOTS(d) * sizeof(*sl2e)); - -unmap_domain_page(sl2e); -} -#endif - /**/ /* Create a shadow of a given guest page. @@ -1610,7 +1585,14 @@ sh_make_shadow(struct vcpu *v, mfn_t gmfn, u32 shadow_type) #endif #if GUEST_PAGING_LEVELS >= 3 case SH_type_l2h_shadow: -sh_install_xen_entries_in_l2h(v->domain, smfn); +BUILD_BUG_ON(sizeof(l2_pgentry_t) != sizeof(shadow_l2e_t)); +if ( is_pv_32bit_domain(d) ) +{ +shadow_l2e_t *l2t = map_domain_page(smfn); + +init_xen_pae_l2_slots(l2t, d); +unmap_domain_page(l2t); +} break; #endif default: /* Do nothing */ break; @@ -1677,6 +1659,8 @@ sh_make_monitor_table(struct vcpu *v) if ( is_pv_32bit_domain(d) ) { +l2_pgentry_t *l2t; + /* For 32-bit PV guests, we need to map the 32-bit Xen * area into its usual VAs in the monitor tables */ m3mfn = shadow_alloc(d, SH_type_monitor_table, 0); @@ -1687,7 +1671,11 @@ sh_make_monitor_table(struct vcpu *v) mfn_to_page(m2mfn)->shadow_flags = 2; l3e = map_domain_page(m3mfn); l3e[3] = l3e_from_mfn(m2mfn, _PAGE_PRESENT); -sh_install_xen_entries_in_l2h(d, m2mfn); + +l2t = map_domain_page(m2mfn); +init_xen_pae_l2_slots(l2t, d); +unmap_domain_page(l2t); + unmap_domain_page(l3e); } diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h index eeac4d7..da3c5e2 100644 --- a/xen/include/asm-x86/mm.h +++ b/xen/include/asm-x86/mm.h @@ -340,6 +340,7 @@ static inline void *__page_to_virt(const struct page_info *pg) int free_page_type(struct page_info *page, unsigned long type, int preemptible); +void init_xen_pae_l2_slots(l2_pgentry_t *l2t, const struct domain *d); void init_guest_l4_table(l4_pgentry_t[], const struct domain *, bool_t zap_ro_mpt); bool fill_ro_mpt(mfn_t mfn); -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/x
[Xen-devel] [xen-unstable-smoke test] 114418: regressions - FAIL
flight 114418 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/114418/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 114299 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen c4e365a0eb3cb6c9dedfaf0c13b0a2ce62f49cf6 baseline version: xen 3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a Last test of basis 114299 2017-10-10 21:02:54 Z1 days Failing since114308 2017-10-10 23:01:10 Z1 days 15 attempts Testing same since 114376 2017-10-11 23:01:15 Z0 days6 attempts People who touched revisions under test: Alexandru Isaila Andre Przywara Andrew Cooper Boris Ostrovsky George Dunlap Ian Jackson Jan Beulich Julien Grall Julien Grall Konrad Rzeszutek Wilk Meng Xu Ross Lagerwall Stefano Stabellini Volodymyr Babchuk Wei Liu Yi Sun jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt 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 1175 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v2 3/7] xen/passthrough/arm: Introduce iommu_fwspec
Hi, On 12/10/17 14:05, Julien Grall wrote: Hi, On 21/09/17 01:37, Sameer Goel wrote: Introduce a common structure to hold the fw (ACPI or DT) defined configuration for SMMU hw. The current use case is for arm SMMUs. So, making this architecture specific. Based on Linux kernel commit 57f98d2f61e1: iommu: Introduce iommu_fwspec Signed-off-by: Sameer Goel --- xen/drivers/passthrough/arm/iommu.c | 66 + xen/include/asm-arm/device.h | 1 + xen/include/xen/iommu.h | 29 3 files changed, 96 insertions(+) diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/arm/iommu.c index 95b1abb..41c6497 100644 --- a/xen/drivers/passthrough/arm/iommu.c +++ b/xen/drivers/passthrough/arm/iommu.c @@ -73,3 +73,69 @@ int arch_iommu_populate_page_table(struct domain *d) /* The IOMMU shares the p2m with the CPU */ return -ENOSYS; } + +const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode) +{ + return iommu_get_ops(); Can you please add a comment explain why you always return iommu_get_ops()? Would it be possible that the device is not behind an IOMMU? +} + +int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode, + const struct iommu_ops *ops) +{ + struct iommu_fwspec *fwspec = dev->iommu_fwspec; + + if ( fwspec ) + return ops == fwspec->ops ? 0 : -EINVAL; + + fwspec = _xzalloc(sizeof(struct iommu_fwspec), sizeof(void *)); On the previous version this was xzalloc(struct iommu_fwspec), why? I also don't understand the align on sizeof(void *). + if ( !fwspec ) + return -ENOMEM; + + fwspec->iommu_fwnode = iommu_fwnode; + fwspec->ops = ops; + dev->iommu_fwspec = fwspec; + + return 0; +} + +void iommu_fwspec_free(struct device *dev) +{ + struct iommu_fwspec *fwspec = dev->iommu_fwspec; + + if ( fwspec ) + { Linux is dropping the reference on the iommu_fwnode. Are we never expecting to take reference on the it in Xen? + xfree(fwspec); + dev->iommu_fwspec = NULL; + } +} + +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids) +{ + struct iommu_fwspec *fwspec = dev->iommu_fwspec; + struct iommu_fwspec *fwspec_n = NULL; + size_t size, size_n; + int i; + + if ( !fwspec ) + return -EINVAL; + + size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids]); + size_n = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]); + if ( size_n > size ) + { > + fwspec_n = _xzalloc(size_n, sizeof(void *)); Same question about _xzalloc() here. Also, please see the comment I just made on "[RFC 3/6] Introduce _xrealloc". I would prefer to explore the possibility of a generic helper rather than open-coding it. I think we have enough information in hand to get the size of the old region. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 3/6] Introduce _xrealloc
Hi, Bringing back this discussion. On 28/08/17 22:39, Goel, Sameer wrote: On 6/9/2017 3:44 AM, Wei Liu wrote: On Thu, Jun 08, 2017 at 08:49:01PM +0100, Julien Grall wrote: CC the REST maintainers On 08/06/2017 20:30, Sameer Goel wrote: Introduce a memory realloc function. Signed-off-by: Sameer Goel --- xen/common/xmalloc_tlsf.c | 13 + xen/include/xen/xmalloc.h | 1 + 2 files changed, 14 insertions(+) diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c index b256dc5..52385a8 100644 --- a/xen/common/xmalloc_tlsf.c +++ b/xen/common/xmalloc_tlsf.c @@ -612,6 +612,19 @@ void *_xzalloc(unsigned long size, unsigned long align) return p ? memset(p, 0, size) : p; } +void *_xrealloc(void *p, unsigned long new_size, unsigned long align) +{ +void *new_p = _xmalloc(new_size, align); + +if(new_p && p) Coding style: if ( ... ) +{ +memcpy(new_p, p, new_size); This is wrong. How can you know if the area pointed to by p is at least new_size bytes long? Agreed, I revisited the code and will remove _xrealloc and use xfree and _xmalloc instead. I am not sure why you choose to drop it completely. xfree is able to know the size of the buffer to free. So you could find out the size and copy the right amount of data. Note that having _xrealloc would be my preference over an open-coded version in the code. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v2 3/7] xen/passthrough/arm: Introduce iommu_fwspec
Hi, On 21/09/17 01:37, Sameer Goel wrote: Introduce a common structure to hold the fw (ACPI or DT) defined configuration for SMMU hw. The current use case is for arm SMMUs. So, making this architecture specific. Based on Linux kernel commit 57f98d2f61e1: iommu: Introduce iommu_fwspec Signed-off-by: Sameer Goel --- xen/drivers/passthrough/arm/iommu.c | 66 + xen/include/asm-arm/device.h| 1 + xen/include/xen/iommu.h | 29 3 files changed, 96 insertions(+) diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/arm/iommu.c index 95b1abb..41c6497 100644 --- a/xen/drivers/passthrough/arm/iommu.c +++ b/xen/drivers/passthrough/arm/iommu.c @@ -73,3 +73,69 @@ int arch_iommu_populate_page_table(struct domain *d) /* The IOMMU shares the p2m with the CPU */ return -ENOSYS; } + +const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode) +{ +return iommu_get_ops(); Can you please add a comment explain why you always return iommu_get_ops()? Would it be possible that the device is not behind an IOMMU? +} + +int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode, +const struct iommu_ops *ops) +{ +struct iommu_fwspec *fwspec = dev->iommu_fwspec; + +if ( fwspec ) +return ops == fwspec->ops ? 0 : -EINVAL; + +fwspec = _xzalloc(sizeof(struct iommu_fwspec), sizeof(void *)); On the previous version this was xzalloc(struct iommu_fwspec), why? I also don't understand the align on sizeof(void *). +if ( !fwspec ) +return -ENOMEM; + +fwspec->iommu_fwnode = iommu_fwnode; +fwspec->ops = ops; +dev->iommu_fwspec = fwspec; + +return 0; +} + +void iommu_fwspec_free(struct device *dev) +{ +struct iommu_fwspec *fwspec = dev->iommu_fwspec; + +if ( fwspec ) +{ Linux is dropping the reference on the iommu_fwnode. Are we never expecting to take reference on the it in Xen? +xfree(fwspec); +dev->iommu_fwspec = NULL; +} +} + +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids) +{ +struct iommu_fwspec *fwspec = dev->iommu_fwspec; +struct iommu_fwspec *fwspec_n = NULL; +size_t size, size_n; +int i; + +if ( !fwspec ) +return -EINVAL; + +size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids]); +size_n = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]); +if ( size_n > size ) +{ > +fwspec_n = _xzalloc(size_n, sizeof(void *)); Same question about _xzalloc() here. +if ( !fwspec_n ) +return -ENOMEM; + +memcpy(fwspec_n, fwspec, size); +xfree(fwspec); +} + +for (i = 0; i < num_ids; i++) +fwspec_n->ids[fwspec_n->num_ids + i] = ids[i]; + +fwspec_n->num_ids += num_ids; +dev->iommu_fwspec = fwspec_n; + +return 0; +} diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h index 78c38fe..5027c87 100644 --- a/xen/include/asm-arm/device.h +++ b/xen/include/asm-arm/device.h @@ -21,6 +21,7 @@ struct device struct dt_device_node *of_node; /* Used by drivers imported from Linux */ #endif struct fwnode_handle *fwnode; /*fw device node identifier */ +struct iommu_fwspec *iommu_fwspec; struct dev_archdata archdata; }; diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h index 0dac4f3..34e8d68 100644 --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -208,4 +208,33 @@ DECLARE_PER_CPU(bool_t, iommu_dont_flush_iotlb); extern struct spinlock iommu_pt_cleanup_lock; extern struct page_list_head iommu_pt_cleanup_list; +/** + * Following block was ported from Linux to help with the implementation of + * arm64 iommu devices. Hence the architecture specific compile + */ + +#if defined(CONFIG_ARM) If it is Arm only, then it should be moved in asm-arm/iommu.h. +/** + * struct iommu_fwspec - per-device IOMMU instance data + * @ops: ops for this device's IOMMU + * @iommu_fwnode: firmware handle for this device's IOMMU + * @iommu_priv: IOMMU driver private data for this device + * @num_ids: number of associated device IDs + * @ids: IDs which this device may present to the IOMMU + */ +struct iommu_fwspec { +const struct iommu_ops *ops; +struct fwnode_handle *iommu_fwnode; +void *iommu_priv; +unsigned int num_ids; +u32ids[1]; +}; + +int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode, + const struct iommu_ops *ops); +void iommu_fwspec_free(struct device *dev); +int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids); +const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode); + +#endif #endif /* _IOMMU_H_ */ Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-d
Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest
On 10/10/17 12:05 -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Sep 12, 2017 at 11:15:09AM +0800, Haozhong Zhang wrote: > > On 09/11/17 11:52 -0700, Stefano Stabellini wrote: > > > CC'ing xen-devel, and the Xen tools and x86 maintainers. > > > > > > On Mon, 11 Sep 2017, Igor Mammedov wrote: > > > > On Mon, 11 Sep 2017 12:41:47 +0800 > > > > Haozhong Zhang wrote: > > > > > > > > > This is the QEMU part patches that works with the associated Xen > > > > > patches to enable vNVDIMM support for Xen HVM domains. Xen relies on > > > > > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate > > > > > guest address space for vNVDIMM devices. > > > > > > > > > > All patches can be found at > > > > > Xen: https://github.com/hzzhan9/xen.git nvdimm-rfc-v3 > > > > > QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v3 > > > > > > > > > > Patch 1 is to avoid dereferencing the NULL pointer to non-existing > > > > > label data, as the Xen side support for labels is not implemented yet. > > > > > > > > > > Patch 2 & 3 add a memory backend dedicated for Xen usage and a hotplug > > > > > memory region for Xen guest, in order to make the existing nvdimm > > > > > device plugging path work on Xen. > > > > > > > > > > Patch 4 - 10 build and cooy NFIT from QEMU to Xen guest, when QEMU is > > > > > used as the Xen device model. > > > > > > > > I've skimmed over patch-set and can't say that I'm happy with > > > > number of xen_enabled() invariants it introduced as well as > > > > with partial blobs it creates. > > > > > > I have not read the series (Haozhong, please CC me, Anthony and > > > xen-devel to the whole series next time), but yes, indeed. Let's not add > > > more xen_enabled() if possible. > > > > > > Haozhong, was there a design document thread on xen-devel about this? If > > > so, did it reach a conclusion? Was the design accepted? If so, please > > > add a link to the design doc in the introductory email, so that > > > everybody can read it and be on the same page. > > > > Yes, there is a design [1] discussed and reviewed. Section 4.3 discussed > > the guest ACPI. > > > > [1] > > https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01921.html > > Igor, did you have a chance to read it? > > .. see below > > > > > > > > > > > > I'd like to reduce above and a way to do this might be making xen > > > > 1. use fw_cfg > > > > 2. fetch QEMU build acpi tables from fw_cfg > > > > 3. extract nvdim tables (which is trivial) and use them > > > > > > > > looking at xen_load_linux(), it seems possible to use fw_cfg. > > > > > > > > So what's stopping xen from using it elsewhere?, > > > > instead of adding more xen specific code to do 'the same' > > > > job and not reusing/sharing common code with tcg/kvm. > > > > > > So far, ACPI tables have not been generated by QEMU. Xen HVM machines > > > rely on a firmware-like application called "hvmloader" that runs in > > > guest context and generates the ACPI tables. I have no opinions on > > > hvmloader and I'll let the Xen maintainers talk about it. However, keep > > > in mind that with an HVM guest some devices are emulated by Xen and/or > > > by other device emulators that can run alongside QEMU. QEMU doesn't have > > > a full few of the system. > > > > > > Here the question is: does it have to be QEMU the one to generate the > > > ACPI blobs for the nvdimm? It would be nicer if it was up to hvmloader > > > like the rest, instead of introducing this split-brain design about > > > ACPI. We need to see a design doc to fully understand this. > > > > > > > hvmloader runs in the guest and is responsible to build/load guest > > ACPI. However, it's not capable to build AML at runtime (for the lack > > of AML builder). If any guest ACPI object is needed (e.g. by guest > > DSDT), it has to be generated from ASL by iasl at Xen compile time and > > then be loaded by hvmloader at runtime. > > > > Xen includes an OperationRegion "BIOS" in the static generated guest > > DSDT, whose address is hardcoded and which contains a list of values > > filled by hvmloader at runtime. Other ACPI objects can refer to those > > values (e.g., the number of vCPUs). But it's not enough for generating > > guest NVDIMM ACPI objects at compile time and then being customized > > and loaded by hvmload, because its structure (i.e., the number of > > namespace devices) cannot be decided util the guest config is known. > > > > Alternatively, we may introduce an AML builder in hvmloader and build > > all guest ACPI completely in hvmloader. Looking at the similar > > implementation in QEMU, it would not be small, compared to the current > > size of hvmloader. Besides, I'm still going to let QEMU handle guest > > NVDIMM _DSM and _FIT calls, which is another reason I use QEMU to > > build NVDIMM ACPI. > > > > > If the design doc thread led into thinking that it has to be QEMU to > > > generate them, then would it make the code nicer if we used fw_cfg to > > > get
Re: [Xen-devel] [RFC v2 2/7] arm64: Add definitions for fwnode_handle
Hi, On 21/09/17 01:37, Sameer Goel wrote: This will be used as a device property to match the DMA capable devices with the associated SMMU. The header file is a port from linux. The code was changed to remove the types that were not needed for Xen. I think you probably want a bit more context in the commit message about implement fwnode.h in common code. Within this series, fwnode seems to only be used by Arm. So what would be the advantage to get that in xen/? Is it going to be used by x86 or taken advantage in common code? Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI companions using fwnode_handle Signed-off-by: Sameer Goel --- xen/include/asm-arm/device.h | 2 ++ xen/include/xen/fwnode.h | 33 + 2 files changed, 35 insertions(+) create mode 100644 xen/include/xen/fwnode.h diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h index 6734ae8..78c38fe 100644 --- a/xen/include/asm-arm/device.h +++ b/xen/include/asm-arm/device.h @@ -2,6 +2,7 @@ #define __ASM_ARM_DEVICE_H #include +#include enum device_type { @@ -19,6 +20,7 @@ struct device #ifdef CONFIG_HAS_DEVICE_TREE struct dt_device_node *of_node; /* Used by drivers imported from Linux */ I was expecting a todo in the code after the discussion about leave of_node here. #endif +struct fwnode_handle *fwnode; /*fw device node identifier */ Space missing before "fw". struct dev_archdata archdata; }; diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h new file mode 100644 index 000..0fed958 --- /dev/null +++ b/xen/include/xen/fwnode.h @@ -0,0 +1,33 @@ +/* + * fwnode.h - Firmware device node object handle type definition. + * + * Copyright (C) 2015, Intel Corporation + * Author: Rafael J. Wysocki + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Ported from Linux include/linux/fwnode.h + * => commit ce793486e23e0162a732c605189c8028e0910e86 + * + * No functional Xen modifications. + */ + +#ifndef __XEN_FWNODE_H_ +#define __XEN_FWNODE_H_ + +enum fwnode_type { + FWNODE_INVALID = 0, + FWNODE_OF, + FWNODE_ACPI, + FWNODE_ACPI_STATIC, + FWNODE_IRQCHIP +}; + Looking at Linux code, the fwnode_type already disappeared from Linux (see commit db3e50f3234b "device property: Get rid of struct fwnode_handle type field"). I understand the goal on using fwnode is to help porting drivers from Linux. So how much this has changed now? Cheers, +struct fwnode_handle { + enum fwnode_type type; + struct fwnode_handle *secondary; +}; + +#endif -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 114338: regressions - FAIL
flight 114338 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/114338/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 114175 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 114175 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 114175 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 114175 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-examine 7 reboot fail REGR. vs. 114175 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 114175 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-libvirt-qcow2 7 xen-bootfail REGR. vs. 114175 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 114175 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 114175 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 114175 build-armhf-pvops 6 kernel-build fail REGR. vs. 114175 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail REGR. vs. 114175 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114175 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: linux49827b977a2e374540bc1bb1dcd9cf72952967d7 baseline version: linux8a5776a5f49812d29fe4b2d0a2d71675c3facf3f Last test of basis (not found) F
[Xen-devel] [PATCH 4/3] x86: don't ignore foreigndom on L2/L3/L4 page table updates
Silently assuming DOMID_SELF is unlikely to be a good idea for page table updates. For PGT_writable pages, though, it seems better to allow the writes, so the same check isn't being applied there. Also add blank lines between the individual case blocks. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -3542,18 +3542,28 @@ long do_mmu_update( cmd == MMU_PT_UPDATE_PRESERVE_AD, v, pg_owner); break; + case PGT_l2_page_table: +if ( unlikely(pg_owner != pt_owner) ) +break; rc = mod_l2_entry(va, l2e_from_intpte(req.val), mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, v); break; + case PGT_l3_page_table: +if ( unlikely(pg_owner != pt_owner) ) +break; rc = mod_l3_entry(va, l3e_from_intpte(req.val), mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, v); break; + case PGT_l4_page_table: +if ( unlikely(pg_owner != pt_owner) ) +break; rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn, cmd == MMU_PT_UPDATE_PRESERVE_AD, v); break; + case PGT_writable_page: perfc_incr(writable_mmu_updates); if ( paging_write_guest_entry(v, va, req.val, _mfn(mfn)) ) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 238 - DMOP map/unmap missing argument checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-238 version 2 DMOP map/unmap missing argument checks UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = DMOPs (which were a subgroup of HVMOPs in older releases) allow guests to control and drive other guests. The I/O request server page mapping interface uses range sets to represent I/O resources the emulation of which is provided by a given I/O request server. The internals of the range set implementation require that ranges have a starting value no lower than the ending one. Checks for this fact were missing. IMPACT == Malicious or buggy stub domain kernels or tool stacks otherwise living outside of Domain0 can mount a denial of service attack which, if successful, can affect the whole system. Only domains controlling HVM guests can exploit this vulnerability. (This includes domains providing hardware emulation services to HVM guests.) VULNERABLE SYSTEMS == Xen versions 4.5 and later are vulnerable. Xen versions 4.4 and earlier are not vulnerable. Only x86 systems are affected. ARM systems are not affected. This vulnerability is only applicable to Xen systems using stub domains or other forms of disaggregation of control domains for HVM guests. MITIGATION == Running only PV guests will avoid this issue. (The security of a Xen system using stub domains is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm.) CREDITS === This issue was discovered by Vitaly Kuznetsov of RedHat. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa238.patch xen-unstable, Xen 4.9.x, Xen 4.8.x, Xen 4.7.x xsa238-4.6.patch Xen 4.6.x xsa238-4.5.patch Xen 4.5.x $ sha256sum xsa238* 3cced09a1fb2936644d654c568f38580952328b84e28601b019ea7418c36 xsa238.meta 85d3f9713bef1bc86c682857dbd7388a1d1f20089363ddfc4cb9ecbd88eaffec xsa238.patch 034e91c234f6831dbaa1aaf29f4f90de2e822f99301424f7f3527f9da883ff68 xsa238-4.5.patch 29255a81729b24866e594426167de5fbef70de21ef62a95ba95de191d2a7fd54 xsa238-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 iQEcBAEBCAAGBQJZ31v7AAoJEIP+FMlX6CvZrBgIAMg3C1Gvc3rnrPjT+0Im7gdQ vBXGAWViWDs7EC1Vl5IU6lQQKETNmx40kRPyOYOVSdPzWamOotXOSadpJ49mbTX1 CA2iSJ8OAdqcPhgKjdUYVJXkybujNp6WkdlcT6ZXvEs6DLuvKJXZBaRoX2vYtObq JjwUfGgpHcOc8vLhaEjEZTWRnKJotqQPaPaDHzrtGJAkHB0F+gwqpM4lBD6Q18+/ DzyBWlDENEcoSwzDldZ/4Ktl/rOXDOPoYYZfnFmYA2puWP7ujonio8iofOy+6GH3 GoKSPs1ciC4ax1WdJqbuxM0TCStz4QFOselVQ0hEJNdH6k3mmA4wMg+6kPNDf2U= =9idj -END PGP SIGNATURE- xsa238.meta Description: Binary data xsa238.patch Description: Binary data xsa238-4.5.patch Description: Binary data xsa238-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 237 - multiple MSI mapping issues on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-237 version 2 multiple MSI mapping issues on x86 UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Multiple issues exist with the setup of PCI MSI interrupts: - - unprivileged guests were permitted access to devices not owned by them, in particular allowing them to disable MSI or MSI-X on any device - - HVM guests can trigger a codepath intended only for PV guests - - some failure paths partially tear down previously configured interrupts, leaving inconsistent state - - with XSM enabled, caller and callee of a hook disagreed about the data structure pointed to by a type-less argument IMPACT == A malicious or buggy guest may cause the hypervisor to crash, resulting in Denial of Service (DoS) affecting the entire host. Privilege escalation and information leaks cannot be excluded. VULNERABLE SYSTEMS == All Xen versions from at 3.3 onwards are vulnerable. Xen versions 3.2 and earlier are not vulnerable. Only x86 systems are affected. ARM systems are not affected. Only guests which have a physical device assigned to them can exploit the vulnerability. MITIGATION == Not passing through physical devices to untrusted guests will avoid the vulnerability. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Simon Gaiser of Qubes OS Project. RESOLUTION == Applying the appropriate attached set of patches resolves this issue. xsa237-unstable/*.patch xen-unstable xsa237-4.9/*.patch Xen 4.9.x xsa237-4.8/*.patch Xen 4.8.x, Xen 4.7.x xsa237-4.6/*.patch Xen 4.6.x xsa237-4.5/*.patch Xen 4.5.x $ sha256sum xsa237* xsa237*/* 1d4d3fa452e91d235fd688761d695752bde2f2e91fd9b17f566c4cee23ae26d0 xsa237.meta 3259cd514ea80e3cbac5b72376b4e964afb3b2cabee347440ec2bdd6e585c513 xsa237-unstable/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch 7ef53f6a5f3fc6952cb8411e31e0a670de5a78ab2c8176037db32cf147438aa6 xsa237-unstable/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb xsa237-unstable/0003-x86-MSI-disallow-redundant-enabling.patch 503b58512c5336aff9692c0d0768f38ee956c0988fa3fad4d439f13814736e06 xsa237-unstable/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch dc5f27245e44582db682ac53f24007685ea2f8cb104bad9b4d6afeaa7c4e73d2 xsa237-unstable/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch cd9cd248c4564552bbe847462d247b78ff6af1052198e6b6529178a8a624e1f6 xsa237-4.5/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch 87bbb240323b3cce9767da73961d58436c436db6da614c62ade7640f87f748dd xsa237-4.5/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 6a2e6772fa7b7a1683f7b1041f0675756268635aedb8c760ebcd9ad0ff7a xsa237-4.5/0003-x86-MSI-disallow-redundant-enabling.patch c558ca347b6df9b430fbdaf9c9b8e3b203c273be1e2bb01aa3424773b88df91d xsa237-4.5/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch 60169e2016451e1c479c4f873ee6798b6abc46e3223a60a4b83bac20a7a3d27c xsa237-4.5/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch cd9cd248c4564552bbe847462d247b78ff6af1052198e6b6529178a8a624e1f6 xsa237-4.6/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch d39d1c0eaf2ba169b6596520b05930d280721c397fafa3414b6da6168e8b73ca xsa237-4.6/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb xsa237-4.6/0003-x86-MSI-disallow-redundant-enabling.patch c558ca347b6df9b430fbdaf9c9b8e3b203c273be1e2bb01aa3424773b88df91d xsa237-4.6/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch 4cdcd71758d9e5b392c38aeafc9960a4f3ef5c109508e69b2218a8d8394edf0b xsa237-4.6/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch 1ae6aefb86ba0c48a45ecc14ff56ea0bc3d9d354937668bcacadaed1225017a8 xsa237-4.8/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch bf2ca9cb99ee64d7db77d628cec1a84684c360fd36de433cbc78fbcde8095319 xsa237-4.8/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb xsa237-4.8/0003-x86-MSI-disallow-redundant-enabling.patch 9a38899afd728d504382954de28657aa82af7da352eb4e45a5e615bd646834c5 xsa237-4.8/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch fef5c77f19e2c6229912f1fd19cbcb41c1ce554ff53be22198b2f34ea7a27314 xsa237-4.8/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch c97819cdf567c9bb2c38083a941995f
[Xen-devel] Xen Security Advisory 242 - page type reference leak on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-242 version 2 page type reference leak on x86 UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The page type system of Xen requires cleanup when the last reference for a given page is being dropped. In order to exclude simultaneous updates to a given page by multiple parties, pages which are updated are locked beforehand. This locking includes temporarily increasing the type reference count by one. When the page is later unlocked, the context precludes cleanup, so the reference that is then dropped must not be the last one. This was not properly enforced. IMPACT == A malicious or buggy PV guest may cause a memory leak upon shutdown of the guest, ultimately perhaps resulting in Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == All Xen versions from 3.4 onwards are vulnerable. Xen versions 3.3 and earlier are not vulnerable. Only x86 systems are affected. ARM systems are not affected. Only x86 PV guests can leverage the vulnerability. x86 HVM guests cannot leverage the vulnerability. MITIGATION == Running only HVM guests will avoid this vulnerability. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa242.patch xen-unstable xsa242-4.9.patch Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa242* 168db3aef00806025afa255dee35cd0c042706a27a0256744e4d63f3ee86a2e8 xsa242.meta 16848f71311c2fd6a38afd7602e59211c89a3daf29b874097dba0b1e31ba6eec xsa242.patch 5e66b6b1d1cd400905d3abd3478144539c3afa24f5a744a11809d9c5eb517b98 xsa242-4.9.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 iQEcBAEBCAAGBQJZ31wBAAoJEIP+FMlX6CvZs4YH+QH5lTpge4JLyHQRJbLry52Z 70oB+1vZIsoWg9/XONE9/l1kei0WOGPh4Pt2AWUZOXy8I/euHlMUeGZchl7cQ73M 6EOPjQ1+EXv+vIePwyjZiZmjKQJYQDZ5IsNZ3lz2oV27SkppSW6KKPFlj9G3Dc+E Fv0JwawHNBruGQu9RYWukLbCKn9g4Z0OD/4OwpzF0PY3c/zqk9aYjg318i2Na5zu tWDI9+srfzgvT9N2+om/hVBQYHp48OOIUIGtMz7M4A33LBySsETigpBaCiNmyNeG +l3ONWKF8XNeJbpYGtd3jClgXLg8Hy5MgalSCKOyB2XAgl0y2BSX3tyhOnQZKcs= =tqOh -END PGP SIGNATURE- xsa242.meta Description: Binary data xsa242.patch Description: Binary data xsa242-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 243 - x86: Incorrect handling of self-linear shadow mappings with translated guests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-243 version 3 x86: Incorrect handling of self-linear shadow mappings with translated guests UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The shadow pagetable code uses linear mappings to inspect and modify the shadow pagetables. A linear mapping which points back to itself is known as self-linear. For translated guests, the shadow linear mappings (being in a separate address space) are not intended to be self-linear. For non-translated guests, the shadow linear mappings (being the same address space) are intended to be self-linear. When constructing a monitor pagetable for Xen to run on a vcpu with, the shadow linear slot is filled with a self-linear mapping, and for translated guests, shortly thereafter replaced with a non-self-linear mapping, when the guest's %cr3 is shadowed. However when writeable heuristics are used, the shadow mappings are used as part of shadowing %cr3, causing the heuristics to be applied to Xen's pagetables, not the guest shadow pagetables. While investigating, it was also identified that PV auto-translate mode was insecure. This mode was removed in Xen 4.7 due to being unused, unmaintained and presumed broken. We are not aware of any guest implementation of PV auto-translate mode. IMPACT == A malicious or buggy HVM guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host, or cause hypervisor memory corruption. We cannot rule out a guest being able to escalate its privilege. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. HVM guests using shadow mode paging can exploit this vulnerability. HVM guests using Hardware Assisted Paging (HAP) as well as PV guests cannot exploit this vulnerability. ARM systems are not vulnerable. MITIGATION == Running only PV guests will avoid this vulnerability. Where the HVM guest is explicitly configured to use shadow paging (eg via the `hap=0' xl domain configuration file parameter), changing to HAP (eg by setting `hap=1') will avoid exposing the vulnerability to those guests. HAP is the default (in upstream Xen), where the hardware supports it; so this mitigation is only applicable if HAP has been disabled by configuration. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa243.patch xen-unstable, Xen 4.9.x xsa243-4.8.patch Xen 4.8.x xsa243-4.7.patch Xen 4.7.x xsa243-4.6-[1,2].patch Xen 4.6.x xsa243-4.{6-1,5-2}.patch Xen 4.5.x $ sha256sum xsa243* 61b05e2d6655f5d18cd53b16e03499152c603162584f64d68fad31b088cc5cd2 xsa243.meta a5b484db80346f7e75c7921ee4780567f04b9f9b4620c0cde4bfa1df3ac0f87f xsa243.patch 79e1c5e088eee8e78aa67895a29d611352c64251854e4c5129e33c85988a47a5 xsa243-4.5-2.patch 722073aad1e734e24b0b79d03a1957e491f3616fe6e244a89050f7a50f8f356b xsa243-4.6-1.patch 94cb346c486f88f2f4f701564017e1997e518a5a14218f0e38ff882c60fb382c xsa243-4.6-2.patch 465ba9e3293591a3c84c122ffd73474fe96483f5e21565440d5fbc207fa4c4a9 xsa243-4.7.patch f8e471b42502905a442d43934ac339663a6124118c9762b31f2ad930fd532e64 xsa243-4.8.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 iQEcBAEBCAAGBQJZ31wCAAoJEIP+FMlX6CvZfZIH/i6Ict2HQ3HPT8yLY6e+Lab4 XXRUutCRqiBYoxes4vsOs8SqVEBQ/AI/Ds5jpByNQqUrK/dH7CdTOthy3bsOSmHQ UcUveuMyJ7IDCjJhFYmIA6o7Bc1OiBDoA3yg1pFn4tb1eAn/3mq4OCSNhqnCPiFy MxnsQ023yCLUdHwPvNagLOwycOelD1CdZQPae8e1fuasABJfuTZ+MdREMcsJWfOo rcH5++We9yWKttJqV9om7NsyEBdiQYRJHepJb0dJwm+ZMp46A5NaqNd6/PpFmoP9 L7sgweOd/Z2taJOrDiSTAuaoKuxA0sZstUaE+BCb7Xp2aqFmnSp85gsaqdvAkCs= =ktEr -END PGP SIGNATURE- xsa243.meta Description: Binary data xsa243.patch Description: Binary data xsa243-4.5-2.patch Description: Binary data xsa243-4.6-1.patch Description: Binary data xsa243-4.6-2.patch Description: Binary
[Xen-devel] Xen Security Advisory 244 - x86: Incorrect handling of IST settings during CPU hotplug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-244 version 2 x86: Incorrect handling of IST settings during CPU hotplug UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The x86-64 architecture allows interrupts to be run on distinct stacks. The choice of stack is encoded in a field of the corresponding interrupt descriptor in the Interrupt Descriptor Table (IDT). That field selects an entry from the active Task State Segment (TSS). Since, on AMD hardware, Xen switches to an HVM guest's TSS before actually entering the guest, with the Global Interrupt Flag still set, the selectors in the IDT entry are switched when guest context is loaded/unloaded. When a new CPU is brought online, its IDT is copied from CPU0's IDT, including those selector fields. If CPU0 happens at that moment to be in HVM context, wrong values for those IDT fields would be installed for the new CPU. If the first guest vCPU to be run on that CPU belongs to a PV guest, it will then have the ability to escalate its privilege or crash the hypervisor. IMPACT == A malicious or buggy x86 PV guest could escalate its privileges or crash the hypervisor. VULNERABLE SYSTEMS == All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been checked. Only PV guests can exploit the vulnerability. HVM guests cannot exploit the vulnerability, but their presence is necessary for the exposure of the vulnerability to PV guests. Only x86 systems using SVM (AMD virtualisation extensions) rather than VMX (Intel virtualisation extensions) are vulnerable. Therefore AMD x86 hardware is vulnerable; Intel hardware is not vulnerable. ARM systems are not vulnerable. MITIGATION == Avoiding to online CPUs at runtime will avoid this vulnerability. Running only HVM or only PV guests on any individual host will also avoid this vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa244.patch xen-unstable, Xen 4.9.x, Xen 4.8.x xsa244-4.7.patch Xen 4.7.x xsa244-4.6.patch Xen 4.6.x xsa244-4.5.patch Xen 4.5.x $ sha256sum xsa244* 5b663620a1b0d5f07e7ae4d1d3506d925515d5f85830ca49dda75cab1218506f xsa244.meta bcf22b332bf3f6fe8c86e4de67f82628c9b8e257d9513c3bf5c7f5dd71d86c33 xsa244.patch 4c4543fdfd25b4a8ea7d53f3f45011ec137798e7d4e690d8f3ea58d77afb5f06 xsa244-4.5.patch eaa3ba303980d783813db7aee948a9cb2723328da5fa5650ffca7b825c21bab6 xsa244-4.6.patch 4d8cf754f760ef05488e9fb25a7ebd9a7e46f3742e91eee1a8385fd1e611ea8c xsa244-4.7.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 iQEcBAEBCAAGBQJZ31wEAAoJEIP+FMlX6CvZixEIALXqWn6ShR2MCMeiGHy1ewsX S80m2OFqHYgZuawTuA3TN3mYfQONLNpobpchU5Y/RoWxS70sfV5PqLf6IHYPlSSC 3VI+U+Q3nhPhudQo4RFkyFeDGg6dKEnver+Bfik1pHsTBB0o0ojAdgqbW+K4HEoE flqPaXuQSFSFE5mYzQ+UxI7nE9I7IwDRD+eDSE/JRtTmXuoJPB8bC4De68dM4BbM +nfaNR95PvyNTToKluYdcST7pq/jRal5/O8GSxNsolgcd6C4IZrX1wB2ibMoa1wh ElLmcw/gyT/DfvO0STjvVQ/Ryaoj3ZLjMrNRt7pA8IQ1gig312f7vCGpF0/EeYM= =9+du -END PGP SIGNATURE- xsa244.meta Description: Binary data xsa244.patch Description: Binary data xsa244-4.5.patch Description: Binary data xsa244-4.6.patch Description: Binary data xsa244-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 241 - Stale TLB entry due to page type release race
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-241 version 3 Stale TLB entry due to page type release race UPDATES IN VERSION 3 Fix ARM build issue in patches. Public release. ISSUE DESCRIPTION = x86 PV guests effect TLB flushes by way of a hypercall. Xen tries to reduce the number of TLB flushes by delaying them as much as possible. When the last type reference of a page is dropped, the need for a TLB flush (before the page is re-used) is recorded. If a guest TLB flush request involves an Inter Processor Interrupt (IPI) to a CPU in which is the process of dropping the last type reference of some page, and if that IPI arrives at exactly the right instruction boundary, a stale time stamp may be recorded, possibly resulting in the later omission of the necessary TLB flush for that page. IMPACT == A malicious x86 PV guest may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS == All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been checked. Only x86 systems are affected. ARM systems are not affected. Only x86 PV guests can leverage the vulnerability. x86 HVM guests cannot leverage the vulnerability. RISK ASSESSMENT === A successful attack would require introducing an extended delay between two adjacent operations on one cpu -- long enough for two hypercalls to complete on another cpu. The security team currently has no proof-of-concept for this vulnerability. However, techniques for these sorts of timing-based attacks are continually advancing, so we still recommend users potentially affected by this issue apply the patch as soon as reasonably possible. MITIGATION == Running only HVM guests will avoid this vulnerability. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa241.patch xen-unstable xsa241-4.9.patch Xen 4.9.x xsa241-4.8.patch Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa241* 5e239ba4dbd74fd61e59a27f9abc8ea6ba32532bdf81eeb2d7e66f0fd53e40b4 xsa241.meta b8db933d53e7e289652ffda6c46ce284a0254a9f8bc9e1be6793e388009f49ce xsa241.patch 443a5b0818045ada44fad0370ac01af0c96181be5a4078ae3b2575799e4a4e5b xsa241-4.8.patch 927ef14d875556481c38d4065f501211a78eec1c2396a954a4a4abfb9255960f xsa241-4.9.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 iQEcBAEBCAAGBQJZ31v/AAoJEIP+FMlX6CvZsNgIALcJ/DeUN5nv8duBvC3hbAX6 NABBtlVJ6K7qZpAf+04Eztym4bEWXWGtJ1BQVCJ6aPwPZ4aOUodA/zRBEQS7Xp8F 5P5U3Qwa/C+slqLh7QfYdwlkgdMRG67yWIo2xMOEcfORlPjc1wDxohtCQZT9uiMs Y9Xllt/sLhGgYq4+TpNvJyYMzvPp1+oBEuqcR58IZ2aepQJAlPl3LnLdYyN8TAqv MBmli7cRO/vYn5z7aII9NbuF8XEnx0Vfqp7EufLU1LQyG4S9jYXd0xvD6BjjkGWM N/dvJTMq8HXS00VUAoONOv+blq2AdRs9oYD8yeMCglUhpeK8cIaEsYzhOHbCvlI= =1uZK -END PGP SIGNATURE- xsa241.meta Description: Binary data xsa241.patch Description: Binary data xsa241-4.8.patch Description: Binary data xsa241-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 239 - hypervisor stack leak in x86 I/O intercept code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-239 version 2 hypervisor stack leak in x86 I/O intercept code UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Intercepted I/O operations may deal with less than a full machine word's worth of data. While read paths had been the subject of earlier XSAs (and hence have been fixed), at least one write path was found where the data stored into an internal structure could contain bits from an uninitialized hypervisor stack slot. A subsequent emulated read would then be able to retrieve these bits. IMPACT == A malicious unprivileged x86 HVM guest may be able to obtain sensitive information from the host or other guests. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not affected. Only HVM guests can leverage this vulnerability. PV guests cannot leverage this vulnerability. MITIGATION == Running only PV guests will avoid this issue. CREDITS === This issue was discovered by Roger Pau Monné of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa239.patch xen-unstable, Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa239-4.5.patch Xen 4.5.x $ sha256sum xsa239* eb7971be89199eb3ff510f4f5650fd5a8ec588b9fcb8f89230216fac4214ef21 xsa239.meta 087a8b3cf7ecbdbde593033c127cbcf6c37f532bf33d90f72c19e493970a799c xsa239.patch b91a68fe67240f2a5bb9460c5b650e9595364afa180f8702aef783815e3d7dcd xsa239-4.5.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 iQEcBAEBCAAGBQJZ31v8AAoJEIP+FMlX6CvZ1AQIAMmN4FghnJvlec7xsPQBgPBs nlOItkaXMYZnIajohG2/U5zfFU02oj0GmCz4CDODaKiaZem2p69LzVeVOkqAqQ4p osYMy918GROxrvfHo+36gCBDfwlB7TWr6dQzM50nHh+6O1l1+QlpCw3k+gb5CnNT Rkn/V1ZZGVy7ycwGiMK1mP0C9hsGyuC5xxwCR9XxK01X0x+NTEXZWAS+GbPHBJAS HyopB9W+PkQ0qL/j7VjfGdUWTGquBPffnDGQFBN7CqQ+Pt6Mpv4RvkHiS3NTP5qd 8rp5M0xjVBnpCC/JAQXL9oLK+LZf99oIal1zbQ1FrECYFXIIyf/hUMxguBbsON4= =8UQF -END PGP SIGNATURE- xsa239.meta Description: Binary data xsa239.patch Description: Binary data xsa239-4.5.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] x86: tighten MMU_*PT_UPDATE* check and combine error paths
>>> On 12.10.17 at 13:31, wrote: > On 12/10/17 11:01, Jan Beulich wrote: >> Don't accept anything other than r/w RAM pages and move the paged-out >> check into the (unlikely) error path following that check. >> >> Signed-off-by: Jan Beulich > > How does dom0 boot with this change in place? You appear to have > prohibited mapping MMIO frames. The page in question is a page table one, which can't be MMIO. Dom0 is booting fine. Jan >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -3507,18 +3507,18 @@ long do_mmu_update( >> gmfn = req.ptr >> PAGE_SHIFT; >> page = get_page_from_gfn(pt_owner, gmfn, &p2mt, P2M_ALLOC); >> >> -if ( p2m_is_paged(p2mt) ) >> +if ( unlikely(!page) || p2mt != p2m_ram_rw ) >> { >> -ASSERT(!page); >> -p2m_mem_paging_populate(pt_owner, gmfn); >> -rc = -ENOENT; >> -break; >> -} >> - >> -if ( unlikely(!page) ) >> -{ >> -gdprintk(XENLOG_WARNING, >> - "Could not get page for normal update\n"); >> +if ( page ) >> +put_page(page); >> +if ( p2m_is_paged(p2mt) ) >> +{ >> +p2m_mem_paging_populate(pt_owner, gmfn); >> +rc = -ENOENT; >> +} >> +else >> +gdprintk(XENLOG_WARNING, >> + "Could not get page for normal update\n"); >> break; >> } >> >> >> >> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel