Re: [Xen-devel] [PATCH] x86emul: adjust handling of AVX2 gathers
On 20/04/18 11:25, Jan Beulich wrote: > HVM's MMIO cache only has a capacity of three entries. Once running out > of entries, hvmemul_linear_mmio_access() will return > X86EMUL_UNHANDLEABLE. Since gathers are an iterative process anyway, > simply commit the portion of work done in this and hypothetical similar > cases, exiting back to guest context for the insn to be retried. > > Signed-off-by: Jan Beulich Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 1/3] xen: Introduce vcpu_sleep_nosync_locked()
On 11/04/18 14:25, George Dunlap wrote: > There are a lot of places which release a lock before calling > vcpu_sleep_nosync(), which then just grabs the lock again. This is > not only a waste of time, but leads to more code duplication (since > you have to copy-and-paste recipes rather than calling a unified > function), which in turn leads to an increased chance of bugs. > > Introduce vcpu_sleep_nosync_locked(), which can be called if you > already hold the schedule lock. > > Signed-off-by: George Dunlap Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 2/3] xen: Refactor migration
On 11/04/18 14:25, George Dunlap wrote: > The current sequence to initiate vcpu migration is inefficent and error-prone: > > - The initiator sets VPF_migraging with the lock held, then drops the > lock and calls vcpu_sleep_nosync(), which immediately grabs the lock > again > > - A number of places unnecessarily check for v->pause_flags in between > those two > > - Every call to vcpu_migrate() must be prefaced with > vcpu_sleep_nosync() or introduce a race condition; this code > duplication is error-prone > > - In the event that v->is_running is true at the beginning of > vcpu_migrate(), it's almost certain that vcpu_migrate() will end up > being called in context_switch() as well; we might as well simply > let it run there and save the duplicated effort (which will be > non-negligible). > > Instead, introduce vcpu_migrate_start() to initiate the process. > vcpu_migrate_start() is called with the scheduling lock held. It not > only sets VPF_migrating, but also calls vcpu_sleep_nosync_locked() > (which will automatically do nothing if there's nothing to do). > > Rename vcpu_migrate() to vcpu_migrate_finish(). Check for v->is_running and > pause_flags & VPF_migrating at the top and return if appropriate. > > Then the way to initiate migration is consistently: > > * Grab lock > * vcpu_migrate_start() > * Release lock > * vcpu_migrate_finish() > > Signed-off-by: George Dunlap Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Should PV frontend drivers trust the backends?
On 04/25/2018 04:47 PM, Paul Durrant wrote: -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of Juergen Gross Sent: 25 April 2018 13:43 To: xen-devel Subject: [Xen-devel] Should PV frontend drivers trust the backends? This is a followup of a discussion on IRC: The main question of the discussion was: "Should frontend drivers trust their backends not doing malicious actions?" This IMO includes: 1. The data put by the backend on the ring page(s) is sane and consistent, meaning that e.g. the response producer index is always ahead of the consumer index. 2. Response data won't be modified by the backend after the producer index has been incremented signaling the response is valid. 3. Response data is sane, e.g. an I/O data length is not larger than the buffer originally was. 4. When a response has been sent all grants belonging to the request have been unmapped again by the backend, meaning that the frontend can assume the grants can be removed without conflict. Today most frontend drivers (at least in the Linux kernel) seem to assume all of the above is true (there are some exceptions, but never for all items): - they don't check sanity of ring index values - they don't copy response data into local memory before looking at it - they don't verify returned data length (or do so via BUG_ON()) - they BUG() in case of a conflict when trying to remove a grant So the basic question is: should all Linux frontend drivers be modified in order to be able to tolerate buggy or malicious backends? Or is the list of trust above fine? IMO even in case the frontends do trust the backends to behave sane this doesn't mean driver domains don't make sense. Driver domains still make a Xen host more robust as they e.g. protect the host against driver failures normally leading to a crash of dom0. I see the general question as being analogous to 'should a Linux device driver trust its hardware' and I think the answer for a general purpose OS like linux is 'yes'. Now, having worked on fault tolerant systems in a past life, there are definitely cases where you want your OS not to implicitly trust its peripheral hardware and hence special device drivers are used. So what do you do if counters provided by the untrusted HW are ok and the payload is not? I think the same would apply for virtual machines in situations where a driver domain is not wholly controlled by a host administrator or is not trusted to the same extent as dom0 for other reasons; i.e. they should have specialist frontends. I believe we might be able to express some common strategy for the frontends. I do understand though that it all needs to be decided on case by case basis, but common things could still be there, e.g. if prod/cons counters are not in sync what a frontend needs to do: - should it keep trying to get in sync - might be a bad idea as the req/resp data may already become inconsistent (net can probably survive, but not block) - should it tear down the connection with the backend - this may render in the whole system instability, e.g. imagine you tear down a "/" block device - should it BUG_ON and die To me the second option (tear down the connection) seems to be more reasonable, although it can still render the guest unusable, but at least it gives a chance for the guest to recover in a proper way And, if my assumption is correct, we still do trust the contents of the requests and responses, e.g. the payload is still trusted. This also questions the approach, e.g. if we don't trust backend's counters, then why do we trust the payload it sends? And there is no obvious way to check the payload integrity. So, either we trust the backend and accept the risks or we need to develop some complex approach to address the above. Thank you, Oleksandr Paul Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 122396: all pass - PUSHED
flight 122396 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/122396/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf d3180516f31b93f3dc14ebb0191cd78bcfc052d9 baseline version: ovmf ee4dc24f57c32a445e7c747396c9bfbd8b221568 Last test of basis 122362 2018-04-23 11:18:13 Z2 days Testing same since 122396 2018-04-24 18:04:23 Z1 days1 attempts People who touched revisions under test: Evan Lloyd Gary Lin Girish Pathak Girish Pathak Laszlo Ersek Leif Lindholm jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git ee4dc24f57..d3180516f3 d3180516f31b93f3dc14ebb0191cd78bcfc052d9 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing test] 122391: trouble: broken/fail/pass
flight 122391 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122391/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-raw broken test-amd64-amd64-xl-qemut-ws16-amd64 broken test-amd64-i386-freebsd10-i386 broken Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-ws16-amd64 4 host-install(4) broken pass in 122356 test-amd64-i386-freebsd10-i386 4 host-install(4)broken pass in 122356 test-amd64-i386-xl-raw4 host-install(4) broken pass in 122356 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail in 122356 pass in 122391 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail in 122356 pass in 122391 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 122356 pass in 122391 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 122356 never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail 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-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-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-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-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass 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-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop 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-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-a
[Xen-devel] [qemu-mainline test] 122394: trouble: broken/fail/pass
flight 122394 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/122394/ 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 test-armhf-armhf-xl-multivcpu 4 host-install(4) broken REGR. vs. 122357 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122357 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122357 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122357 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122357 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122357 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122357 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 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-ws16-amd64 17 guest-stop 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 version targeted for testing: qemuu4743c23509a51bd4ee85cc272287a41917d1be35 baseline version: qemuu27e757e29cc79f3f104d2a84d17cdb3b4c11c8ff Last test of basis 122357 2018-04-23 11:07:12 Z2 days Testing same since 122394 2018-04-24 16:40:23 Z1 days1 attempts People who touched revisions under test: Peter Maydell jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386
[Xen-devel] [linux-3.18 test] 122388: regressions - FAIL
flight 122388 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122388/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 122286 test-armhf-armhf-xl-xsm 16 guest-start/debian.repeat fail REGR. vs. 122286 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail like 122286 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122286 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122286 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122286 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122286 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122286 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122286 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122286 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail 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-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-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 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-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-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-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 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 build-arm64-pvops 6 kernel-build fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop 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-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: linux915b8f498b1a2dacc4f81dc949e310915c7374f2 baseline version: linux78db2bbfa06cc39707054093fbbc5e573a643d3e Last test of basis 122286 2018-04-14 16:36:32 Z 11 days Testing same since 122388 2018-04-24 07:40:13 Z1 days1 attempts People who touched r
[Xen-devel] [xen-unstable-smoke test] 122421: tolerable all pass - PUSHED
flight 122421 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122421/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 67c632e38a9894269babd854e122c47a8fbf545c baseline version: xen 82fed8530d8832a9a7b99554dfc49b041351785a Last test of basis 122416 2018-04-25 15:03:27 Z0 days Testing same since 122421 2018-04-25 17:00:32 Z0 days1 attempts People who touched revisions under test: Ian Jackson jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 82fed8530d..67c632e38a 67c632e38a9894269babd854e122c47a8fbf545c -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On Wed, Apr 25, 2018 at 08:34:55AM +0200, Daniel Vetter wrote: > On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote: > > On 04/24/2018 11:35 PM, Dongwon Kim wrote: > > > Had a meeting with Daniel and talked about bringing out generic > > > part of hyper-dmabuf to the userspace, which means we most likely > > > reuse IOCTLs defined in xen-zcopy for our use-case if we follow > > > his suggestion. > > I will still have kernel side API, so backends/frontends implemented > > in the kernel can access that functionality as well. > > > > > > So assuming we use these IOCTLs as they are, > > > Several things I would like you to double-check.. > > > > > > 1. returning gref as is to the user space is still unsafe because > > > it is a constant, easy to guess and any process that hijacks it can easily > > > exploit the buffer. So I am wondering if it's possible to keep dmabuf-to > > > -gref or gref-to-dmabuf in kernel space and add other layers on top > > > of those in actual IOCTLs to add some safety.. We introduced flink like > > > hyper_dmabuf_id including random number but many says even that is still > > > not safe. > > Yes, it is generally unsafe. But even if we have implemented > > the approach you have in hyper-dmabuf or similar, what stops > > malicious software from doing the same with the existing gntdev UAPI? > > No need to brute force new UAPI if there is a simpler one. > > That being said, I'll put security aside at the first stage, > > but of course we can start investigating ways to improve > > (I assume you already have use-cases where security issues must > > be considered, so, probably you can tell more on what was investigated > > so far). Yeah, although we think we lowered the chance of guessing the right id by adding random number to it, the security hole is still there as far as we use a constant id across VMs. We understood this from the beginning but couldn't find a better way. So what we proposed is to make sure our customer understand this and prepare very secure way to handle this id in the userspace (mattrope however recently proposed a "hyper-pipe" which FD-type id can be converted and exchanged safely through. So we are looking into this now.) And another approach we have proposed is to use event-polling, that lets the privileged userapp in importing guest to know about a new exported DMABUF so that it can retrieve it from the queue then redistribute to other applications. This method is not very flexible however, is one way to hide ID from userspace completely. Anyway, yes, we can continue to investigate the possible way to make it more secure. > > Maybe a bit more context here: > > So in graphics we have this old flink approach for buffer sharing with > processes, and it's unsafe because way too easy to guess the buffer > handles. And anyone with access to the graphics driver can then import > that buffer object. We switched to file descriptor passing to make sure > only the intended recipient can import a buffer. > > So at the vm->vm level it sounds like grefs are safe, because they're only > for a specific other guest (or sets of guests, not sure about). That means > security is only within the OS. For that you need to make sure that > unpriviledge userspace simply can't ever access a gref. If that doesn't > work out, then I guess we should improve the xen gref stuff to have a more > secure cookie. > > > > 2. maybe we could take hypervisor-independent process (e.g. SGT<->page) > > > out of xen-zcopy and put those in a new helper library. > > I believe this can be done, but at the first stage I would go without > > that helper library, so it is clearly seen what can be moved to it later > > (I know that you want to run ACRN as well, but can I run it on ARM? ;) > > There's already helpers for walking sgtables and adding pages/enumerating > pages. I don't think we need more. ok, where would that helpers be located? If we consider we will use these with other hypervisor drivers, maybe it's better to place those in some common area? > > > > 3. please consider the case where original DMA-BUF's first offset > > > and last length are not 0 and PAGE_SIZE respectively. I assume current > > > xen-zcopy only supports page-aligned buffer with PAGE_SIZE x n big. > > Hm, what is the use-case for that? Just in general use-case.. I was just considering the case (might be corner case..) where sg->offset != 0 or sg->length != PAGE_SIZE. Hyper dmabuf sends this information (first offset and last length) together with references for pages. So I was wondering if we should so similar thing in zcopy since your goal is now to cover general dma-buf use-cases (however, danvet mentioned hard constaint of dma-buf below.. so if this can't happen according to the spec, then we can ignore it..) > > dma-buf is always page-aligned. That's a hard constraint of the linux > dma-buf interface spec. > -Daniel Hmm.. I am little bit confused.. So does it mean dmabuf->size is always n*P
[Xen-devel] [xen-unstable-smoke test] 122416: tolerable all pass - PUSHED
flight 122416 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122416/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 82fed8530d8832a9a7b99554dfc49b041351785a baseline version: xen 5a5c368faf45ced8a8c6235f4fbf5cdb38ec939f Last test of basis 122412 2018-04-25 13:00:34 Z0 days Testing same since 122416 2018-04-25 15:03:27 Z0 days1 attempts People who touched revisions under test: Ian Jackson jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 5a5c368faf..82fed8530d 82fed8530d8832a9a7b99554dfc49b041351785a -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]
On 25/04/18 17:58, Ian Jackson wrote: > Ian Jackson writes ("Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support > matrix generation [and 4 more messages]"): >> Thanks everyone. I have pushed this to staging-4.10, including the >> patch 10/9. > > The first cut of the cron job is now running. So far it is only > running off staging, and the output is here: > > http://xenbits.xen.org/docs/unstable-staging/support-matrix.html > > It's labelled DRAFT because it's from staging, not because it's > hand-edited or anything. > > When we get pushes of all the relevant branches to the corresponding > stable branches, I think the non-DRAFT version is ready to go. > > Ian. > The links to the 4.10 SUPPORT.html aren't working: https://xenbits.xen.org/docs/4.10-testing/SUPPORT.html Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] docs/support-matrix-generate: use `git log' not `git-log'
On 25/04/18 17:56, Ian Jackson wrote: > I found this bug when trying to set up the cron job. > > Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]
Ian Jackson writes ("Re: [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]"): > Thanks everyone. I have pushed this to staging-4.10, including the > patch 10/9. The first cut of the cron job is now running. So far it is only running off staging, and the output is here: http://xenbits.xen.org/docs/unstable-staging/support-matrix.html It's labelled DRAFT because it's from staging, not because it's hand-edited or anything. When we get pushes of all the relevant branches to the corresponding stable branches, I think the non-DRAFT version is ready to go. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 4.11.0 RC1 panic
On Wed, Apr 25, 2018 at 09:28:03AM -0600, Jan Beulich wrote: > >>> On 25.04.18 at 16:42, wrote: > > On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote: > >> > Without line numbers associated with at least the top stack trace entry > >> > I can only guess what it might be - could you give the patch below a try? > >> > (This may not be the final patch, as I'm afraid there may be some race > >> > here, but I'd have to work this out later.) > >> > >> Yes, this works. thanks ! > >> I'll now put this version on the NetBSD testbed I'm running. > >> This should put some pressure on it. > > > > Running NetBSD tests in several guests I got: > > (XEN) > > (XEN) > > (XEN) Panic on CPU 1: > > (XEN) Assertion 'oc > 0' failed at mm.c:628 > > (XEN) > > (see attached file for complete report). > > Do you know what exactly the guest was doing at that time? Unfortunably no. It was running the NetBSD test benchs, but as this is automated I don't even know what version of NetBSD was running in the guests. BTW there doesn't seem to be a domain number in the panic message ... > IOW do > you have any information on how to repro (preferably without having > to run NetBSD)? Unfortunably no, and it's not reliably reproductible either. A cron job starts running the tests for available builds daily, and the panic occurs once in a while. You may be able to reproduce it with a linux dom0: install anita from http://www.gson.org/netbsd/anita/download/ this is a set of python script; so you should be able to extract the tar.gz and run the anita script in there. Then run: ./anita --test-timeout 14400 --vmm xl --vmm-args vcpus=4 --disk-size 2G --memory-size 256M test http://ftp.fr.netbsd.org/pub/NetBSD-daily/HEAD/201804210730Z/amd64/ you will have to adjust the URLs: these are daily builds, and older versions are deleted when newer ones are build. You can also use other branches instead of HEAD. Eventually Xen will panic (but only once in a while). > Did these failures start occurring recently (your > mention of 4.8 seems to suggest otherwise)? Looking at the server's log, the first time I've seen them was with Xen 4.6.6, with patches up to XSA244. Before that it was running 4.6.5 with patch for XSA-212. It looks like the ASSERT() was added as part of XSA240. Then I upgraded to Xen 4.8.x (also with the security patches) but this didn't fix the problem. I still had it with 4.8.3, and now with 4.11 too (I didn't try anything else between 4.8 and 4.11) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] docs/support-matrix-generate: use `git log' not `git-log'
I found this bug when trying to set up the cron job. Signed-off-by: Ian Jackson --- docs/support-matrix-generate | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/support-matrix-generate b/docs/support-matrix-generate index b5ce3f4..a3d9332 100755 --- a/docs/support-matrix-generate +++ b/docs/support-matrix-generate @@ -139,7 +139,7 @@ END # find previous version search_commit="$current_ref" while true; do -search_commit=$(git-log --pretty=format:%H -n1 \ +search_commit=$(git log --pretty=format:%H -n1 \ -G 'XEN.*VERSION' $search_commit -- $versionfile) if ! [ "$search_commit" ]; then search_version=''; break; fi -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] Add Designated Reviewer (R:) to MAINTAINERS (plus a test case)
On Tue, Apr 24, 2018 at 04:56:21PM +0100, Lars Kurth wrote: > This follows up from a conversation after the April x86 community call, in > which I had > the following action: Lars to propose fixing CC issue in xen.git:MAINTAINERS > copying > the R section entries from Linux.git:MAINTAINERS (will need changes to > get_maintainers.pl also) > > Lars Kurth (2): > Add Designated Reviewer (R:) to MAINTAINERS file and add support for > it in get_maintainer.pl > Add Brian Woods as Designated reviewer to AMD IOMMU and AMD SVM Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11
>>> On 25.04.18 at 17:26, wrote: > Juergen Gross writes ("[PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11"): >> Some tags have been changed in 4.11. Adapt the 4.10 ones to match in >> order to produce an easier to read support HTML table. > > Reviwed-by: Ian Jackson > > An example of the resulting output is here: > https://xenbits.xen.org/people/iwj/2018/support-matrix-example-D/t.html > > Jan, are you happy for this to go into 4.10 now ? Yes. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 4.11.0 RC1 panic
>>> On 25.04.18 at 16:42, wrote: > On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote: >> > Without line numbers associated with at least the top stack trace entry >> > I can only guess what it might be - could you give the patch below a try? >> > (This may not be the final patch, as I'm afraid there may be some race >> > here, but I'd have to work this out later.) >> >> Yes, this works. thanks ! >> I'll now put this version on the NetBSD testbed I'm running. >> This should put some pressure on it. > > Running NetBSD tests in several guests I got: > (XEN) > (XEN) > (XEN) Panic on CPU 1: > (XEN) Assertion 'oc > 0' failed at mm.c:628 > (XEN) > (see attached file for complete report). Do you know what exactly the guest was doing at that time? IOW do you have any information on how to repro (preferably without having to run NetBSD)? Did these failures start occurring recently (your mention of 4.8 seems to suggest otherwise)? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11
Juergen Gross writes ("[PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11"): > Some tags have been changed in 4.11. Adapt the 4.10 ones to match in > order to produce an easier to read support HTML table. Reviwed-by: Ian Jackson An example of the resulting output is here: https://xenbits.xen.org/people/iwj/2018/support-matrix-example-D/t.html Jan, are you happy for this to go into 4.10 now ? Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH-for-4.10 V2] adapt SUPPORT.md to match 4.11
Some tags have been changed in 4.11. Adapt the 4.10 ones to match in order to produce an easier to read support HTML table. Signed-off-by: Juergen Gross --- SUPPORT.md | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index f85dda8933..96002ea661 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -78,9 +78,9 @@ Fully virtualised guest using hardware virtualisation extensions Requires hardware virtualisation support (Intel VMX / AMD SVM) -Status: Supported +Status, domU: Supported -### x86/PVH guest +### x86/PVH PVH is a next-generation paravirtualized mode designed to take advantage of hardware virtualization support when possible. @@ -88,9 +88,9 @@ During development this was sometimes called HVMLite or PVHv2. Requires hardware virtualisation support (Intel VMX / AMD SVM) -Status: Supported +Status, domU: Supported -### ARM guest +### ARM ARM only has one guest type at the moment -- 2.13.6 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 10/10] xen/arm: Call check_local_cpu_errata for secondary CPU only on boot
Hi Julien, On Mon, Apr 23, 2018 at 1:46 PM, Julien Grall wrote: > Hi, > > On 20/04/18 13:25, Mirela Simonovic wrote: >> >> Checking CPU errata should be done only when a CPU is initially booted. >> It is assumed that the CPU which is hotplugged after the system/Xen boots, >> was initially hotplugged during the system/Xen boot, so errata is checked >> by each CPU only once, on boot. > > > It is a good idea to document the assumption in the code. This will help to > know what is missing for other use case. > >> >> Signed-off-by: Mirela Simonovic >> >> --- >> CC: Stefano Stabellini >> CC: Julien Grall >> --- >> xen/arch/arm/smpboot.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c >> index d01b51592d..5d6c6cadec 100644 >> --- a/xen/arch/arm/smpboot.c >> +++ b/xen/arch/arm/smpboot.c >> @@ -366,8 +366,8 @@ void start_secondary(unsigned long boot_phys_offset, >> if ( system_state != SYS_STATE_boot ) >> setup_virt_paging_secondary(); >> - >> -check_local_cpu_errata(); >> +else >> +check_local_cpu_errata(); > > > No, check_local_cpu_errata should be called for everyone. This check should Could you please clarify what you meant with "for everyone"? My understanding is that you suggested this in https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00979.html Did something change meanwhile? > be moved in the function with a TODO explaining what needs to be done. > Likely this will be go over the CPU errata and see if there are any issue > with the one currently selected. Please clarify, I don't follow this. > > Also, I just realized that any "cpu capability" (e.g spectre workaround) > that requires to be enabled will not be done on hotplugged CPU. You likely > need to implement a version of enable_errata_workaround for them. > Could you please point me to a place where this is done on boot? Thanks, Mirela > Cheers, > > >> printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id()); >> > > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation [and 4 more messages]
Ian Jackson writes ("[PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation"): > This is a backport of my two recent series to fix bugs in SUPPORT.md, > format it as part of the published docs, and use relative position of > the `Status' stanza compared to descriptive text to indicate whether > the text is a caveat that deserves a footnote. Thanks everyone. I have pushed this to staging-4.10, including the patch 10/9. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.9-testing test] 122386: trouble: blocked/broken/fail/pass
flight 122386 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122386/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken test-amd64-i386-xl-qemuu-debianhvm-amd64broken test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken build-armhf 4 host-install(4)broken REGR. vs. 121761 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-amd64 4 host-install(4) broken pass in 122355 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken pass in 122355 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 122355 pass in 122386 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 122355 pass in 122386 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass in 122355 test-amd64-i386-xl-qemut-ws16-amd64 14 guest-localmigrate fail pass in 122355 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 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-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-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl 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-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 122355 like 121728 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 122355 like 121761 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 122355 like 121761 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 122355 like 121761 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 122355 like 121761 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 122355 never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 122355 never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 122355 never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 122355 never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 122355 never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 122355 never pass test-armhf-armhf-xl-rtds13 migrate-support-check fail in 122355 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 122355 never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 122355 never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 122355 never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 122355 never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 122355 never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 122355 never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 122355 never pass test-armhf-armhf-xl 13 migrate-support-check fail in 122355 never pass test-armhf-armhf-xl 14 saverestore-support-check fail in 122355 never pass test-armhf-armhf-libvirt13 migrate-support-check fail in 122355 never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail in 122355 never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 122355 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 122355 never pass test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 121704 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 121704 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 121728 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 121761 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 121761 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 121761 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 121761 test-amd64-amd64-libvirt 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-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail n
Re: [Xen-devel] [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info
> On Apr 25, 2018, at 2:00 PM, Ian Jackson wrote: > > This turns all the things which were treated as caveats, but which > don't need to be footnoted in the matrix, into descriptions. > > For the benefit of the support matrix generator, this patch (or a > version of it) should be backported to 4.10. > > Signed-off-by: Ian Jackson > Release-acked-by: Juergen Gross > (cherry picked from commit 67b46e14cb943e27134e9c6d7b41b27bdd8c6ae9) > > Merge conflicts resolved: > - x86/HVM: 4.11 talks about "Status, domU" > - x86/PVH: 4.11 mentions domO so heading is different too > - ARM: Heading in 4.11 says just "ARM", in 4.10 "ARM guest” Reviewed-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 122412: tolerable all pass - PUSHED
flight 122412 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122412/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 5a5c368faf45ced8a8c6235f4fbf5cdb38ec939f baseline version: xen 27170adb54a558e11defcd51989326a9beb95afe Last test of basis 122392 2018-04-24 13:00:34 Z1 days Testing same since 122412 2018-04-25 13:00:34 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Ian Jackson Jan Beulich jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 27170adb54..5a5c368faf 5a5c368faf45ced8a8c6235f4fbf5cdb38ec939f -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 4.11.0 RC1 panic
On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote: > > Without line numbers associated with at least the top stack trace entry > > I can only guess what it might be - could you give the patch below a try? > > (This may not be the final patch, as I'm afraid there may be some race > > here, but I'd have to work this out later.) > > Yes, this works. thanks ! > I'll now put this version on the NetBSD testbed I'm running. > This should put some pressure on it. Running NetBSD tests in several guests I got: (XEN) (XEN) (XEN) Panic on CPU 1: (XEN) Assertion 'oc > 0' failed at mm.c:628 (XEN) (see attached file for complete report). I got similar panics on Xen 4.8 after patching for meltdown (XSA-254). I'll try the patch from XSA-259 -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- (XEN) Assertion 'oc > 0' failed at mm.c:628 (XEN) [ Xen-4.11-rcnb0 x86_64 debug=y Not tainted ] (XEN) CPU:1 (XEN) RIP:e008:[] mm.c#dec_linear_entries+0x12/0x20 (XEN) RFLAGS: 00010246 CONTEXT: hypervisor (d14v3) (XEN) rax: rbx: 4401 rcx: 00189b0d (XEN) rdx: 0400 rsi: 0008 rdi: 82e0031349c0 (XEN) rbp: 82e0031361a0 rsp: 8301bf15fc08 r8: (XEN) r9: 0200 r10: r11: (XEN) r12: 82e0031349c0 r13: r14: 10ff (XEN) r15: 1000 cr0: 80050033 cr4: 26e4 (XEN) cr3: 0001b98de000 cr2: cd9ffe80 (XEN) fsb: c0e02000 gsb: gss: (XEN) ds: 0011 es: 0011 fs: 0031 gs: 0011 ss: cs: e008 (XEN) Xen code around (mm.c#dec_linear_entries+0x12/0x20): (XEN) c1 47 1e 66 85 c0 7f 02 <0f> 0b c3 66 66 2e 0f 1f 84 00 00 00 00 00 41 54 (XEN) Xen stack trace from rsp=8301bf15fc08: (XEN)82d080288e3e 00800063 8301bf15 4c02 (XEN)82e0031361a0 82e0031349c0 8301b970e000 0001 (XEN)82004000b000 0200 82d08028945f 01fd (XEN)82e0031349c0 82d080288869 00189a4e (XEN)8301bf15 4401 82e0031349c0 (XEN)00ff 10ff 1000 82d080288e07 (XEN)000101000206 8301bf15 4402 00189a4e (XEN)82e0031349c0 8301b970e000 82008000c000 (XEN) 82d08028949f 82d0802906cd 8300bf9be000 (XEN)0001802a7eb2 8301b970e000 8301b970e000 (XEN)0007 8300bf9be000 7ff0 (XEN)8301b970e000 82e0031ab060 82d0804b0058 82d0804b0060 (XEN)0018d583 0018d583 0004 00189a4e (XEN)cd9c9ce4 82008000c018 0001 cd9c9af4 (XEN)82d080386b30 0001 8301bf15 82d080295190 (XEN)8301bf15fe14 0001 82008000c000 (XEN)7ff0 00048036b1d8 cd7cc0189a4e 8301bf15fef8 (XEN)8300bf9be000 01a0 deadf00d 0004 (XEN)deadf00d 82d0803672fa 82d07ff0 82d0 (XEN)82d1 82d0cd9c9ae8 82d08036b1e4 82d08036b1d8 (XEN) Xen call trace: (XEN)[] mm.c#dec_linear_entries+0x12/0x20 (XEN)[] mm.c#_put_page_type+0x13e/0x340 (XEN)[] mm.c#put_page_from_l2e+0xdf/0x110 (XEN)[] free_page_type+0x2f9/0x790 (XEN)[] mm.c#_put_page_type+0x107/0x340 (XEN)[] put_page_type_preemptible+0xf/0x10 (XEN)[] do_mmuext_op+0x73d/0x1810 (XEN)[] compat_mmuext_op+0x430/0x450 (XEN)[] pv_hypercall+0x3aa/0x430 (XEN)[] entry_int82+0x74/0xc0 (XEN)[] entry_int82+0x68/0xc0 (XEN)[] entry_int82+0x74/0xc0 (XEN)[] entry_int82+0x68/0xc0 (XEN)[] entry_int82+0x74/0xc0 (XEN)[] entry_int82+0x68/0xc0 (XEN)[] entry_int82+0x74/0xc0 (XEN)[] do_entry_int82+0x1e/0x20 (XEN)[] entry_int82+0xb1/0xc0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged
Hi Julien, On Wed, Apr 25, 2018 at 3:23 PM, Julien Grall wrote: > Hi, > > > On 25/04/18 14:09, Mirela Simonovic wrote: >> >> On Mon, Apr 23, 2018 at 1:33 PM, Julien Grall >> wrote: >>> >>> Hi Mirela, >>> >>> >>> On 20/04/18 13:25, Mirela Simonovic wrote: When a CPU is hot-unplugged the maintenance interrupt has to be released in order to free the memory that was allocated when the CPU was hotplugged and interrupt requested. The interrupt was requested using request_irq() which is called from start_secondary-> init_maintenance_interrupt. Signed-off-by: Mirela Simonovic --- CC: Stefano Stabellini CC: Julien Grall --- xen/arch/arm/gic.c| 5 + xen/arch/arm/smpboot.c| 7 +++ xen/include/asm-arm/gic.h | 1 + 3 files changed, 13 insertions(+) diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index 653a815127..e536b99e84 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -431,6 +431,11 @@ void init_maintenance_interrupt(void) "irq-maintenance", NULL); } +void deinit_maintenance_interrupt(void) +{ +release_irq(gic_hw_ops->info->maintenance_irq, NULL); +} + int gic_make_hwdom_dt_node(const struct domain *d, const struct dt_device_node *gic, void *fdt) diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index abc642804f..449fefc77d 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -375,11 +375,18 @@ void __cpu_disable(void) local_irq_disable(); gic_disable_cpu(); + >>> >>> >>> >>> Spurious change. >>> /* Allow any queued timer interrupts to get serviced */ local_irq_enable(); mdelay(1); local_irq_disable(); +/* + * Deinitialize interrupts (this will free the memory that was allocated + * in respective init interrupt functions called from start_secondary) + */ +deinit_maintenance_interrupt(); >>> >>> >>> >>> Can you have a look at using a notifier (see CPU_DIYING)? This would >>> avoid >>> exporting too much new function. >> >> >> I believe releasing of maintenance irq should happen after the dying >> CPU's GIC interface is disabled. > > > Why? The maintenance interrupt will only be fired when running in guest > context. Furthermore, it is initialized after the GIC has been initialized, > so it makes sense to disable before hand. > >> To make such ordering using notifiers I would need to move these lines >> from __cpu_disable into the notifier callback under the CPU_DYING >> case: >> local_irq_disable(); >> gic_disable_cpu(); >> local_irq_enable(); > > > This looks a bit weird. AFAIU, if you disable the CPU interface, then you > should never receive interrupt after. So why would you re-enable them? > > I realize the code in __cpu_disbale do that, but this looks quite wrong to > me. There are no way to receive queued timer interrupt afterwards. > That is what I took as a reference, but I asked myself the same. There is (extremely small, but it exists) time window between disabling irq locally and disabling CPU interface. An interrupt received in that time window would propagate to the CPU but I'm not sure would happen after the GIC CPU interface is disabled and interrupts are locally enabled. That is the only explanation I can come up with, although I believe the answer is nothing. Since you're at ARM you could check this internally. Anyway, since we're taking the notifier approach the timer interrupt would be disabled before the GIC CPU interface, so I believe the mdelay and the surrounding local_irq_enable/disable will not be needed. Please lets do such a cleanup out of this series. >> then below these lines in the callback I would add >> release_irq(gic_hw_ops->info->maintenance_irq, NULL); >> >> This would have to be done because CPU_DYING notifiers execute before >> __cpu_disable(). >> How that sounds? If it's ok, should these changes be split into 2 >> patches (1) notifier based call to gic_disable_cpu + 2) release >> maintenance irq, I believe this is better) or should I merge them? > > I am not sure this is right to do. We want to disable the CPU interface very > late (imagine we need to service interrupt). > This doesn't mean that the gic_disable_cpu can't be done using notifiers, we would just first disable maintenance irq and then gic cpu interface. However, moving gic_disable_cpu in notifier would mean that interrupts should be disabled using notifiers (whose priority is higher than gic notifier's priority) as well. Please lets finalize the discussion and make an agreement on what should be done, I would like to get v3 ASAP. Thanks, Mirela > Cheers, > > -- > Julien Grall
Re: [Xen-devel] [PATCH-for-4.10] adapt SUPPORT.md to match 4.11
On 25/04/18 16:09, Ian Jackson wrote: > Juergen Gross writes ("[PATCH-for-4.10] adapt SUPPORT.md to match 4.11"): >> Some tags have been changed in 4.11. Adapt the 4.10 ones to match in >> order to produce an easier to read support HTML table. > > This does not seem to appply on top of my own 4.10 series. Oh, my bad. I built it on top of staging-4.10. I'll resend as soon as your series has been applied. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH-for-4.10] adapt SUPPORT.md to match 4.11
Juergen Gross writes ("[PATCH-for-4.10] adapt SUPPORT.md to match 4.11"): > Some tags have been changed in 4.11. Adapt the 4.10 ones to match in > order to produce an easier to read support HTML table. This does not seem to appply on top of my own 4.10 series. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"): > Aah, so on ARM we have no dom0 support? No, that is a mistake. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH-for-4.10] adapt SUPPORT.md to match 4.11
Some tags have been changed in 4.11. Adapt the 4.10 ones to match in order to produce an easier to read support HTML table. Signed-off-by: Juergen Gross --- SUPPORT.md | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index cb862b538d..2b0d58feb3 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -74,15 +74,15 @@ No hardware requirements ### x86/HVM -Status: Supported +Status, domU: Supported Fully virtualised guest using hardware virtualisation extensions Requires hardware virtualisation support (Intel VMX / AMD SVM) -### x86/PVH guest +### x86/PVH -Status: Supported +Status, domU: Supported PVH is a next-generation paravirtualized mode designed to take advantage of hardware virtualization support when possible. @@ -90,7 +90,7 @@ During development this was sometimes called HVMLite or PVHv2. Requires hardware virtualisation support (Intel VMX / AMD SVM) -### ARM guest +### ARM Status: Supported -- 2.13.6 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
On 25/04/18 15:54, Ian Jackson wrote: > Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes > (series "C")"): >> On 25/04/18 15:43, George Dunlap wrote: >>> 2. Backport all renames / reorganizations to all supported versions >> >> +1 >> >> As this will only be more specific it is a win. Again above example: >> How would you read the 4.10 PVH support? Is dom0 supported? Its a guest >> after all... > > I think "guest" excludes dom0. dom0 is a domain but not a guest. Aah, so on ARM we have no dom0 support? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"): > On 25/04/18 15:43, George Dunlap wrote: > > 2. Backport all renames / reorganizations to all supported versions > > +1 > > As this will only be more specific it is a win. Again above example: > How would you read the 4.10 PVH support? Is dom0 supported? Its a guest > after all... I think "guest" excludes dom0. dom0 is a domain but not a guest. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
Ian Jackson writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"): > George Dunlap writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes > (series "C")"): > > 2. Backport all renames / reorganizations to all supported versions ... > > I was initially opposed to #2, but I think the idea is growing on > > me. It does mean SUPPORT.md may end up being reorganized or renamed > > in point releases, however. It’s a bit hard for me to tell how > > disruptive that would be. ... > If someone wants to send a patch (on top of my backport series, > please) that renames "PVH guest" to "PVH" in 4.10, and changes > "Status:" to "Status, domU:", to match 4.11 that would be fine by me. Oh, and, if we contemplate doing #2 occasionally then we should ask people to not send mixed patches which do both (i) renaming/reorganising features (ii) changing the support status. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
George Dunlap writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"): > Right, so there are four options: > > 1. Never rename / reorganize SUPPORT.md categories This is clearly unworkable. > 3. Introduce some sort of “mapping” of options so that the table > generator can correctly construct rows I think this would be quite annoying. It would have to be maintained separately, probably in the branch for the next version. It would also make the table generator more complicated and it's quite bad enough already. > 2. Backport all renames / reorganizations to all supported versions > 4. Tolerate duplicate rows for renamed / reorganized features So it has to be one of these. IMO either of these is fine. > I was initially opposed to #2, but I think the idea is growing on > me. It does mean SUPPORT.md may end up being reorganized or renamed > in point releases, however. It’s a bit hard for me to tell how > disruptive that would be. We don't have to make this decision the same way for every feature. If someone wants to send a patch (on top of my backport series, please) that renames "PVH guest" to "PVH" in 4.10, and changes "Status:" to "Status, domU:", to match 4.11 that would be fine by me. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
On 25/04/18 15:43, George Dunlap wrote: > > >> On Apr 25, 2018, at 2:32 PM, Juergen Gross wrote: >> >> On 25/04/18 15:21, Ian Jackson wrote: >>> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes >>> (series "C")"): Not related to these patches, but: SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we want to change those? This might result in a more readable table. e.g.: 4.10: ### x86/PVH guest Status: Supported 4.11: ### x86/PVH Status, domU: Supported Status, dom0: Experimental >>> >>> Indeed. I noticed this when I was backporting my reformatting. >>> I considered changing this but I think TBH that this slight deviation >>> in naming is going to occur occasionally. >> >> The resulting table is rather hard to read, don't you think? >> >> Especially the supported guest types are difficult to compare between >> 4.10 and 4.11. > > Right, so there are four options: > > 1. Never rename / reorganize SUPPORT.md categories As we can see in the example above this won't work very well. > 2. Backport all renames / reorganizations to all supported versions +1 As this will only be more specific it is a win. Again above example: How would you read the 4.10 PVH support? Is dom0 supported? Its a guest after all... > 3. Introduce some sort of “mapping” of options so that the table generator > can correctly construct rows Seems to be rather complex, e.g. in above example > 4. Tolerate duplicate rows for renamed / reorganized features This might grow rather ugly results after some more versions. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Should PV frontend drivers trust the backends?
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Juergen Gross > Sent: 25 April 2018 13:43 > To: xen-devel > Subject: [Xen-devel] Should PV frontend drivers trust the backends? > > This is a followup of a discussion on IRC: > > The main question of the discussion was: "Should frontend drivers > trust their backends not doing malicious actions?" > > This IMO includes: > > 1. The data put by the backend on the ring page(s) is sane and >consistent, meaning that e.g. the response producer index is always >ahead of the consumer index. > > 2. Response data won't be modified by the backend after the producer >index has been incremented signaling the response is valid. > > 3. Response data is sane, e.g. an I/O data length is not larger than >the buffer originally was. > > 4. When a response has been sent all grants belonging to the request >have been unmapped again by the backend, meaning that the frontend >can assume the grants can be removed without conflict. > > Today most frontend drivers (at least in the Linux kernel) seem to > assume all of the above is true (there are some exceptions, but never > for all items): > > - they don't check sanity of ring index values > - they don't copy response data into local memory before looking at it > - they don't verify returned data length (or do so via BUG_ON()) > - they BUG() in case of a conflict when trying to remove a grant > > So the basic question is: should all Linux frontend drivers be modified > in order to be able to tolerate buggy or malicious backends? Or is the > list of trust above fine? > > IMO even in case the frontends do trust the backends to behave sane this > doesn't mean driver domains don't make sense. Driver domains still make > a Xen host more robust as they e.g. protect the host against driver > failures normally leading to a crash of dom0. > I see the general question as being analogous to 'should a Linux device driver trust its hardware' and I think the answer for a general purpose OS like linux is 'yes'. Now, having worked on fault tolerant systems in a past life, there are definitely cases where you want your OS not to implicitly trust its peripheral hardware and hence special device drivers are used. I think the same would apply for virtual machines in situations where a driver domain is not wholly controlled by a host administrator or is not trusted to the same extent as dom0 for other reasons; i.e. they should have specialist frontends. Paul > > Juergen > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/hvm: correct reporting of modified memory under physmap during migration
When global_log_dirty is enabled VRAM modification tracking never worked correctly. The address that is passed to xen_hvm_modified_memory() is not the effective PFN but RAM block address which is not the same for VRAM. We need to make a translation for this address into PFN using physmap. Since there is no way to access physmap properly inside xen_hvm_modified_memory() let's make it a global structure. Signed-off-by: Igor Druzhinin --- hw/i386/xen/xen-hvm.c | 37 +++-- hw/i386/xen/xen-mapcache.c| 2 +- include/sysemu/xen-mapcache.h | 5 ++--- 3 files changed, 22 insertions(+), 22 deletions(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index cb85541..0cc0124 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -89,6 +89,8 @@ typedef struct XenPhysmap { QLIST_ENTRY(XenPhysmap) list; } XenPhysmap; +static QLIST_HEAD(, XenPhysmap) xen_physmap; + typedef struct XenIOState { ioservid_t ioservid; shared_iopage_t *shared_page; @@ -109,7 +111,6 @@ typedef struct XenIOState { MemoryListener memory_listener; MemoryListener io_listener; DeviceListener device_listener; -QLIST_HEAD(, XenPhysmap) physmap; hwaddr free_phys_offset; const XenPhysmap *log_for_dirtybit; @@ -276,14 +277,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr, g_free(pfn_list); } -static XenPhysmap *get_physmapping(XenIOState *state, - hwaddr start_addr, ram_addr_t size) +static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size) { XenPhysmap *physmap = NULL; start_addr &= TARGET_PAGE_MASK; -QLIST_FOREACH(physmap, &state->physmap, list) { +QLIST_FOREACH(physmap, &xen_physmap, list) { if (range_covers_byte(physmap->start_addr, physmap->size, start_addr)) { return physmap; } @@ -291,23 +291,21 @@ static XenPhysmap *get_physmapping(XenIOState *state, return NULL; } -#ifdef XEN_COMPAT_PHYSMAP -static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr, - ram_addr_t size, void *opaque) +static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size) { -hwaddr addr = start_addr & TARGET_PAGE_MASK; -XenIOState *xen_io_state = opaque; +hwaddr addr = phys_offset & TARGET_PAGE_MASK; XenPhysmap *physmap = NULL; -QLIST_FOREACH(physmap, &xen_io_state->physmap, list) { +QLIST_FOREACH(physmap, &xen_physmap, list) { if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) { -return physmap->start_addr; +return physmap->start_addr + (phys_offset - physmap->phys_offset); } } -return start_addr; +return phys_offset; } +#ifdef XEN_COMPAT_PHYSMAP static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap) { char path[80], value[17]; @@ -357,7 +355,7 @@ static int xen_add_to_physmap(XenIOState *state, hwaddr phys_offset = memory_region_get_ram_addr(mr); const char *mr_name; -if (get_physmapping(state, start_addr, size)) { +if (get_physmapping(start_addr, size)) { return 0; } if (size <= 0) { @@ -386,7 +384,7 @@ go_physmap: physmap->name = mr_name; physmap->phys_offset = phys_offset; -QLIST_INSERT_HEAD(&state->physmap, physmap, list); +QLIST_INSERT_HEAD(&xen_physmap, physmap, list); if (runstate_check(RUN_STATE_INMIGRATE)) { /* Now when we have a physmap entry we can replace a dummy mapping with @@ -425,7 +423,7 @@ static int xen_remove_from_physmap(XenIOState *state, XenPhysmap *physmap = NULL; hwaddr phys_offset = 0; -physmap = get_physmapping(state, start_addr, size); +physmap = get_physmapping(start_addr, size); if (physmap == NULL) { return -1; } @@ -593,7 +591,7 @@ static void xen_sync_dirty_bitmap(XenIOState *state, int rc, i, j; const XenPhysmap *physmap = NULL; -physmap = get_physmapping(state, start_addr, size); +physmap = get_physmapping(start_addr, size); if (physmap == NULL) { /* not handled */ return; @@ -1219,7 +1217,7 @@ static void xen_read_physmap(XenIOState *state) xen_domid, entries[i]); physmap->name = xs_read(state->xenstore, 0, path, &len); -QLIST_INSERT_HEAD(&state->physmap, physmap, list); +QLIST_INSERT_HEAD(&xen_physmap, physmap, list); } free(entries); } @@ -1356,7 +1354,6 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory) qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state); state->memory_listener = xen_memory_listener; -QLIST_INIT(&state->physmap); memory_listener_register(&state->memory_listener, &address_space_memory); state->log_for_dirtybit = NULL; @@ -1372,6 +1369,8 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion **r
Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
> On Apr 25, 2018, at 2:32 PM, Juergen Gross wrote: > > On 25/04/18 15:21, Ian Jackson wrote: >> Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes >> (series "C")"): >>> Not related to these patches, but: >>> >>> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we >>> want to change those? This might result in a more readable table. >>> >>> e.g.: >>> >>> 4.10: ### x86/PVH guest >>> Status: Supported >>> >>> 4.11: ### x86/PVH >>> Status, domU: Supported >>> Status, dom0: Experimental >> >> Indeed. I noticed this when I was backporting my reformatting. >> I considered changing this but I think TBH that this slight deviation >> in naming is going to occur occasionally. > > The resulting table is rather hard to read, don't you think? > > Especially the supported guest types are difficult to compare between > 4.10 and 4.11. Right, so there are four options: 1. Never rename / reorganize SUPPORT.md categories 2. Backport all renames / reorganizations to all supported versions 3. Introduce some sort of “mapping” of options so that the table generator can correctly construct rows 4. Tolerate duplicate rows for renamed / reorganized features I was initially opposed to #2, but I think the idea is growing on me. It does mean SUPPORT.md may end up being reorganized or renamed in point releases, however. It’s a bit hard for me to tell how disruptive that would be. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Should PV frontend drivers trust the backends?
On 25/04/18 13:42, Juergen Gross wrote: > This is a followup of a discussion on IRC: > > The main question of the discussion was: "Should frontend drivers > trust their backends not doing malicious actions?" > > This IMO includes: > > 1. The data put by the backend on the ring page(s) is sane and >consistent, meaning that e.g. the response producer index is always >ahead of the consumer index. > > 2. Response data won't be modified by the backend after the producer >index has been incremented signaling the response is valid. > > 3. Response data is sane, e.g. an I/O data length is not larger than >the buffer originally was. > > 4. When a response has been sent all grants belonging to the request >have been unmapped again by the backend, meaning that the frontend >can assume the grants can be removed without conflict. > > Today most frontend drivers (at least in the Linux kernel) seem to > assume all of the above is true (there are some exceptions, but never > for all items): > > - they don't check sanity of ring index values > - they don't copy response data into local memory before looking at it > - they don't verify returned data length (or do so via BUG_ON()) > - they BUG() in case of a conflict when trying to remove a grant > > So the basic question is: should all Linux frontend drivers be modified > in order to be able to tolerate buggy or malicious backends? Or is the > list of trust above fine? > > IMO even in case the frontends do trust the backends to behave sane this > doesn't mean driver domains don't make sense. Driver domains still make > a Xen host more robust as they e.g. protect the host against driver > failures normally leading to a crash of dom0. I think the issue here is that "trust" is actually two different thing here. If we consider "the ring" as an opaque transport layer, then I expect both sides to be resilient to a buggy/malicious other end. I realise this is not currently the case, but I think it should be reasonable to hook either side up to AFL and not have the other side crash. (Declaring the other half insane and transitioning to closed is an entirely reasonable action.) When it comes to the data content served by "the opaque ring", then trust is far more complicated thing. If blkback is serving /, then the default case has little option but to trust the other end. This is clearly how the frontends have been developed. However, non-default cases might include using an encrypted filesystem, at which point the domU isn't in the position of having to trust the driver domain serving its filesystem, and therefore shouldn't be forced into trusting the backend simply because it doesn't protect itself against pitfalls which inherently come from using shared memory interfaces. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.10 10/9] SUPPORT.md: Fix a typo
On 25/04/18 15:23, Ian Jackson wrote: > Reported-by: Juergen Gross > Signed-off-by: Ian Jackson Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
On 25/04/18 15:21, Ian Jackson wrote: > Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes > (series "C")"): >> Not related to these patches, but: >> >> SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we >> want to change those? This might result in a more readable table. >> >> e.g.: >> >> 4.10: ### x86/PVH guest >> Status: Supported >> >> 4.11: ### x86/PVH >> Status, domU: Supported >> Status, dom0: Experimental > > Indeed. I noticed this when I was backporting my reformatting. > I considered changing this but I think TBH that this slight deviation > in naming is going to occur occasionally. The resulting table is rather hard to read, don't you think? Especially the supported guest types are difficult to compare between 4.10 and 4.11. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.10 10/9] SUPPORT.md: Fix a typo
Reported-by: Juergen Gross Signed-off-by: Ian Jackson --- SUPPORT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SUPPORT.md b/SUPPORT.md index 0d2db1f..f85dda8 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -653,7 +653,7 @@ See the section **Blkback** for image formats supported by QEMU. ### x86/Emulated graphics (QEMU): Status, cirrus-vga: Supported -Status, stgvga: Supported +Status, stdvga: Supported ### x86/Emulated audio (QEMU): -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged
Hi, On 25/04/18 14:09, Mirela Simonovic wrote: On Mon, Apr 23, 2018 at 1:33 PM, Julien Grall wrote: Hi Mirela, On 20/04/18 13:25, Mirela Simonovic wrote: When a CPU is hot-unplugged the maintenance interrupt has to be released in order to free the memory that was allocated when the CPU was hotplugged and interrupt requested. The interrupt was requested using request_irq() which is called from start_secondary-> init_maintenance_interrupt. Signed-off-by: Mirela Simonovic --- CC: Stefano Stabellini CC: Julien Grall --- xen/arch/arm/gic.c| 5 + xen/arch/arm/smpboot.c| 7 +++ xen/include/asm-arm/gic.h | 1 + 3 files changed, 13 insertions(+) diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index 653a815127..e536b99e84 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -431,6 +431,11 @@ void init_maintenance_interrupt(void) "irq-maintenance", NULL); } +void deinit_maintenance_interrupt(void) +{ +release_irq(gic_hw_ops->info->maintenance_irq, NULL); +} + int gic_make_hwdom_dt_node(const struct domain *d, const struct dt_device_node *gic, void *fdt) diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index abc642804f..449fefc77d 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -375,11 +375,18 @@ void __cpu_disable(void) local_irq_disable(); gic_disable_cpu(); + Spurious change. /* Allow any queued timer interrupts to get serviced */ local_irq_enable(); mdelay(1); local_irq_disable(); +/* + * Deinitialize interrupts (this will free the memory that was allocated + * in respective init interrupt functions called from start_secondary) + */ +deinit_maintenance_interrupt(); Can you have a look at using a notifier (see CPU_DIYING)? This would avoid exporting too much new function. I believe releasing of maintenance irq should happen after the dying CPU's GIC interface is disabled. Why? The maintenance interrupt will only be fired when running in guest context. Furthermore, it is initialized after the GIC has been initialized, so it makes sense to disable before hand. To make such ordering using notifiers I would need to move these lines from __cpu_disable into the notifier callback under the CPU_DYING case: local_irq_disable(); gic_disable_cpu(); local_irq_enable(); This looks a bit weird. AFAIU, if you disable the CPU interface, then you should never receive interrupt after. So why would you re-enable them? I realize the code in __cpu_disbale do that, but this looks quite wrong to me. There are no way to receive queued timer interrupt afterwards. then below these lines in the callback I would add release_irq(gic_hw_ops->info->maintenance_irq, NULL); This would have to be done because CPU_DYING notifiers execute before __cpu_disable(). How that sounds? If it's ok, should these changes be split into 2 patches (1) notifier based call to gic_disable_cpu + 2) release maintenance irq, I believe this is better) or should I merge them? I am not sure this is right to do. We want to disable the CPU interface very late (imagine we need to service interrupt). Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation
>>> On 25.04.18 at 14:59, wrote: > This is a backport of my two recent series to fix bugs in SUPPORT.md, > format it as part of the published docs, and use relative position of > the `Status' stanza compared to descriptive text to indicate whether > the text is a caveat that deserves a footnote. > > Most of this is uncontroversial and I have run the build and checked > that the resulting index.html is good. > > It would be good if someone could review particularly the way I > resolved the conflicts in the big patch to SUPPORT.md, ie in > [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info > > The result for 4.10's > SUPPORT.md is here: > > https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/SUPPORT.html > > I have also checked that (with the patch I am about to send for > staging's parse-support-md) that this generates a sensible-looking > support matrix. The resulting support matrix can be found here: > https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html > (The hyperlink references for staging are to the live xenbits version; > the references for 4.10 are to the example output file mentioned above.) > > I have squashed the fix to not depend on HTML::TreeBuilder::XPath into > the patch that introduces the dependency. Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
Juergen Gross writes ("Re: [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")"): > Not related to these patches, but: > > SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we > want to change those? This might result in a more readable table. > > e.g.: > > 4.10: ### x86/PVH guest > Status: Supported > > 4.11: ### x86/PVH > Status, domU: Supported > Status, dom0: Experimental Indeed. I noticed this when I was backporting my reformatting. I considered changing this but I think TBH that this slight deviation in naming is going to occur occasionally. There's a paragraph about it in the intro and everything. > 4.10: ### x86/Emulated graphics (QEMU): > Status, stgvga: Supported <- note the typo in "stgvga" > 4.11: ### x86/Emulated graphics (QEMU): > Status, stdvga: Supported This should be fixed. I'll send a followup patch. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.8-testing test] 122385: regressions - FAIL
flight 122385 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122385/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl broken in 122354 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 122161 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 4 host-install(4) broken in 122354 pass in 122385 test-armhf-armhf-xl-rtds 12 guest-start fail in 122354 pass in 122385 test-amd64-i386-xl-qemut-win7-amd64 13 guest-saverestore fail pass in 122354 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail pass in 122354 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 122354 like 122161 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122132 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122161 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122161 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 122161 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122161 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122161 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122161 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122161 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122161 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122161 build-i386-prev 7 xen-build/dist-test fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass build-amd64-prev 7 xen-build/dist-test fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-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 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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-
Re: [Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
On 25/04/18 15:04, Ian Jackson wrote: > I was just testing the results of my backports of the SUPPORT.md > series to 4.10 - just sent, under the Subject line: > [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation > > I found a bug in the support matrix generator. Sadly the bug was not > evident without the backported changes to SUPPORT.md. These two > patches fix this bug. > > Example output can be found here: > https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html > (The hyperlink references for staging are to the live xenbits version; > the references for 4.10 are to the example SUPPORT.html output file > from the 4.10 backport series, as discussed above.) > > For my reference, this was made as follows: > docs/support-matrix-generate -D HEAD > https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html > refs/heads/wip.support-stmt-NN-2 SUPPORT.html 2>&1 >docs/html/t.html |less > rsync -LvP docs/html/{t,SUPPORT}.html > xenbits:public_html/2018/support-matrix-example-C > > Thanks, > Ian. > For the series: Release-acked-by: Juergen Gross Not related to these patches, but: SUPPORT.md of 4.10 seems to have some entries different to 4.11. Do we want to change those? This might result in a more readable table. e.g.: 4.10: ### x86/PVH guest Status: Supported 4.11: ### x86/PVH Status, domU: Supported Status, dom0: Experimental 4.10: ### x86/Emulated graphics (QEMU): Status, stgvga: Supported <- note the typo in "stgvga" 4.11: ### x86/Emulated graphics (QEMU): Status, stdvga: Supported Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged
Hi Julien, On Mon, Apr 23, 2018 at 1:33 PM, Julien Grall wrote: > Hi Mirela, > > > On 20/04/18 13:25, Mirela Simonovic wrote: >> >> When a CPU is hot-unplugged the maintenance interrupt has to be >> released in order to free the memory that was allocated when the CPU >> was hotplugged and interrupt requested. The interrupt was requested >> using request_irq() which is called from start_secondary-> >> init_maintenance_interrupt. >> >> Signed-off-by: Mirela Simonovic >> >> --- >> CC: Stefano Stabellini >> CC: Julien Grall >> --- >> xen/arch/arm/gic.c| 5 + >> xen/arch/arm/smpboot.c| 7 +++ >> xen/include/asm-arm/gic.h | 1 + >> 3 files changed, 13 insertions(+) >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c >> index 653a815127..e536b99e84 100644 >> --- a/xen/arch/arm/gic.c >> +++ b/xen/arch/arm/gic.c >> @@ -431,6 +431,11 @@ void init_maintenance_interrupt(void) >> "irq-maintenance", NULL); >> } >> +void deinit_maintenance_interrupt(void) >> +{ >> +release_irq(gic_hw_ops->info->maintenance_irq, NULL); >> +} >> + >> int gic_make_hwdom_dt_node(const struct domain *d, >> const struct dt_device_node *gic, >> void *fdt) >> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c >> index abc642804f..449fefc77d 100644 >> --- a/xen/arch/arm/smpboot.c >> +++ b/xen/arch/arm/smpboot.c >> @@ -375,11 +375,18 @@ void __cpu_disable(void) >> local_irq_disable(); >> gic_disable_cpu(); >> + > > > Spurious change. > >> /* Allow any queued timer interrupts to get serviced */ >> local_irq_enable(); >> mdelay(1); >> local_irq_disable(); >> +/* >> + * Deinitialize interrupts (this will free the memory that was >> allocated >> + * in respective init interrupt functions called from >> start_secondary) >> + */ >> +deinit_maintenance_interrupt(); > > > Can you have a look at using a notifier (see CPU_DIYING)? This would avoid > exporting too much new function. I believe releasing of maintenance irq should happen after the dying CPU's GIC interface is disabled. To make such ordering using notifiers I would need to move these lines from __cpu_disable into the notifier callback under the CPU_DYING case: local_irq_disable(); gic_disable_cpu(); local_irq_enable(); then below these lines in the callback I would add release_irq(gic_hw_ops->info->maintenance_irq, NULL); This would have to be done because CPU_DYING notifiers execute before __cpu_disable(). How that sounds? If it's ok, should these changes be split into 2 patches (1) notifier based call to gic_disable_cpu + 2) release maintenance irq, I believe this is better) or should I merge them? Thanks, Mirela > >> + >> /* It's now safe to remove this processor from the online map */ >> cpumask_clear_cpu(cpu, &cpu_online_map); >> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h >> index 58b910fe6a..0db42e6cce 100644 >> --- a/xen/include/asm-arm/gic.h >> +++ b/xen/include/asm-arm/gic.h >> @@ -254,6 +254,7 @@ extern void gic_clear_pending_irqs(struct vcpu *v); >> extern int vgic_vcpu_pending_irq(struct vcpu *v); >> extern void init_maintenance_interrupt(void); >> +extern void deinit_maintenance_interrupt(void); >> extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq, >> unsigned int priority); >> extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int >> virtual_irq); >> > > Cheers, > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] docs/parse-support-md: Break out find_current_sectnode
We are going to want to add a call site for this. No functional change. Signed-off-by: Ian Jackson --- docs/parse-support-md | 48 +++- 1 file changed, 27 insertions(+), 21 deletions(-) diff --git a/docs/parse-support-md b/docs/parse-support-md index 218e12b..f0b4c25 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -67,6 +67,32 @@ our $had_feature; #-- parsing -- +sub find_current_sectnode () { +die unless @insections; + +my $sectnode; +my $realsect; +foreach my $s (@insections) { +my $sectlist = $sectnode +? $sectnode->{Children} : $toplevel_sectlist; +my $key = $s->{Key}; +$realsect = $s if $s->{Anchor}; +tie %$sectlist, 'Tie::IxHash' unless tied %$sectlist; +#print STDERR "FIND_CURRENT_SECTNODE ", Dumper($s); +$sectlist->{$key} //= +{ + Children => new_sectlist(), + Headline => $s->{Headline}, + Key => $key, + RealSect => $realsect, + HasCaveat => [], +}; +$sectnode = $sectlist->{$key}; +} +die unless $sectnode; +return $sectnode; +} + sub ri_Header { my ($c) = @_; my ($level, $infos, $hl) = @$c; @@ -100,29 +126,9 @@ sub ri_Para { sub parse_feature_entry ($) { my ($value) = @_; -die unless @insections; $had_feature = 1; - -my $sectnode; -my $realsect; -foreach my $s (@insections) { -my $sectlist = $sectnode -? $sectnode->{Children} : $toplevel_sectlist; -my $key = $s->{Key}; -$realsect = $s if $s->{Anchor}; -tie %$sectlist, 'Tie::IxHash' unless tied %$sectlist; -#print STDERR "PARSE_FEATURE_ENTRY ", Dumper($s); -$sectlist->{$key} //= -{ - Children => new_sectlist(), - Headline => $s->{Headline}, - Key => $key, - RealSect => $realsect, -}; -$sectnode = $sectlist->{$key}; -} -die unless $sectnode; +my $sectnode = find_current_sectnode(); $sectnode->{Status}[$version_index] = $value; } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11 0/2] SUPPORT.md matrix fixes (series "C")
I was just testing the results of my backports of the SUPPORT.md series to 4.10 - just sent, under the Subject line: [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation I found a bug in the support matrix generator. Sadly the bug was not evident without the backported changes to SUPPORT.md. These two patches fix this bug. Example output can be found here: https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html (The hyperlink references for staging are to the live xenbits version; the references for 4.10 are to the example SUPPORT.html output file from the 4.10 backport series, as discussed above.) For my reference, this was made as follows: docs/support-matrix-generate -D HEAD https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html refs/heads/wip.support-stmt-NN-2 SUPPORT.html 2>&1 >docs/html/t.html |less rsync -LvP docs/html/{t,SUPPORT}.html xenbits:public_html/2018/support-matrix-example-C Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] docs/parse-support-md: Do caveats properly (!)
Each document has its own objects in @insections. Only the first RealSect encountered ends up in the main $toplevel_sectlist tree. This means that trying to unify the Caveats information for all version in the RealSect (the $insection) does not work. The caveats for all versions that aren't the first one where this section was seen end up in the @insections array during parsing of that version, but not recorded in the main tree. The result was that footnotes would only appear in the output for versions which were the most recent version where that feature row or category appeared. The other footnotes would be lost. Instead, store HasCaveat in the sectnode. That means ri_Para needs to find the sectnode. Signed-off-by: Ian Jackson --- docs/parse-support-md | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/parse-support-md b/docs/parse-support-md index f0b4c25..1c82f56 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -33,8 +33,8 @@ our $toplevel_sectlist = new_sectlist(); # $sectlist->{KEY}{Status}[VI] = absent or markdown content # $sectlist->{KEY}{Children} = a further $sectlist # $sectlist->{KEY}{Key} = KEY +# $sectlist->{KEY}{HasCaveat}[VI] = trueish iff other in a Para # $sectlist->{KEY}{RealSect} = containing real section in @insections, so -# $sectlist->{KEY}{RealSect}{HasCaveat}[VI] = trueish iff other in a Para # $sectlist->{KEY}{RealSect}{HasDescription} = VI for some Emph in Para # $sectlist->{KEY}{RealSect}{Anchor} = value for < id="" > in the pandoc html # A $sectnode represents a single section from the original markdown @@ -58,7 +58,6 @@ our @insections; # $insections[]{Headline} = markdown content # these next are only defined for real sections, not Status elements # $insections[]{Anchor} = string -# $insections[]{HasCaveat} = array, $sectlist->{HasCaveat} will refer to this # $insections[]{HasDescription} VI, likewise our $had_unknown; @@ -106,7 +105,6 @@ sub ri_Header { Key => $id, Anchor => $id, Headline => $hl, - HasCaveat => [], HasDescription => undef, }; #print STDERR Dumper(\@insections); @@ -116,9 +114,12 @@ sub ri_Header { sub ri_Para { return unless @insections; my $insection = $insections[$#insections]; +#print STDERR "ri_Para $version_index $had_feature ". +#$insection->{HasCaveat}." $insection->{Key}\n"; if ($had_feature) { -$insection->{HasCaveat}[$version_index] = 1; +my $sectnode = find_current_sectnode(); +$sectnode->{HasCaveat}[$version_index] = 1; } else { $insection->{HasDescription} //= $version_index; } @@ -397,7 +398,7 @@ sub write_output_row ($) { my $nextcell = ''; if (!defined $colspan) { # first row of this RealSect $colspan= ' colspan="2"'; -if ($sectnode->{RealSect}{HasCaveat}[$i] && $st +if ($sectnode->{HasCaveat}[$i] && $st && $sectnode->{RealSect}{Anchor}) { my $rows = $sectnode->{RealSect}{OwnRows}; $nextcell = 'https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] x86/cpu: Add supports for zhaoxin x86 platform
From: DavidWang Zhaoxin is a x86 IC designer. Its SOC products support both CPU virtualization and I/O virtualization, which are compatible with Intel VMX and VT-d respectively. Zhaoxin has 'Shanghai' CPU vendor ID. Signed-off-by: DavidWang --- xen/arch/x86/cpu/Makefile | 1 + xen/arch/x86/cpu/common.c | 1 + xen/arch/x86/cpu/intel_cacheinfo.c | 2 +- xen/arch/x86/cpu/shanghai.c| 90 ++ xen/include/asm-x86/cpufeature.h | 1 + xen/include/asm-x86/iommu.h| 2 + xen/include/asm-x86/setup.h| 1 + xen/include/asm-x86/x86-vendors.h | 3 +- 8 files changed, 99 insertions(+), 2 deletions(-) create mode 100644 xen/arch/x86/cpu/shanghai.c diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile index 74f23ae..34a01ca 100644 --- a/xen/arch/x86/cpu/Makefile +++ b/xen/arch/x86/cpu/Makefile @@ -7,4 +7,5 @@ obj-y += common.o obj-y += intel.o obj-y += intel_cacheinfo.o obj-y += mwait-idle.o +obj-y += shanghai.o obj-y += vpmu.o vpmu_amd.o vpmu_intel.o diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index 0a452ae..02863c9 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -709,6 +709,7 @@ void __init early_cpu_init(void) intel_cpu_init(); amd_init_cpu(); centaur_init_cpu(); + shanghai_init_cpu(); early_cpu_detect(); } diff --git a/xen/arch/x86/cpu/intel_cacheinfo.c b/xen/arch/x86/cpu/intel_cacheinfo.c index 101e297..a3aec13 100644 --- a/xen/arch/x86/cpu/intel_cacheinfo.c +++ b/xen/arch/x86/cpu/intel_cacheinfo.c @@ -103,7 +103,7 @@ int cpuid4_cache_lookup(int index, struct cpuid4_info *this_leaf) return 0; } -static int find_num_cache_leaves(void) +int find_num_cache_leaves(void) { unsigned inteax, ebx, ecx, edx; union _cpuid4_leaf_eax cache_eax; diff --git a/xen/arch/x86/cpu/shanghai.c b/xen/arch/x86/cpu/shanghai.c new file mode 100644 index 000..ac12ba3 --- /dev/null +++ b/xen/arch/x86/cpu/shanghai.c @@ -0,0 +1,90 @@ +#include +#include +#include +#include "cpu.h" + +void init_shanghai_cache(struct cpuinfo_x86 *c) +{ + unsigned int i = 0, l1d = 0, l1i = 0, l2 = 0, l3 = 0; +struct cpuid4_info leaf; + static bool is_initialized = false; + static unsigned int cache_leaves = 0; + + if ( (!is_initialized) && (c->cpuid_level > 0x0003) ) +{ + /* Init cache_leaves from boot CPU */ + cache_leaves = find_num_cache_leaves(); + is_initialized = true; + } + + /* Use cpuid:0x0004 to find the cache details */ + for (i = 0; i < cache_leaves; i++) +{ + if( c->cpuid_level <= 0x0003 ) + break; + + if ( !cpuid4_cache_lookup(i, &leaf) ) +{ + switch( leaf.eax.split.level ) + { + case 1: + if ( leaf.eax.split.type == CACHE_TYPE_DATA ) + l1d = leaf.size/1024; + else if ( leaf.eax.split.type == CACHE_TYPE_INST ) + l1i = leaf.size/1024; + break; + case 2: + l2 = leaf.size/1024; + break; + case 3: + l3 = leaf.size/1024; + break; + default: + break; + } + } + } + + if ( opt_cpu_info ) + { + if ( l1i ) + printk("CPU: L1 I cache: %dK", l1i); + + if ( l1d ) + printk(", L1 D cache: %dK\n", l1d); + else + printk("\n"); + + if ( l2 ) + printk("CPU: L2 cache: %dK\n", l2); + + if ( l3 ) + printk("CPU: L3 cache: %dK\n", l3); + } + + c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i + l1d)); +} + +static void init_shanghai(struct cpuinfo_x86 *c) +{ + if ( cpu_has(c, X86_FEATURE_ITSC) ) + { + __set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); + __set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability); + __set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability); + } + + init_shanghai_cache(c); +} + +static const struct cpu_dev shanghai_cpu_dev = { + .c_vendor = " Shang", + .c_ident= {" Shanghai "}, + .c_init = init_shanghai, +}; + +int __init shanghai_init_cpu(void) +{ + cpu_devs[X86_VENDOR_SHANGHAI] = &shanghai_cpu_dev; + return 0; +} diff --git a/xen/include/asm-x86/cpu
[Xen-devel] [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info
This turns all the things which were treated as caveats, but which don't need to be footnoted in the matrix, into descriptions. For the benefit of the support matrix generator, this patch (or a version of it) should be backported to 4.10. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross (cherry picked from commit 67b46e14cb943e27134e9c6d7b41b27bdd8c6ae9) Merge conflicts resolved: - x86/HVM: 4.11 talks about "Status, domU" - x86/PVH: 4.11 mentions domO so heading is different too - ARM: Heading in 4.11 says just "ARM", in 4.10 "ARM guest" Signed-off-by: Ian Jackson --- SUPPORT.md | 211 - 1 file changed, 110 insertions(+), 101 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index 201e5a3..3429afb 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -58,44 +58,44 @@ for the definitions of the support status levels etc. ### ARM/GICv3 ITS -Status: Experimental - Extension to the GICv3 interrupt controller to support MSI. +Status: Experimental + ## Guest Type ### x86/PV -Status: Supported - Traditional Xen PV guest No hardware requirements -### x86/HVM - Status: Supported +### x86/HVM + Fully virtualised guest using hardware virtualisation extensions Requires hardware virtualisation support (Intel VMX / AMD SVM) -### x86/PVH guest - Status: Supported +### x86/PVH guest + PVH is a next-generation paravirtualized mode designed to take advantage of hardware virtualization support when possible. During development this was sometimes called HVMLite or PVHv2. Requires hardware virtualisation support (Intel VMX / AMD SVM) -### ARM guest - Status: Supported +### ARM guest + ARM only has one guest type at the moment +Status: Supported + ## Toolstack ### xl @@ -104,12 +104,12 @@ ARM only has one guest type at the moment ### Direct-boot kernel image format +Format which the toolstack accepts for direct-boot kernels + Supported, x86: bzImage, ELF Supported, ARM32: zImage Supported, ARM64: Image -Format which the toolstack accepts for direct-boot kernels - ### Dom0 init support for xl Status, SysV: Supported @@ -118,10 +118,10 @@ Format which the toolstack accepts for direct-boot kernels ### JSON output support for xl -Status: Experimental - Output of information in machine-parseable JSON format +Status: Experimental + ### Open vSwitch integration for xl Status, Linux: Supported @@ -154,17 +154,18 @@ Output of information in machine-parseable JSON format ### Hypervisor 'debug keys' -Status: Supported, not security supported - These are functions triggered either from the host serial console, or via the xl 'debug-keys' command, which cause Xen to dump various hypervisor state to the console. +Status: Supported, not security supported + ### Hypervisor synchronous console output (sync_console) +Xen command-line flag to force synchronous console output. + Status: Supported, not security supported -Xen command-line flag to force synchronous console output. Useful for debugging, but not suitable for production environments due to incurred overhead. @@ -176,56 +177,54 @@ Debugger to debug ELF guests ### Soft-reset for PV guests -Status: Supported - Soft-reset allows a new kernel to start 'from scratch' with a fresh VM state, but with all the memory from the previous state of the VM intact. This is primarily designed to allow "crash kernels", which can do core dumps of memory to help with debugging in the event of a crash. -### xentrace +Status: Supported -Status, x86: Supported +### xentrace Tool to capture Xen trace buffer data -### gcov +Status, x86: Supported -Status: Supported, Not security supported +### gcov Export hypervisor coverage data suitable for analysis by gcov or lcov. +Status: Supported, Not security supported + ## Memory Management ### Dynamic memory control -Status: Supported - Allows a guest to add or remove memory after boot-time. This is typically done by a guest kernel agent known as a "balloon driver". -### Populate-on-demand memory +Status: Supported -Status, x86 HVM: Supported +### Populate-on-demand memory This is a mechanism that allows normal operating systems with only a balloon driver to boot with memory < maxmem. -### Memory Sharing +Status, x86 HVM: Supported -Status, x86 HVM: Expermental +### Memory Sharing Allow sharing of identical pages between guests -### Memory Paging +Status, x86 HVM: Expermental -Status, x86 HVM: Experimenal +### Memory Paging Allow pages belonging to guests to be paged to disk -### Transcendent Memory +Status, x86 HVM: Experimenal -Status: Experimental +### Transcendent Memory Transcendent Memory (tmem) allows the creation of hypervisor memory pools which guests can use to store memory @@ -233,96 +232,100 @@ rathe
[Xen-devel] [PATCH 9/9] SUPPORT.md: Document the new text ordering rule
Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross (cherry picked from commit 2e9aeb6f40eaf13c20231ec91301be74a19152ad) --- SUPPORT.md | 5 + 1 file changed, 5 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index 3429afb..0d2db1f 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -712,6 +712,11 @@ The file is in markdown format. The machine-readable fragments are markdown literals containing RFC-822-like (deb822-like) data. +In each case, descriptions which expand on the name of a feature as +provided in the section heading, precede the Status indications. +Any paragraphs which follow the Status indication are caveats or +qualifications of the information provided in Status fields. + ## Keys found in the Feature Support subsections ### Status -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 6/9] docs/Makefile: Introduce GENERATE_PANDOC_RULE_RAW
We are going to want to format SUPPORT.md which does not match the filename patterns in docs/. So provide a way to make an ad-hoc rule using pandoc with the standard options. No functional change in this patch. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: Lars Kurth (cherry picked from commit 539f93945cad06fd90784716be1dc8d2624b6f66) --- docs/Makefile | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/Makefile b/docs/Makefile index 6743fa3..d82463f 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -237,17 +237,18 @@ txt/%.txt: %.markdown $(INSTALL_DATA) $< $@ # Metarule for generating pandoc rules. -define GENERATE_PANDOC_RULE -# $(1) is the target documentation format. $(2) is the source format. - -$(1)/%.$(1): %.$(2) +define GENERATE_PANDOC_RULE_RAW +$(1): $(2) ifneq ($(PANDOC),) @$(INSTALL_DIR) $$(@D) $(PANDOC) --number-sections --toc --standalone $$< --output $$@ else @echo "pandoc not installed; skipping $$@" endif - +endef +define GENERATE_PANDOC_RULE +# $(1) is the target documentation format. $(2) is the source format. +$(call GENERATE_PANDOC_RULE_RAW,$(1)/%.$(1),%.$(2)) endef $(eval $(call GENERATE_PANDOC_RULE,pdf,pandoc)) # pdf/%.pdf: %.pandoc $(eval $(call GENERATE_PANDOC_RULE,txt,pandoc)) # txt/%.txt: %.pandoc -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/9] SUPPORT.md: Syntax: Fix a typo "States"
Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: George Dunlap Acked-by: Lars Kurth (cherry picked from commit ebbd0299089a698c39d4ced966df5831944b4305) --- SUPPORT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SUPPORT.md b/SUPPORT.md index 4f69ed6..92c6a2c 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -357,7 +357,7 @@ Guest-side driver capable of speaking the Xen PV block protocol Status, FreeBSD: Supported, Security support external Status, NetBSD: Supported, Security support external Status, OpenBSD: Supported, Security support external -States, Windows: Supported +Status, Windows: Supported Guest-side driver capable of speaking the Xen PV networking protocol -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/9] SUPPORT.md: Syntax: Fix some bullet lists
Continuations of bullet list items must be indented by exactly 4 spaces (according to pandoc_markdown(5) on Debian jessie). This is most easily achieved by making the bullet list items have two spaces before the `*'. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: George Dunlap Acked-by: Lars Kurth (cherry picked from commit 01143b6273bc35a35afde154b2bb2415941bea89) --- SUPPORT.md | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index cb862b5..4f69ed6 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -770,40 +770,40 @@ What is the risk of it exhibiting bugs? General answers to the above: - * **Here be dragons** + * **Here be dragons** - Pretty likely to still crash / fail to work. - Not recommended unless you like life on the bleeding edge. +Pretty likely to still crash / fail to work. +Not recommended unless you like life on the bleeding edge. - * **Quirky** + * **Quirky** - Mostly works but may have odd behavior here and there. - Recommended for playing around or for non-production use cases. +Mostly works but may have odd behavior here and there. +Recommended for playing around or for non-production use cases. - * **Normal** + * **Normal** - Ready for production use +Ready for production use ### Interface stability If I build a system based on the current interfaces, will they still work when I upgrade to the next version? - * **Not stable** + * **Not stable** - Interface is still in the early stages and - still fairly likely to be broken in future updates. +Interface is still in the early stages and +still fairly likely to be broken in future updates. - * **Provisionally stable** + * **Provisionally stable** - We're not yet promising backwards compatibility, - but we think this is probably the final form of the interface. - It may still require some tweaks. +We're not yet promising backwards compatibility, +but we think this is probably the final form of the interface. +It may still require some tweaks. - * **Stable** + * **Stable** - We will try very hard to avoid breaking backwards compatibility, - and to fix any regressions that are reported. +We will try very hard to avoid breaking backwards compatibility, +and to fix any regressions that are reported. ### Security supported -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/9] docs/gen-html-index: Extract titles from HTML documents
Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: Lars Kurth (cherry picked from commit 7782db9260d4c6499458de4e8d9866bc0427e143) [ Combined with: ] docs/gen-html-index: Make HTML::TreeBuilder::XPath optional again 7782db9260d4 "docs/gen-html-index: Extract titles from HTML documents" requires HTML::TreeBuilder::XPath. This is sadly not as widely available as I had hoped. Work around this problem by making the use of this module optional: instead of `use'ing at the toplevel, we `require' it in the eval. If it's not present, then the title is simply not extracted and the filename is used as before, which is tolerable. Also add some debugging. Reported-by: Doug Goldstein Signed-off-by: Ian Jackson Reviewed-by: Doug Goldstein Tested-by: Doug Goldstein (cherry picked from commit 16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5) --- docs/gen-html-index | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/docs/gen-html-index b/docs/gen-html-index index e9792bf..410674e 100644 --- a/docs/gen-html-index +++ b/docs/gen-html-index @@ -20,8 +20,10 @@ our @dirs; our %index; our $outdir; +our $debug; -GetOptions("i=s" => sub { read_index(@_);} ) +GetOptions("i=s" => sub { read_index(@_);}, + "D" => \$debug) or die; ($outdir,@docs) = @ARGV; @@ -64,6 +66,20 @@ sub make_linktext ($) { return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,; $l =~ s/.(?:html|txt)$//g; return $index{$l} if exists $index{$l}; + +my $from_html; +eval { +require HTML::TreeBuilder::XPath; +my $tree = new HTML::TreeBuilder::XPath; +my $f = "$outdir/$l.html"; +open F, '<', $f or die "$l $f $!"; +$tree->parse_file(\*F) or die; +close F; +$from_html = $tree->findvalue("/html/head/title"); +}; +print "$l: get title: $@" if $@ && $debug; +return $from_html if $from_html; + return basename($l); } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 7/9] docs/Makefile: Format SUPPORT.md into the toplevel
Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: Lars Kurth (cherry picked from commit f246d42665a6023c248c5b3e374da5691df63f6f) --- docs/Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/Makefile b/docs/Makefile index d82463f..b300bb6 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -28,7 +28,8 @@ DOC_MAN7 := $(patsubst man/%.pod.7,man7/%.7,$(MAN7SRC-y)) \ $(patsubst man/%.markdown.7,man7/%.7,$(MAN7SRC-y)) DOC_MAN8 := $(patsubst man/%.pod.8,man8/%.8,$(MAN8SRC-y)) \ $(patsubst man/%.markdown.8,man8/%.8,$(MAN8SRC-y)) -DOC_HTML := $(patsubst %.markdown,html/%.html,$(MARKDOWNSRC-y)) \ +DOC_HTML := html/SUPPORT.html \ +$(patsubst %.markdown,html/%.html,$(MARKDOWNSRC-y)) \ $(patsubst %.pandoc,html/%.html,$(PANDOCSRC-y)) \ $(patsubst man/%.markdown.1,html/man/%.1.html,$(MAN1SRC-y)) \ $(patsubst man/%.markdown.5,html/man/%.5.html,$(MAN5SRC-y)) \ @@ -255,6 +256,8 @@ $(eval $(call GENERATE_PANDOC_RULE,txt,pandoc)) # txt/%.txt: %.pandoc $(eval $(call GENERATE_PANDOC_RULE,html,pandoc)) # html/%.html: %.pandoc $(eval $(call GENERATE_PANDOC_RULE,pdf,markdown)) # pdf/%.pdf: %.markdown +$(eval $(call GENERATE_PANDOC_RULE_RAW,html/SUPPORT.html,$(XEN_ROOT)/SUPPORT.md)) # pdf/%.pdf: %.markdown + ifeq (,$(findstring clean,$(MAKECMDGOALS))) $(XEN_ROOT)/config/Docs.mk: $(error You have to run ./configure before building docs) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5/9] docs/gen-html-index: Support documents at the toplevel
There are none yet. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: Lars Kurth (cherry picked from commit 1e4a834a8f5d970e68cff6d9c16710194bc46537) --- docs/gen-html-index | 4 1 file changed, 4 insertions(+) diff --git a/docs/gen-html-index b/docs/gen-html-index index 410674e..4fad6db 100644 --- a/docs/gen-html-index +++ b/docs/gen-html-index @@ -140,6 +140,10 @@ sub dirs($) return @dirs; } +foreach my $of (grep { !m{/} } @docs) { +$top .= make_link($of,''); +} + foreach my $od (sort { $a cmp $b } uniq map { dirs($_) } @docs) { my @d = (grep /^\Q$od\E/, @docs); if ( @d == 1 and $d[0] eq "$od/index.html" ) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/9] SUPPORT.md: Syntax: Provide a title rather than a spurious empty section
This commits (more or less) this file to be processed with pandoc, rather than other markdown processors. There is, unfortunately, no widely-accepted way to declare a title for the document. I tested feeding the document to markdown(1) on Debian jessie and it reproduced the % line as if it were simple text. I guess many other markdown processors will do something similarly tolerable. My internet searches did not discover a markdown processor that used lines starting with % for something else. Signed-off-by: Ian Jackson Release-acked-by: Juergen Gross Acked-by: George Dunlap Acked-by: Lars Kurth (cherry picked from commit a569c6f815fb6a18c64b8f122f5e2bbecd32) --- SUPPORT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SUPPORT.md b/SUPPORT.md index 92c6a2c..201e5a3 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -1,4 +1,4 @@ -# Support statement for this release +% Support statement for this release This document describes the support status and in particular the security support status of the Xen branch -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.10 0/9] SUPPORT.md backports to support matrix generation
This is a backport of my two recent series to fix bugs in SUPPORT.md, format it as part of the published docs, and use relative position of the `Status' stanza compared to descriptive text to indicate whether the text is a caveat that deserves a footnote. Most of this is uncontroversial and I have run the build and checked that the resulting index.html is good. It would be good if someone could review particularly the way I resolved the conflicts in the big patch to SUPPORT.md, ie in [PATCH 8/9] SUPPORT.md: Move descriptions up before Status info The result for 4.10's SUPPORT.md is here: https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/SUPPORT.html I have also checked that (with the patch I am about to send for staging's parse-support-md) that this generates a sensible-looking support matrix. The resulting support matrix can be found here: https://xenbits.xen.org/people/iwj/2018/support-matrix-example-C/t.html (The hyperlink references for staging are to the live xenbits version; the references for 4.10 are to the example output file mentioned above.) I have squashed the fix to not depend on HTML::TreeBuilder::XPath into the patch that introduces the dependency. For my reference, this was made as follows: docs/support-matrix-generate -D HEAD https://xenbits.xen.org/docs/unstable-staging/SUPPORT.html refs/heads/wip.support-stmt-NN-2 SUPPORT.html 2>&1 >docs/html/t.html |less rsync -LvP docs/html/{t,SUPPORT}.html xenbits:public_html/2018/support-matrix-example-C Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: Do not reserve a crash kernel region if booted on Xen PV
On 25/04/18 12:08, Petr Tesarik wrote: > Xen PV domains cannot shut down and start a crash kernel. Instead, > the crashing kernel makes a SCHEDOP_shutdown hypercall with the > reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in > arch/x86/xen/enlighten_pv.c. > > A crash kernel reservation is merely a waste of RAM in this case. It > may also confuse users of kexec_load(2) and/or kexec_file_load(2). > When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH, > respectively, these syscalls return success, which is technically > correct, but the crash kexec image will never be actually used. > > Signed-off-by: Petr Tesarik Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-squeeze test] 74641: tolerable FAIL
flight 74641 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74641/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 74632 test-amd64-i386-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 74632 test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 74632 test-amd64-i386-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 74632 baseline version: flight 74632 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-squeeze-netboot-pygrubfail test-amd64-i386-amd64-squeeze-netboot-pygrub fail test-amd64-amd64-i386-squeeze-netboot-pygrub fail test-amd64-i386-i386-squeeze-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Should PV frontend drivers trust the backends?
This is a followup of a discussion on IRC: The main question of the discussion was: "Should frontend drivers trust their backends not doing malicious actions?" This IMO includes: 1. The data put by the backend on the ring page(s) is sane and consistent, meaning that e.g. the response producer index is always ahead of the consumer index. 2. Response data won't be modified by the backend after the producer index has been incremented signaling the response is valid. 3. Response data is sane, e.g. an I/O data length is not larger than the buffer originally was. 4. When a response has been sent all grants belonging to the request have been unmapped again by the backend, meaning that the frontend can assume the grants can be removed without conflict. Today most frontend drivers (at least in the Linux kernel) seem to assume all of the above is true (there are some exceptions, but never for all items): - they don't check sanity of ring index values - they don't copy response data into local memory before looking at it - they don't verify returned data length (or do so via BUG_ON()) - they BUG() in case of a conflict when trying to remove a grant So the basic question is: should all Linux frontend drivers be modified in order to be able to tolerate buggy or malicious backends? Or is the list of trust above fine? IMO even in case the frontends do trust the backends to behave sane this doesn't mean driver domains don't make sense. Driver domains still make a Xen host more robust as they e.g. protect the host against driver failures normally leading to a crash of dom0. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 259 - x86: PV guest may crash Xen with XPTI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-259 version 2 x86: PV guest may crash Xen with XPTI UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The workaround for the Meltdown vulnerability (XSA-254) failed to deal with an error code path connecting the INT 80 handling with general exception handling. This results in an unconditional write attempt of the value zero to an address near 2^64, in cases where a PV guest has no handler installed for INT 80 on one of its vCPU-s. IMPACT == A malicious or buggy guest may cause a hypervisor crash, resulting in a Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == All Xen versions which the XSA-254 fixes were applied to are vulnerable. Only x86 systems are vulnerable. ARM systems are not vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH and HVM guests cannot exploit the vulnerability. MITIGATION == Running only PVH or HVM guests avoids the vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa259.patch xen-unstable, Xen 4.10.x ... xen 4.7.x xsa259-4.6.patch Xen 4.6.x $ sha256sum xsa259* 5c14a90af066c952974324b361e2a428c280f876b854f0c85a78e8579054a4d1 xsa259.meta ff2efb5eb2502ded988d0aa15351030a15494a9e2223eafbb88377a8e4d39dcb xsa259.patch c40bc8802077cf73f8393fb50574b7c7efbc4d127e202b0ebd757d34aa07aac3 xsa259-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 iQEcBAEBCAAGBQJa4G58AAoJEIP+FMlX6CvZrqIH+QFfC5NOoFhVZAChTU0WQ7U6 UwP7yEyLeY15VrGb4YvwzKhvTNwsRRiYTbTNB/QjAkrUkMRhBiUIz7mQqBl0Vc/N 4zblt+YNdDMjhCllTjvtYU6OJzbsqvEBByB4mFrz6fxfZiuXIbOnMUOxLHRRdXLR 6JR8+4RrheKNl9DF6lmLj50d3G/fKrNLY9id8VcDG1TGIB6E1CbJ6gibw7FiYDSq PETa5O1szo2FO2yY+xcMzzGLHv+oVeKZnmuq9KYtP7Q+G823Twz1RE6rTBEjwhs9 sDGUlgZ48QVfSzer10syzyeX0p9hLHyKhlJnCrmCiywvKq68/uVexZFNcOKRPtE= =n+01 -END PGP SIGNATURE- xsa259.meta Description: Binary data xsa259.patch Description: Binary data xsa259-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Security Advisory 258 - Information leak via crafted user-supplied CDROM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-258 version 2 Information leak via crafted user-supplied CDROM UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = QEMU handles many different file formats for virtual disks (e.g., raw, qcow2, vhd, &c). Some of these formats are "snapshots" that specify "patches" to an alternate disk image, whose filename is included in the snapshot file. When qemu is given a disk but the type is not specified, it attempts to guess the file format by reading it. If a disk image is intended to be 'raw', but the image is entirely controlled by an attacker, the attacker could write a header to the image, describing one of these "snapshot" formats, and pointing to an arbitrary file as the "backing" file. When attaching disks via command-line parameters at boot time (including both "normal" disks and CDROMs), libxl specifies the format; however, when inserting a CDROM live via QMP, the format was not specified. IMPACT == An attacker supplying a crafted CDROM image can read any file (or device node) on the dom0 filesystem with the permissions of the qemu devicemodel process. (The virtual CDROM device is read-only, so no data can be written.) VULNERABLE SYSTEMS == Only x86 HVM guests with a virtual CDROM device are affected. ARM guests, x86 PV guests, x86 PVH guests, and x86 HVM guests without a virtual CDROM device are not affected. Only systems with qemu running in dom0 are affected; systems running stub domains are not affected. Only systems using qemu-xen (aka "qemu-upstream" are affected; systems running qemu-xen-traditional are not affected. Only systems in which an attacker can provide a raw CDROM image, and cause that image to be virtually inserted while the guest is running, are affected. Systems which only have host administrator-supplied CDROM images, or systems which allow images to be added only at boot time, are not affected. MITIGATION == One workaround is to "wrap" the guest-supplied image in a specific format; i.e., accept a raw image from the untrusted user, and convert it into qcow2 format; for example: qemu-img convert -f raw -O qcow2 untrusted.raw wrapped.qcow2 WARNING: Make sure to specify `-f raw` if you do this, or qemu will "guess" the format of "untrusted.raw" (which the attacker may have crafted to look like a qcow2 snapshot image with an alternativee base). Another workaround is to allow guests to only change CDROMs at boot time, not while the guest is running. CREDITS === This issue was discovered by Anthony Perard of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa258.patch xen-unstable, Xen 4.10.x, Xen 4.9.x xsa258-4.8.patch Xen 4.8.x, Xen 4.7.x xsa258-4.6.patch Xen 4.6.x $ sha256sum xsa258* 2c35a77eeca5579b5c32517c5ba511c836fa70f8b824ca8883fc6e1a7e608405 xsa258.meta 7e8014deae4fa19464fe6570d0719f8f0d7730dd153d58b2fa38b0cd5ed2e459 xsa258.patch 2c58060a42dafbf65563941dd8c737732124b49eb47007cc60f647553227f557 xsa258-4.6.patch ebba2f1f084249cd1e1c2f59e338412161884c31c83dbba03fc1e10bf4ba57a1 xsa258-4.8.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or the "wrap" mitigation described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However, deploying the "only allow guests to change CDROMs at boot time" is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because it may give attackers a hint of where to look for the vulnerability. Deployment of this mitigation is permitted only AFTER the embargo ends. Additionally, 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 iQEcBAEBCAAGBQJa4G55AAoJEIP+FMlX6CvZHjYIAJEtdHT5yPyQuSjh8ATOYN/s DrpUSw65EvvgbuGJTcmWZMc335AvyoMDtYVtk+Ouy5dMlfuUXcwjimoLWC6FfEDg aJ19puvjVaA8JcRzimlWQjru8Eqyso1+uNjuvsv1RCSkhN6qGBGCx6xlyWJL0tGk H
[Xen-devel] [PATCH v2] x86/microcode: Synchronize late microcode loading
From: Gao Chao This patch ports microcode improvement patches from linux kernel. Before you read any further: the early loading method is still the preferred one and you should always do that. The following patch is improving the late loading mechanism for long running jobs and cloud use cases. Gather all cores and serialize the microcode update on them by doing it one-by-one to make the late update process as reliable as possible and avoid potential issues caused by the microcode update. This patch is also in accord with Andrew's suggestion, "Rendezvous all online cpus in an IPI to apply the patch, and keep the processors in until all have completed the patch.", in [1]. [1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_updates Signed-off-by: Chao Gao Tested-by: Chao Gao [linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff] [linux commit: bb8c13d61a629276a162c1d2b1a20a815cbcfbb7] Cc: Kevin Tian Cc: Jun Nakajima Cc: Ashok Raj Cc: Borislav Petkov Cc: Thomas Gleixner Cc: Andrew Cooper Cc: Jan Beulich --- Resend for I forgot to send it to maillist. v2: - Reduce the timeout from 1s to 30ms - update microcode with better parallelism; only one logical thread of each core tries to take lock and do the update. - remove 'error' field from struct microcode_info - correct coding style issues --- xen/arch/x86/microcode.c | 117 --- 1 file changed, 91 insertions(+), 26 deletions(-) diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c index 4163f50..fddce1e 100644 --- a/xen/arch/x86/microcode.c +++ b/xen/arch/x86/microcode.c @@ -22,6 +22,7 @@ */ #include +#include #include #include #include @@ -30,15 +31,21 @@ #include #include #include +#include #include #include #include +#include +#include #include #include #include #include +/* By default, wait for 3us */ +#define MICROCODE_DEFAULT_TIMEOUT 3 + static module_t __initdata ucode_mod; static signed int __initdata ucode_mod_idx; static bool_t __initdata ucode_mod_forced; @@ -187,9 +194,9 @@ static DEFINE_SPINLOCK(microcode_mutex); DEFINE_PER_CPU(struct ucode_cpu_info, ucode_cpu_info); struct microcode_info { -unsigned int cpu; +cpumask_t cpus; +atomic_t cpu_in, cpu_out; uint32_t buffer_size; -int error; char buffer[1]; }; @@ -281,24 +288,56 @@ static int microcode_update_cpu(const void *buf, size_t size) return err; } -static long do_microcode_update(void *_info) +/* Wait for all CPUs to rendezvous with a timeout (us) */ +static int wait_for_cpus(atomic_t *cnt, int timeout) { -struct microcode_info *info = _info; -int error; +unsigned int cpus = num_online_cpus(); -BUG_ON(info->cpu != smp_processor_id()); +atomic_inc(cnt); -error = microcode_update_cpu(info->buffer, info->buffer_size); -if ( error ) -info->error = error; +while ( atomic_read(cnt) != cpus ) +{ +if ( timeout <= 0 ) +{ +printk("Timeout when waiting for CPUs calling in\n"); +return -EBUSY; +} +udelay(1); +timeout--; +} -info->cpu = cpumask_next(info->cpu, &cpu_online_map); -if ( info->cpu < nr_cpu_ids ) -return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info); +return 0; +} -error = info->error; -xfree(info); -return error; +static int do_microcode_update(void *_info) +{ +struct microcode_info *info = _info; +unsigned int cpu = smp_processor_id(); +int ret; + +ret = wait_for_cpus(&info->cpu_in, MICROCODE_DEFAULT_TIMEOUT); +if ( ret ) +return ret; + +/* + * Logical threads which set the first bit in cpu_sibling_mask can do + * the update. Other sibling threads just await the completion of + * microcode update. + */ +if ( cpumask_test_and_set_cpu( +cpumask_first(per_cpu(cpu_sibling_mask, cpu)), &info->cpus) ) +ret = microcode_update_cpu(info->buffer, info->buffer_size); +/* + * Increase the wait timeout to a safe value here since we're serializing + * the microcode update and that could take a while on a large number of + * CPUs. And that is fine as the *actual* timeout will be determined by + * the last CPU finished updating and thus cut short + */ +if ( wait_for_cpus(&info->cpu_out, MICROCODE_DEFAULT_TIMEOUT * + num_online_cpus()) ) +panic("Timeout when finishing updating microcode"); + +return ret; } int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len) @@ -318,26 +357,52 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len) ret = copy_from_guest(info->buffer, buf, len); if ( ret != 0 ) -{ -xfree(info); -return ret; -} +goto free; info->buffer_size = len; -info->error =
Re: [Xen-devel] Graduation Review: Windows PV Driver
On Mon, Apr 23, 2018 at 6:14 PM, Lars Kurth wrote: > ## Summary/Recommendation > > Assessment by Lars Kurth, Community Manager: > > _Given the maturity of the drivers and thus limited need to fix issues or > develop new features, > I would recommend to graduate the project. The project has shown increased > user > engagement, adoption and delivered several releases which is consistent with > a mature > project . I have no objections on grounds of process adherence, values and > developer > community diversity and propose to the project leadership teams of other > mature > projects to agree to graduate the Windows PV Driver subproject._ > > _Recommendations: Given that Windows PV Drivers development today depends on > 3rd > party testing, I would like to recommend a public discussion whether some > testing of > Windows PV Drivers in OSSTEST is feasible and desirable._ +1 from me. I think if this project doesn't make the cut, nothing will. :-) -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 4.11.0 RC1 panic
On Wed, Apr 25, 2018 at 09:16:59AM +0100, Andrew Cooper wrote: > Manuel: As a tangentially related question, does NetBSD ever try to page > out its LDT? AFAIK no, LDTs are allocated as kernel wired memory -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] bogus wrap check in xen-netback
On Wed, Apr 25, 2018 at 12:35:11PM +0200, Olaf Hering wrote: > Am Wed, 25 Apr 2018 11:31:25 +0100 > schrieb Wei Liu : > > > My bad. Yes, they are converted to int, not unsigned int. > > Hopefully that happens only if the target is int, not if all involved > variables are short. > > Unless there are objections I will prepare a patch to deal with RING_IDX > being u16. > RING_IDX is a type defined in the public header -- I don't think you can change that at all. You don't know what third party drivers rely on that. If you want to change the type locally in netback, then why? Aren't you just debugging? In that light, I don't see a point having a patch to deal with u16. Wei. > Olaf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 4.11.0 RC1 panic
On Wed, Apr 25, 2018 at 12:58:47AM -0600, Jan Beulich wrote: > >>> On 24.04.18 at 18:06, wrote: > > Hello, > > I tested xen 4.11.0 rc1 with NetBSD as dom0. > > I could boot a NetBSD PV domU without problem, but at shutdown time > > (poweroff > > in the domU), I got a Xen panic: > > (XEN) Assertion 'cpu < nr_cpu_ids' failed at > > ...1/work/xen-4.11.0-rc1/xen/include/xen/cpumask.h:97 > > > > A xl destroy instead of poweroff gives the same result. > > > > This happens with both 32bitsPAE and 64bits domU. This doens't seem to > > happen with HVM domUs. > > > > Attached are a cut-n-paste of the panic, and the output of xl demsg. > > Without line numbers associated with at least the top stack trace entry > I can only guess what it might be - could you give the patch below a try? > (This may not be the final patch, as I'm afraid there may be some race > here, but I'd have to work this out later.) Yes, this works. thanks ! I'll now put this version on the NetBSD testbed I'm running. This should put some pressure on it. thanks ! -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference -- ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 08/10] xen/arm: Release timer interrupts when CPU is hot-unplugged
On 25/04/18 11:34, Mirela Simonovic wrote: Hi Julien, You may have missed this one. Should we try using notifiers here as well? Yes, I assumed this was implied by my comments previously, so I skipped the patch. Sorry for that. Cheers, Thanks, Mirela On Fri, Apr 20, 2018 at 2:25 PM, Mirela Simonovic wrote: When a CPU is hot-unplugged timer interrupts have to be released in order to free the memory that was allocated when the interrupts were requested (using request_irq()). The request_irq is called for each timer interrupt when the CPU gets hotplugged (start_secondary->init_timer_interrupt->request_irq). Signed-off-by: Mirela Simonovic --- CC: Stefano Stabellini CC: Julien Grall --- xen/arch/arm/smpboot.c | 1 + xen/arch/arm/time.c| 7 +++ xen/include/asm-arm/time.h | 6 ++ 3 files changed, 14 insertions(+) diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index 449fefc77d..b4ed479dc6 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -386,6 +386,7 @@ void __cpu_disable(void) * in respective init interrupt functions called from start_secondary) */ deinit_maintenance_interrupt(); +deinit_timer_interrupt(); /* It's now safe to remove this processor from the online map */ cpumask_clear_cpu(cpu, &cpu_online_map); diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c index c11fcfeadd..1d9dc16f89 100644 --- a/xen/arch/arm/time.c +++ b/xen/arch/arm/time.c @@ -312,6 +312,13 @@ void init_timer_interrupt(void) check_timer_irq_cfg(timer_irq[TIMER_PHYS_NONSECURE_PPI], "NS-physical"); } +void deinit_timer_interrupt(void) +{ +release_irq(timer_irq[TIMER_HYP_PPI], NULL); +release_irq(timer_irq[TIMER_VIRT_PPI], NULL); +release_irq(timer_irq[TIMER_PHYS_NONSECURE_PPI], NULL); +} + /* Wait a set number of microseconds */ void udelay(unsigned long usecs) { diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h index 5b9a31de91..6fa4c47532 100644 --- a/xen/include/asm-arm/time.h +++ b/xen/include/asm-arm/time.h @@ -34,6 +34,12 @@ unsigned int timer_get_irq(enum timer_ppi ppi); /* Set up the timer interrupt on this CPU */ extern void init_timer_interrupt(void); +/* + * Revert actions done in init_timer_interrupt that are required to properly + * disable this CPU. + */ +extern void deinit_timer_interrupt(void); + /* Counter value at boot time */ extern uint64_t boot_count; -- 2.13.0 -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] bogus wrap check in xen-netback
Am Wed, 25 Apr 2018 11:31:25 +0100 schrieb Wei Liu : > My bad. Yes, they are converted to int, not unsigned int. Hopefully that happens only if the target is int, not if all involved variables are short. Unless there are objections I will prepare a patch to deal with RING_IDX being u16. Olaf pgpKZjIyrez3i.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 08/10] xen/arm: Release timer interrupts when CPU is hot-unplugged
Hi Julien, You may have missed this one. Should we try using notifiers here as well? Thanks, Mirela On Fri, Apr 20, 2018 at 2:25 PM, Mirela Simonovic wrote: > When a CPU is hot-unplugged timer interrupts have to be released > in order to free the memory that was allocated when the interrupts > were requested (using request_irq()). The request_irq is called > for each timer interrupt when the CPU gets hotplugged > (start_secondary->init_timer_interrupt->request_irq). > > Signed-off-by: Mirela Simonovic > > --- > CC: Stefano Stabellini > CC: Julien Grall > --- > xen/arch/arm/smpboot.c | 1 + > xen/arch/arm/time.c| 7 +++ > xen/include/asm-arm/time.h | 6 ++ > 3 files changed, 14 insertions(+) > > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c > index 449fefc77d..b4ed479dc6 100644 > --- a/xen/arch/arm/smpboot.c > +++ b/xen/arch/arm/smpboot.c > @@ -386,6 +386,7 @@ void __cpu_disable(void) > * in respective init interrupt functions called from start_secondary) > */ > deinit_maintenance_interrupt(); > +deinit_timer_interrupt(); > > /* It's now safe to remove this processor from the online map */ > cpumask_clear_cpu(cpu, &cpu_online_map); > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c > index c11fcfeadd..1d9dc16f89 100644 > --- a/xen/arch/arm/time.c > +++ b/xen/arch/arm/time.c > @@ -312,6 +312,13 @@ void init_timer_interrupt(void) > check_timer_irq_cfg(timer_irq[TIMER_PHYS_NONSECURE_PPI], "NS-physical"); > } > > +void deinit_timer_interrupt(void) > +{ > +release_irq(timer_irq[TIMER_HYP_PPI], NULL); > +release_irq(timer_irq[TIMER_VIRT_PPI], NULL); > +release_irq(timer_irq[TIMER_PHYS_NONSECURE_PPI], NULL); > +} > + > /* Wait a set number of microseconds */ > void udelay(unsigned long usecs) > { > diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h > index 5b9a31de91..6fa4c47532 100644 > --- a/xen/include/asm-arm/time.h > +++ b/xen/include/asm-arm/time.h > @@ -34,6 +34,12 @@ unsigned int timer_get_irq(enum timer_ppi ppi); > /* Set up the timer interrupt on this CPU */ > extern void init_timer_interrupt(void); > > +/* > + * Revert actions done in init_timer_interrupt that are required to properly > + * disable this CPU. > + */ > +extern void deinit_timer_interrupt(void); > + > /* Counter value at boot time */ > extern uint64_t boot_count; > > -- > 2.13.0 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] bogus wrap check in xen-netback
On Wed, Apr 25, 2018 at 04:26:06AM -0600, Jan Beulich wrote: > >>> On 25.04.18 at 12:06, wrote: > > On Wed, Apr 25, 2018 at 11:04:26AM +0200, Olaf Hering wrote: > >> Am Wed, 25 Apr 2018 09:59:23 +0100 > >> schrieb Wei Liu : > >> > >> > Do you have the full diff of your changes? > >> > >> Not right now. But without 'val', or val being uint, the same error > >> happens > > in f(): > >> > >> #include > >> void f(void) > >> { > >> unsigned short req_prod = 0, req_cons = 65400; > >> unsigned short val; > >> val = req_prod - req_cons; > >> printf("req_prod - req_cons %u\n", val); > >> printf("req_prod - req_cons %x\n", val); > >> } > > > > What Jan said. > > > > Integer promotion makes unsigned short into unsigned int first then do > > the calculation. > > Not exactly - it promotes to plain (i.e. signed) int. My bad. Yes, they are converted to int, not unsigned int. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] bogus wrap check in xen-netback
>>> On 25.04.18 at 12:06, wrote: > On Wed, Apr 25, 2018 at 11:04:26AM +0200, Olaf Hering wrote: >> Am Wed, 25 Apr 2018 09:59:23 +0100 >> schrieb Wei Liu : >> >> > Do you have the full diff of your changes? >> >> Not right now. But without 'val', or val being uint, the same error happens > in f(): >> >> #include >> void f(void) >> { >> unsigned short req_prod = 0, req_cons = 65400; >> unsigned short val; >> val = req_prod - req_cons; >> printf("req_prod - req_cons %u\n", val); >> printf("req_prod - req_cons %x\n", val); >> } > > What Jan said. > > Integer promotion makes unsigned short into unsigned int first then do > the calculation. Not exactly - it promotes to plain (i.e. signed) int. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-coverity test] 122409: all pass - PUSHED
flight 122409 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/122409/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 27170adb54a558e11defcd51989326a9beb95afe baseline version: xen 16fb4b5a9a79f95df17f10ba62e9f44d21cf89b5 Last test of basis 122308 2018-04-15 09:38:37 Z 10 days Testing same since 122409 2018-04-25 09:18:40 Z0 days1 attempts People who touched revisions under test: Andrew Cooper David Wang George Dunlap Ian Jackson Jan Beulich Juergen Gross Oleksandr Tyshchenko Roger Pau Monne Roger Pau Monné Wei Liu jobs: coverity-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 16fb4b5a9a..27170adb54 27170adb54a558e11defcd51989326a9beb95afe -> coverity-tested/smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86: Do not reserve a crash kernel region if booted on Xen PV
Xen PV domains cannot shut down and start a crash kernel. Instead, the crashing kernel makes a SCHEDOP_shutdown hypercall with the reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in arch/x86/xen/enlighten_pv.c. A crash kernel reservation is merely a waste of RAM in this case. It may also confuse users of kexec_load(2) and/or kexec_file_load(2). When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH, respectively, these syscalls return success, which is technically correct, but the crash kexec image will never be actually used. Signed-off-by: Petr Tesarik --- arch/x86/kernel/setup.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 6285697b6e56..5c623dfe39d1 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -50,6 +50,7 @@ #include #include #include +#include #include #include @@ -534,6 +535,11 @@ static void __init reserve_crashkernel(void) high = true; } + if (xen_pv_domain()) { + pr_info("Ignoring crashkernel for a Xen PV domain\n"); + return; + } + /* 0 means: find the address automatically */ if (crash_base <= 0) { /* -- 2.13.6 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] bogus wrap check in xen-netback
On Wed, Apr 25, 2018 at 11:04:26AM +0200, Olaf Hering wrote: > Am Wed, 25 Apr 2018 09:59:23 +0100 > schrieb Wei Liu : > > > Do you have the full diff of your changes? > > Not right now. But without 'val', or val being uint, the same error happens > in f(): > > #include > void f(void) > { > unsigned short req_prod = 0, req_cons = 65400; > unsigned short val; > val = req_prod - req_cons; > printf("req_prod - req_cons %u\n", val); > printf("req_prod - req_cons %x\n", val); > } What Jan said. Integer promotion makes unsigned short into unsigned int first then do the calculation. Assigning the result to val truncates it back to unsigned short. For the original code, idx is of type unsigned int. No promotion or truncation is needed so the end result is correct. Wei. > > int main(void) > { > #if 1 > unsigned nr_ents = 0x100U, req_prod_pvt = 0x14U, rsp_cons = > 0xffeeU, req_prod = 0xfffeU; > unsigned rx_target = 0x40U, qlen = 0x1aU; > #else > unsigned nr_ents = 0x100U, req_prod_pvt = 0x00U, rsp_cons = > 0xffeeU, req_prod = 0xfffeU; > unsigned rx_target = 0x40U, qlen = 0x1aU; > #endif > printf("batch_target %u, skb_queue_len %u, rx_target %u\n", rx_target > - (req_prod_pvt - rsp_cons), qlen, rx_target); > printf("nr_ents %u\n", nr_ents); > printf("req_prod_pvt - rsp_cons %u\n", req_prod_pvt - rsp_cons); > printf("req_prod_pvt - req_prod %u\n", req_prod_pvt - req_prod); > printf("%u\n", nr_ents - (req_prod_pvt - rsp_cons)); > printf("%u\n", nr_ents - (req_prod_pvt - rsp_cons)); > f(); > return 0; > } ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] bogus wrap check in xen-netback
>>> On 25.04.18 at 11:04, wrote: > Am Wed, 25 Apr 2018 09:59:23 +0100 > schrieb Wei Liu : > >> Do you have the full diff of your changes? > > Not right now. But without 'val', or val being uint, the same error happens > in f(): > > #include > void f(void) > { > unsigned short req_prod = 0, req_cons = 65400; > unsigned short val; > val = req_prod - req_cons; > printf("req_prod - req_cons %u\n", val); > printf("req_prod - req_cons %x\n", val); > } Well, of course - anything more narrow than int will be promoted to int first. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling
On 04/25/2018 12:02 PM, Takashi Iwai wrote: On Wed, 25 Apr 2018 10:26:34 +0200, Oleksandr Andrushchenko wrote: On 04/24/2018 07:23 PM, Oleksandr Andrushchenko wrote: On 04/24/2018 06:02 PM, Takashi Iwai wrote: On Tue, 24 Apr 2018 16:58:43 +0200, Oleksandr Andrushchenko wrote: On 04/24/2018 05:35 PM, Takashi Iwai wrote: On Tue, 24 Apr 2018 16:29:15 +0200, Oleksandr Andrushchenko wrote: On 04/24/2018 05:20 PM, Takashi Iwai wrote: On Mon, 16 Apr 2018 08:24:51 +0200, Oleksandr Andrushchenko wrote: +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) +{ + struct xen_snd_front_evtchnl *channel = dev_id; + struct xen_snd_front_info *front_info = channel->front_info; + struct xensnd_resp *resp; + RING_IDX i, rp; + unsigned long flags; + + if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED)) + return IRQ_HANDLED; + + spin_lock_irqsave(&front_info->io_lock, flags); + +again: + rp = channel->u.req.ring.sring->rsp_prod; + /* ensure we see queued responses up to rp */ + rmb(); + + for (i = channel->u.req.ring.rsp_cons; i != rp; i++) { I'm not familiar with Xen stuff in general, but through a quick glance, this kind of code worries me a bit. If channel->u.req.ring.rsp_cons has a bogus number, this may lead to a very long loop, no? Better to have a sanity check of the ring buffer size. In this loop I have: resp = RING_GET_RESPONSE(&channel->u.req.ring, i); and the RING_GET_RESPONSE macro is designed in the way that it wraps around when *i* in the question gets bigger than the ring size: #define RING_GET_REQUEST(_r, _idx) \ (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req)) So, even if the counter has a bogus number it will not last long Hm, this prevents from accessing outside the ring buffer, but does it change the loop behavior? no, it doesn't Suppose channel->u.req.ring_rsp_cons = 1, and rp = 0, the loop below would still consume the whole 32bit counts, no? for (i = channel->u.req.ring.rsp_cons; i != rp; i++) { resp = RING_GET_RESPONSE(&channel->u.req.ring, i); ... } You are right here and the comment is totally valid. I'll put an additional check like here [1] and here [2] Will this address your comment? Yep, this kind of sanity checks should work. Great, will implement the checks this way then Well, after thinking a bit more on that and chatting on #xendevel IRC with Juergen (he is on CC list), it seems that the way the code is now it is all fine without the checks: the assumption here is that the backend is trusted to always write sane values to the ring counters, thus no overflow checks on frontend side are required. Even if I implement the checks then I have no means to recover, but just print an error message and bail out not handling any responses. This is probably why the checks [1] and [2] are only implemented for the backend side and there are no such macros for the frontend side. Takashi, please let me know if the above sounds reasonable and addresses your comments. If it's guaranteed to work, that's OK. But maybe it's worth to comment for readers. ok, will put a comment on that thanks, Takashi Thank you, Oleksandr ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] bogus wrap check in xen-netback
Am Wed, 25 Apr 2018 09:59:23 +0100 schrieb Wei Liu : > Do you have the full diff of your changes? Not right now. But without 'val', or val being uint, the same error happens in f(): #include void f(void) { unsigned short req_prod = 0, req_cons = 65400; unsigned short val; val = req_prod - req_cons; printf("req_prod - req_cons %u\n", val); printf("req_prod - req_cons %x\n", val); } int main(void) { #if 1 unsigned nr_ents = 0x100U, req_prod_pvt = 0x14U, rsp_cons = 0xffeeU, req_prod = 0xfffeU; unsigned rx_target = 0x40U, qlen = 0x1aU; #else unsigned nr_ents = 0x100U, req_prod_pvt = 0x00U, rsp_cons = 0xffeeU, req_prod = 0xfffeU; unsigned rx_target = 0x40U, qlen = 0x1aU; #endif printf("batch_target %u, skb_queue_len %u, rx_target %u\n", rx_target - (req_prod_pvt - rsp_cons), qlen, rx_target); printf("nr_ents %u\n", nr_ents); printf("req_prod_pvt - rsp_cons %u\n", req_prod_pvt - rsp_cons); printf("req_prod_pvt - req_prod %u\n", req_prod_pvt - req_prod); printf("%u\n", nr_ents - (req_prod_pvt - rsp_cons)); printf("%u\n", nr_ents - (req_prod_pvt - rsp_cons)); f(); return 0; } pgpUg7lnDX9qJ.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling
On Wed, 25 Apr 2018 10:26:34 +0200, Oleksandr Andrushchenko wrote: > > On 04/24/2018 07:23 PM, Oleksandr Andrushchenko wrote: > > On 04/24/2018 06:02 PM, Takashi Iwai wrote: > >> On Tue, 24 Apr 2018 16:58:43 +0200, > >> Oleksandr Andrushchenko wrote: > >>> On 04/24/2018 05:35 PM, Takashi Iwai wrote: > On Tue, 24 Apr 2018 16:29:15 +0200, > Oleksandr Andrushchenko wrote: > > On 04/24/2018 05:20 PM, Takashi Iwai wrote: > >> On Mon, 16 Apr 2018 08:24:51 +0200, > >> Oleksandr Andrushchenko wrote: > >>> +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) > >>> +{ > >>> + struct xen_snd_front_evtchnl *channel = dev_id; > >>> + struct xen_snd_front_info *front_info = channel->front_info; > >>> + struct xensnd_resp *resp; > >>> + RING_IDX i, rp; > >>> + unsigned long flags; > >>> + > >>> + if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED)) > >>> + return IRQ_HANDLED; > >>> + > >>> + spin_lock_irqsave(&front_info->io_lock, flags); > >>> + > >>> +again: > >>> + rp = channel->u.req.ring.sring->rsp_prod; > >>> + /* ensure we see queued responses up to rp */ > >>> + rmb(); > >>> + > >>> + for (i = channel->u.req.ring.rsp_cons; i != rp; i++) { > >> I'm not familiar with Xen stuff in general, but through a quick > >> glance, this kind of code worries me a bit. > >> > >> If channel->u.req.ring.rsp_cons has a bogus number, this may > >> lead to a > >> very long loop, no? Better to have a sanity check of the ring > >> buffer > >> size. > > In this loop I have: > > resp = RING_GET_RESPONSE(&channel->u.req.ring, i); > > and the RING_GET_RESPONSE macro is designed in the way that > > it wraps around when *i* in the question gets bigger than > > the ring size: > > > > #define RING_GET_REQUEST(_r, _idx) \ > > (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req)) > > > > So, even if the counter has a bogus number it will not last long > Hm, this prevents from accessing outside the ring buffer, but does it > change the loop behavior? > >>> no, it doesn't > Suppose channel->u.req.ring_rsp_cons = 1, and rp = 0, the loop below > would still consume the whole 32bit counts, no? > > for (i = channel->u.req.ring.rsp_cons; i != rp; i++) { > resp = RING_GET_RESPONSE(&channel->u.req.ring, i); > ... > } > >>> You are right here and the comment is totally valid. > >>> I'll put an additional check like here [1] and here [2] > >>> Will this address your comment? > >> Yep, this kind of sanity checks should work. > >> > > Great, will implement the checks this way then > Well, after thinking a bit more on that and chatting on #xendevel IRC > with Juergen (he is on CC list), it seems that the way the code is now > it is all fine without the checks: the assumption here is that > the backend is trusted to always write sane values to the ring counters, > thus no overflow checks on frontend side are required. > Even if I implement the checks then I have no means to recover, but > just print > an error message and bail out not handling any responses. > This is probably why the checks [1] and [2] are only implemented for the > backend side and there are no such macros for the frontend side. > > Takashi, please let me know if the above sounds reasonable and > addresses your comments. If it's guaranteed to work, that's OK. But maybe it's worth to comment for readers. thanks, Takashi ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] bogus wrap check in xen-netback
On Wed, Apr 25, 2018 at 09:39:24AM +0200, Olaf Hering wrote: > Am Wed, 25 Apr 2018 09:28:38 +0200 > schrieb Juergen Gross : > > > Why? (u16)0 - (u16)65400 == 136 > > My helloworld.c shows that ushort gets promoted to uint, unless it is done > like that: > > - if (queue->tx.sring->req_prod - queue->tx.req_cons > > - XEN_NETIF_TX_RING_SIZE) { > + idx = queue->tx.sring->req_prod - queue->tx.req_cons; > + if ( idx > XEN_NETIF_TX_RING_SIZE) { Do you have the full diff of your changes? I don't follow why integer conversion works differently if you write the code like this. As far as I can tell the type of LHS didn't change. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/5] ALSA: xen-front: Implement Xen event channel handling
On 04/24/2018 07:23 PM, Oleksandr Andrushchenko wrote: On 04/24/2018 06:02 PM, Takashi Iwai wrote: On Tue, 24 Apr 2018 16:58:43 +0200, Oleksandr Andrushchenko wrote: On 04/24/2018 05:35 PM, Takashi Iwai wrote: On Tue, 24 Apr 2018 16:29:15 +0200, Oleksandr Andrushchenko wrote: On 04/24/2018 05:20 PM, Takashi Iwai wrote: On Mon, 16 Apr 2018 08:24:51 +0200, Oleksandr Andrushchenko wrote: +static irqreturn_t evtchnl_interrupt_req(int irq, void *dev_id) +{ + struct xen_snd_front_evtchnl *channel = dev_id; + struct xen_snd_front_info *front_info = channel->front_info; + struct xensnd_resp *resp; + RING_IDX i, rp; + unsigned long flags; + + if (unlikely(channel->state != EVTCHNL_STATE_CONNECTED)) + return IRQ_HANDLED; + + spin_lock_irqsave(&front_info->io_lock, flags); + +again: + rp = channel->u.req.ring.sring->rsp_prod; + /* ensure we see queued responses up to rp */ + rmb(); + + for (i = channel->u.req.ring.rsp_cons; i != rp; i++) { I'm not familiar with Xen stuff in general, but through a quick glance, this kind of code worries me a bit. If channel->u.req.ring.rsp_cons has a bogus number, this may lead to a very long loop, no? Better to have a sanity check of the ring buffer size. In this loop I have: resp = RING_GET_RESPONSE(&channel->u.req.ring, i); and the RING_GET_RESPONSE macro is designed in the way that it wraps around when *i* in the question gets bigger than the ring size: #define RING_GET_REQUEST(_r, _idx) \ (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req)) So, even if the counter has a bogus number it will not last long Hm, this prevents from accessing outside the ring buffer, but does it change the loop behavior? no, it doesn't Suppose channel->u.req.ring_rsp_cons = 1, and rp = 0, the loop below would still consume the whole 32bit counts, no? for (i = channel->u.req.ring.rsp_cons; i != rp; i++) { resp = RING_GET_RESPONSE(&channel->u.req.ring, i); ... } You are right here and the comment is totally valid. I'll put an additional check like here [1] and here [2] Will this address your comment? Yep, this kind of sanity checks should work. Great, will implement the checks this way then Well, after thinking a bit more on that and chatting on #xendevel IRC with Juergen (he is on CC list), it seems that the way the code is now it is all fine without the checks: the assumption here is that the backend is trusted to always write sane values to the ring counters, thus no overflow checks on frontend side are required. Even if I implement the checks then I have no means to recover, but just print an error message and bail out not handling any responses. This is probably why the checks [1] and [2] are only implemented for the backend side and there are no such macros for the frontend side. Takashi, please let me know if the above sounds reasonable and addresses your comments. thanks, Takashi Thank you, Oleksandr Takashi Thank you, Oleksandr [1] https://elixir.bootlin.com/linux/v4.17-rc2/source/drivers/block/xen-blkback/blkback.c#L1127 [2] https://elixir.bootlin.com/linux/v4.17-rc2/source/drivers/block/xen-blkback/blkback.c#L1135 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 05/10] xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume
On 04/24/2018 03:50 PM, Mirela Simonovic wrote: Hi Julien, Hi, Sorry I forgot to answer to some part of the e-mail. On Mon, Apr 23, 2018 at 1:28 PM, Julien Grall wrote: Hi Mirela, On 20/04/18 13:25, Mirela Simonovic wrote: diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index d43c3aa896..9bb62c13cd 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -1451,13 +1451,21 @@ err: return page; } -static void __init setup_virt_paging_one(void *data) +static void setup_virt_paging_one(void *data) { unsigned long val = (unsigned long)data; WRITE_SYSREG32(val, VTCR_EL2); isb(); } +/* VTCR value to be configured by all CPUs. Set only once by the boot CPU */ +static unsigned long __read_mostly vtcr_value; VTCR is a register, so the type should be represented in term of bits (i.e uint*_t). I followed the type used in setup_virt_paging() and it's unsigned long. However, the spec says the VTCR_EL2 is 32-bit register, meaning that in the current implementation the type is not correct. If I want the type to be correct in this patch Xen will not compile. Are you suggesting to fix the type in existing implementation? The unsigned long is just a workaround to avoid an extra variable for the cast. As you introduce a static variable, then the cast become unnecessary. + +void setup_virt_paging_secondary(void) +{ +setup_virt_paging_one((void *)vtcr_value); That's fairly ugly. Is there any way to rework the interface? For instance, because you have a static variable which contain the VTCR, you could just use the variable in setup_virt_paging one. I If the argument provided to setup_virt_paging_one() is NULL within the setup_virt_paging_one() I configure saved static vtcr_value? If that is what you meant it was submitted in previous version of this patch :) Are you suggesting to revert the change to v1? I would suggest a mix between v1 and v2. Something like: static uint64_t vtcr; static setup_init_paging_one(void *data) { WRITE_SYSREG(vtcr, VTRC_EL2); [...] } r void __init setup_virt_paging(...) { vtcr = val; } Potentially, you could drop val and use vtcr everywhere in setup_virt_paging(). Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 4.11.0 RC1 panic
On 25/04/2018 07:58, Jan Beulich wrote: On 24.04.18 at 18:06, wrote: >> Hello, >> I tested xen 4.11.0 rc1 with NetBSD as dom0. >> I could boot a NetBSD PV domU without problem, but at shutdown time >> (poweroff >> in the domU), I got a Xen panic: >> (XEN) Assertion 'cpu < nr_cpu_ids' failed at >> ...1/work/xen-4.11.0-rc1/xen/include/xen/cpumask.h:97 >> >> A xl destroy instead of poweroff gives the same result. >> >> This happens with both 32bitsPAE and 64bits domU. This doens't seem to >> happen with HVM domUs. >> >> Attached are a cut-n-paste of the panic, and the output of xl demsg. > Without line numbers associated with at least the top stack trace entry > I can only guess what it might be - could you give the patch below a try? > (This may not be the final patch, as I'm afraid there may be some race > here, but I'd have to work this out later.) > > Jan > > --- unstable.orig/xen/arch/x86/mm.c > +++ unstable/xen/arch/x86/mm.c > @@ -1255,7 +1255,7 @@ void put_page_from_l1e(l1_pgentry_t l1e, > { > for_each_vcpu ( pg_owner, v ) > { > -if ( pv_destroy_ldt(v) ) > +if ( pv_destroy_ldt(v) && v->dirty_cpu != VCPU_CPU_CLEAN ) > flush_tlb_mask(cpumask_of(v->dirty_cpu)); > } > } > Manuel: As a tangentially related question, does NetBSD ever try to page out its LDT? I'm fairly sure this particular bit of code exists solely for the Windows XP port to PV guests. The code itself is broken as far as the "feature" goes (as it only works on present => not present PTE changes, and not for other PTE permissions changes which would also drop the segdesc typeref), and dropping it would remove one vcpu scalability limitation for PV guests. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/SVM: Fix intercepted {RD, WR}MSR for the SYS{CALL, ENTER} MSRs
On 04/25/2018 09:49 AM, Jan Beulich wrote: On 24.04.18 at 20:51, wrote: >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr, >> uint64_t *msr_content) >> switch ( msr ) >> { >> case MSR_IA32_SYSENTER_CS: >> +case MSR_IA32_SYSENTER_ESP: >> +case MSR_IA32_SYSENTER_EIP: > > These three do not require sync-ing, as their values aren't read from the > VMCB. > (They do require sync-ing on the write path). > > I also don't think this is going to fully resolve Razvan's issue (not the > least > because the code paths you adjust aren't involved in his scenario): As > pointed out in a private mail, I think vmcb_in_sync needs to start out as > true for a vCPU, and may need setting to true upon context set and/or > reset/init emulation. Doing arch_svm->vmcb_in_sync = 1; in construct_vmcb() does solve the issue. I can't unfortunately test if it also needs setting in other places as our internal patches still need some work so introspection is not yet fully functional on SVM (mem_access events specifically are a bit of a problem). Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.7-testing test] 122382: regressions - trouble: blocked/broken/fail/pass
flight 122382 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122382/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 122131 build-armhf 5 host-build-prep fail REGR. vs. 122131 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 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-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122131 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122131 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122131 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122131 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122131 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122131 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122131 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122131 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122131 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122131 test-amd64-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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 2fbc00615061d8931acfd2908426ba5fa0132ca3 baseline version: xen 9680710bed1c174ced7a170cb94e30b4ae4fff5e Last test of basis 122131 2018-04-09 10:53:16 Z 15 days Testing same since 122353 2018-04-23 11:05:56 Z1 days2 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Kevin Tian jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf broken build-i386 pass buil
Re: [Xen-devel] [PATCH for-4.11] x86/SVM: Fix intercepted {RD, WR}MSR for the SYS{CALL, ENTER} MSRs
On 25/04/2018 07:49, Jan Beulich wrote: On 24.04.18 at 20:51, wrote: >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr, >> uint64_t *msr_content) >> switch ( msr ) >> { >> case MSR_IA32_SYSENTER_CS: >> +case MSR_IA32_SYSENTER_ESP: >> +case MSR_IA32_SYSENTER_EIP: > These three do not require sync-ing, as their values aren't read from the > VMCB. > (They do require sync-ing on the write path). See the TODO list in the patch comment. This is a quirk of cross-vendor logic being used unnecessarily in the common case, and isn't going to remain like this. > I also don't think this is going to fully resolve Razvan's issue (not the > least > because the code paths you adjust aren't involved in his scenario): As > pointed out in a private mail, I think vmcb_in_sync needs to start out as > true for a vCPU, and may need setting to true upon context set and/or > reset/init emulation. No - it wont, but its obviously broken and will be the second bug to be hit by introspection, when interception of these MSRs is active. It just so happened that it was the easier issue to get started with. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] bogus wrap check in xen-netback
Am Wed, 25 Apr 2018 09:28:38 +0200 schrieb Juergen Gross : > Why? (u16)0 - (u16)65400 == 136 My helloworld.c shows that ushort gets promoted to uint, unless it is done like that: - if (queue->tx.sring->req_prod - queue->tx.req_cons > - XEN_NETIF_TX_RING_SIZE) { + idx = queue->tx.sring->req_prod - queue->tx.req_cons; + if ( idx > XEN_NETIF_TX_RING_SIZE) { Olaf pgpAzwssvPxQm.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] bogus wrap check in xen-netback
On 25/04/18 09:19, Olaf Hering wrote: > With commit 48856286b64e ("xen/netback: shutdown the ring if it contains > garbage.") a new check was added to xen-netback, which triggers for me. > > Since there are bugs in ring buffer handling I tried to trigger them earlier > by changing RING_IDX from u32 to u16. Now I found another one, and I wonder > if the error below could potentially also hit with u32: > > ... > [ 624.186492] br0: port 3(vif2.0) entered forwarding state > [ 624.186522] br0: port 3(vif2.0) entered forwarding state > [ 680.865398] vif vif-1-0 vif1.0: Impossible number of requests. req_prod 0, > req_cons 65400, size 256 > [ 680.865402] vif vif-1-0 vif1.0: fatal error; disabling device > [ 680.865495] br0: port 2(vif1.0) entered disabled state > [ 689.433849] vif vif-2-0 vif2.0: Impossible number of requests. req_prod 0, > req_cons 65527, size 256 > [ 689.433857] vif vif-2-0 vif2.0: fatal error; disabling device > [ 689.433945] br0: port 3(vif2.0) entered disabled state > [ 690.930512] pktgen: Packet Generator for packet performance testing. > Version: 2.75 > ... > > What exactly is that check in xenvif_tx_build_gops trying to achieve? > Subtracting a non-zero value from zero will always create something larger > than XEN_NETIF_TX_RING_SIZE. Why? (u16)0 - (u16)65400 == 136 Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] bogus wrap check in xen-netback
With commit 48856286b64e ("xen/netback: shutdown the ring if it contains garbage.") a new check was added to xen-netback, which triggers for me. Since there are bugs in ring buffer handling I tried to trigger them earlier by changing RING_IDX from u32 to u16. Now I found another one, and I wonder if the error below could potentially also hit with u32: ... [ 624.186492] br0: port 3(vif2.0) entered forwarding state [ 624.186522] br0: port 3(vif2.0) entered forwarding state [ 680.865398] vif vif-1-0 vif1.0: Impossible number of requests. req_prod 0, req_cons 65400, size 256 [ 680.865402] vif vif-1-0 vif1.0: fatal error; disabling device [ 680.865495] br0: port 2(vif1.0) entered disabled state [ 689.433849] vif vif-2-0 vif2.0: Impossible number of requests. req_prod 0, req_cons 65527, size 256 [ 689.433857] vif vif-2-0 vif2.0: fatal error; disabling device [ 689.433945] br0: port 3(vif2.0) entered disabled state [ 690.930512] pktgen: Packet Generator for packet performance testing. Version: 2.75 ... What exactly is that check in xenvif_tx_build_gops trying to achieve? Subtracting a non-zero value from zero will always create something larger than XEN_NETIF_TX_RING_SIZE. Olaf pgpKg1S8p5tB_.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] x86/SVM: Fix intercepted {RD, WR}MSR for the SYS{CALL, ENTER} MSRs
On 04/25/2018 09:49 AM, Jan Beulich wrote: On 24.04.18 at 20:51, wrote: --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1883,6 +1883,22 @@ static int svm_msr_read_intercept(unsigned int msr, uint64_t *msr_content) switch ( msr ) { case MSR_IA32_SYSENTER_CS: +case MSR_IA32_SYSENTER_ESP: +case MSR_IA32_SYSENTER_EIP: These three do not require sync-ing, as their values aren't read from the VMCB. (They do require sync-ing on the write path). I also don't think this is going to fully resolve Razvan's issue (not the least because the code paths you adjust aren't involved in his scenario): As pointed out in a private mail, I think vmcb_in_sync needs to start out as true for a vCPU, and may need setting to true upon context set and/or reset/init emulation. It indeed does not solve the whole issue - I've tested the patch as soon as it was posted (and I've tried a similar strategy for LSTAR alone as part of debugging before notifying of the issue). But I think Andrew meant it as a separate patch, fixing only the intercept part. I'll test the vmcb_in_sync suggestion ASAP. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 4.11.0 RC1 panic
>>> On 24.04.18 at 18:06, wrote: > Hello, > I tested xen 4.11.0 rc1 with NetBSD as dom0. > I could boot a NetBSD PV domU without problem, but at shutdown time > (poweroff > in the domU), I got a Xen panic: > (XEN) Assertion 'cpu < nr_cpu_ids' failed at > ...1/work/xen-4.11.0-rc1/xen/include/xen/cpumask.h:97 > > A xl destroy instead of poweroff gives the same result. > > This happens with both 32bitsPAE and 64bits domU. This doens't seem to > happen with HVM domUs. > > Attached are a cut-n-paste of the panic, and the output of xl demsg. Without line numbers associated with at least the top stack trace entry I can only guess what it might be - could you give the patch below a try? (This may not be the final patch, as I'm afraid there may be some race here, but I'd have to work this out later.) Jan --- unstable.orig/xen/arch/x86/mm.c +++ unstable/xen/arch/x86/mm.c @@ -1255,7 +1255,7 @@ void put_page_from_l1e(l1_pgentry_t l1e, { for_each_vcpu ( pg_owner, v ) { -if ( pv_destroy_ldt(v) ) +if ( pv_destroy_ldt(v) && v->dirty_cpu != VCPU_CPU_CLEAN ) flush_tlb_mask(cpumask_of(v->dirty_cpu)); } } ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel