xen-network-common.sh MAC address assignment
Hello,
Why does git commit f400f2993b52e820d0da24a2e49a8fdfab0d2827, make
xen-network-common.sh set a static MAC address for the virtual device
as shown below?
ip link set dev ${dev} address fe:ff:ff:ff:ff:ff || true
I see the high order byte is 0xFE, which has the broadcast flag unset,
thereby signifying a unicast MAC address (as stated in the comment
right before this line). But shouldnt the device have a random MAC
address? Is there any reason why a hardcoded MAC is assigned? FYI, in
rewriting this script with a randomized MAC, my VM cannot communicate
with my host, so this might have something to do with my problem.
Thanks.
--
My Blog: http://www.neilscomputerblog.blogspot.com/
Twitter: @neilsikka
[linux-linus bisection] complete test-amd64-i386-xl-pvshim
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-pvshim
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Bug introduced: 6cd3d4019ba3f45aa1a87e4e914e81d367b59937
Bug not present: 0adb8bc0391f1fa7820529c0200fb0c4912fe365
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149546/
commit 6cd3d4019ba3f45aa1a87e4e914e81d367b59937
Merge: 0adb8bc0391f c3881eb58d56
Author: Linus Torvalds
Date: Fri Apr 3 12:51:46 2020 -0700
Merge tag 'for-linus-5.7-rc1-tag' of
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen updates from Juergen Gross:
- a cleanup patch removing an unused function
- a small fix for the xen pciback driver
- a series for making the unwinder hyppay with the Xen PV guest idle
task stacks
* tag 'for-linus-5.7-rc1-tag' of
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
x86/xen: Make the secondary CPU idle tasks reliable
x86/xen: Make the boot CPU idle task reliable
xen-pciback: fix INTERRUPT_TYPE_* defines
xen/xenbus: remove unused xenbus_map_ring()
commit c3881eb58d56116c79ac4ee4f40fd15ead124c4b
Author: Miroslav Benes
Date: Thu Mar 26 10:26:03 2020 +0100
x86/xen: Make the secondary CPU idle tasks reliable
The unwinder reports the secondary CPU idle tasks' stack on XEN PV as
unreliable, which affects at least live patching.
cpu_initialize_context() sets up the context of the CPU through
VCPUOP_initialise hypercall. After it is woken up, the idle task starts
in cpu_bringup_and_idle() function and its stack starts at the offset
right below pt_regs. The unwinder correctly detects the end of stack
there but it is confused by NULL return address in the last frame.
Introduce a wrapper in assembly, which just calls
cpu_bringup_and_idle(). The return address is thus pushed on the stack
and the wrapper contains the annotation hint for the unwinder regarding
the stack state.
Signed-off-by: Miroslav Benes
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
commit 2f62f36e62daec43aa7b9633ef7f18e042a80bed
Author: Miroslav Benes
Date: Thu Mar 26 10:26:02 2020 +0100
x86/xen: Make the boot CPU idle task reliable
The unwinder reports the boot CPU idle task's stack on XEN PV as
unreliable, which affects at least live patching. There are two reasons
for this. First, the task does not follow the x86 convention that its
stack starts at the offset right below saved pt_regs. It allows the
unwinder to easily detect the end of the stack and verify it. Second,
startup_xen() function does not store the return address before jumping
to xen_start_kernel() which confuses the unwinder.
Amend both issues by moving the starting point of initial stack in
startup_xen() and storing the return address before the jump, which is
exactly what call instruction does.
Signed-off-by: Miroslav Benes
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
commit 69086bd698574501a59073b07b629f2a00b82552
Author: Marek Marczykowski-Górecki
Date: Fri Mar 20 04:09:18 2020 +0100
xen-pciback: fix INTERRUPT_TYPE_* defines
xen_pcibk_get_interrupt_type() assumes INTERRUPT_TYPE_NONE being 0
(initialize ret to 0 and return as INTERRUPT_TYPE_NONE).
Fix the definition to make INTERRUPT_TYPE_NONE really 0, and also shift
other values to not leave holes.
But also, do not assume INTERRUPT_TYPE_NONE being 0 anymore to avoid
similar confusions in the future.
Fixes: 476878e4b2be ("xen-pciback: optionally allow interrupt enable flag
writes")
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Boris Ostrovsky
Reviewed-by: Roger Pau Monné
Signed-off-by: Juergen Gross
commit b28089a7ad9d07b1b35e2b781a66a200f8b8e20d
Author: Juergen Gross
Date: Mon Mar 9 16:54:41 2020 +0100
xen/xenbus: remove unused xenbus_map_ring()
xenbus_map_ring() is used nowhere in the tree, remove it.
xenbus_unmap_ring() is used only locally, so make it static and move it
up.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Signed-off-by: Juergen Gross
For
[xen-unstable test] 149520: regressions - FAIL
flight 149520 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/149520/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. vs. 149478 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail in 149502 pass in 149520 test-armhf-armhf-xl-vhd 18 leak-check/check fail pass in 149502 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149431 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 149478 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 149478 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 149478 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 149478 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 149478 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 149478 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 149478 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 149478 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 149478 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-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-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail 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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-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-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-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-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 version targeted for testing: xen e013e8514389b739153016349e49f5a78e34ddf0 baseline version: xen
Re: [PATCH v14 0/3] VM forking
On Wed, Apr 8, 2020 at 5:15 AM Jan Beulich wrote:
>
> On 06.04.2020 17:20, Tamas K Lengyel wrote:
> > The following series implements VM forking for Intel HVM guests to allow for
> > the fast creation of identical VMs without the assosciated high startup
> > costs
> > of booting or restoring the VM from a savefile.
> >
> > JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
> >
> > The fork operation is implemented as part of the "xl fork-vm" command:
> > xl fork-vm -C -Q -m
> >
> > By default a fully functional fork is created. The user is in charge
> > however to
> > create the appropriate config file for the fork and to generate the QEMU
> > save
> > file before the fork-vm call is made. The config file needs to give the
> > fork a new name at minimum but other settings may also require changes.
> > Certain
> > settings in the config file of both the parent and the fork have to be set
> > to
> > default. Details are documented.
> >
> > The interface also allows to split the forking into two steps:
> > xl fork-vm --launch-dm no \
> >-m \
> >-p
> > xl fork-vm --launch-dm late \
> >-C \
> >-Q \
> >
> >
> > The split creation model is useful when the VM needs to be created as fast
> > as
> > possible. The forked VM can be unpaused without the device model being
> > launched
> > to be monitored and accessed via VMI. Note however that without its device
> > model running (depending on what is executing in the VM) it is bound to
> > misbehave or even crash when its trying to access devices that would be
> > emulated by QEMU. We anticipate that for certain use-cases this would be an
> > acceptable situation, in case for example when fuzzing is performed of code
> > segments that don't access such devices.
> >
> > Launching the device model requires the QEMU Xen savefile to be generated
> > manually from the parent VM. This can be accomplished simply by connecting
> > to
> > its QMP socket and issuing the "xen-save-devices-state" command. For example
> > using the standard tool socat these commands can be used to generate the
> > file:
> > socat - UNIX-CONNECT:/var/run/xen/qmp-libxl-
> > { "execute": "qmp_capabilities" }
> > { "execute": "xen-save-devices-state", \
> > "arguments": { "filename": "/path/to/save/qemu_state", \
> > "live": false} }
> >
> > At runtime the forked VM starts running with an empty p2m which gets lazily
> > populated when the VM generates EPT faults, similar to how altp2m views are
> > populated. If the memory access is a read-only access, the p2m entry is
> > populated with a memory shared entry with its parent. For write memory
> > accesses
> > or in case memory sharing wasn't possible (for example in case a reference
> > is
> > held by a third party), a new page is allocated and the page contents are
> > copied over from the parent VM. Forks can be further forked if needed, thus
> > allowing for further memory savings.
> >
> > A VM fork reset hypercall is also added that allows the fork to be reset to
> > the
> > state it was just after a fork, also accessible via xl:
> > xl fork-vm --fork-reset -p
> >
> > This is an optimization for cases where the forks are very short-lived and
> > run
> > without a device model, so resetting saves some time compared to creating a
> > brand new fork provided the fork has not aquired a lot of memory. If the
> > fork
> > has a lot of memory deduplicated it is likely going to be faster to create a
> > new fork from scratch and asynchronously destroying the old one.
> >
> > The series has been tested with Windows VMs and functions as expected. Linux
> > VMs when forked from a running VM will have a frozen VNC screen. Linux VMs
> > at
> > this time can only be forked with a working device model when the parent VM
> > was
> > restored from a snapshot using "xl restore -p". This is a known limitation.
> > Also note that PVHVM/PVH Linux guests have not been tested. Forking most
> > likely
> > works but PV devices and drivers would require additional wiring to set
> > things
> > up properly since the guests are unaware of the forking taking place, unlike
> > the save/restore routine where the guest is made aware of the procedure.
> >
> > Forking time has been measured to be 0.0007s, device model launch to be
> > around
> > 1s depending largely on the number of devices being emulated. Fork resets
> > have
> > been measured to be 0.0001s under the optimal circumstances.
> >
> > New in v14:
> > minor adjustments
> >
> > Patch 1 implements the VM fork
> > Patch 2 implements fork reset operation
> > Patch 3 adds the toolstack-side code implementing VM forking and reset
> >
> > Tamas K Lengyel (3):
> > xen/mem_sharing: VM forking
> > x86/mem_sharing: reset a fork
>
> I've applied these two, but ...
>
> > xen/tools: VM forking toolstack side
>
> ... since this one doesn't have any
Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
On Tue, 7 Apr 2020, Julien Grall wrote:
> > > > I don’t know what maintenance IRQs are, but if they only happen
> > > > intermittently, it’s possible that you’d never get more than a single
> > > > one in a latency-critical IRQ routine; and as such, the variatibility in
> > > > execution time (jitter) wouldn’t be an issue in practice. But every
> > > > time you add a new unblockable IPI, you increase this jitter;
> > > > particularly if this unblockable IPI might be repeated an arbitrary
> > > > number of times.
> > > > (Stefano, let me know if I’ve misunderstood something.)
> > > > So stepping back a moment, here’s all the possible ideas that I think
> > > > have been discussed (or are there implicitly) so far.
> > > > 1. [Default] Do nothing; guests using this register continue crashing
> > > > 2. Make the I?ACTIVER registers RZWI.
> > > > 3. Make I?ACTIVER return the most recent known value; i.e. KVM’s current
> > > > behavior (as far as we understand it)
> > > > 4. Use a simple IPI with do_noop to update I?ACTIVER
> > > > 4a. Use an IPI, but come up with clever tricks to avoid interrupting
> > > > guests handling IRQs.
> > > > 5. Trap to Xen on guest EOI, so that we know when the
> > > > 6. Some clever paravirtualized option
> > >
> > > 7. Use an IPI if we are confident the interrupts may be active.
> >
> > I don’t understand this one. How is it different than 4 or 4a? And in
> > particular, how does it evaluate on the “how much additional design work
> > would it take” criteria?
>
> Let me start with, if we want to have a vGIC to rule them all, then I am
> afraid you are going to have to compromise. We can discuss about tailoring the
> vGIC but I think before that we need a vGIC that is faithfull with the spec
> (e.g differentiating level vs edge interrupts, handling activer...). Note that
> Arm spent some effort to get a new vGIC merged but this was never made a first
> class citizen.
>
> However, even if you tailor the vGIC, you are not going to be able to avoid
> IPI in some occasions. This would happen when using event channels, in-guest
> IPI... Another example is when enabling an interrupt, although I realize that
> our vGIC does not do it today meaning that a pending interrupt while disabled
> will not be forwarded until the vCPU exit.
>
> Furthermore, implementing a write to I{C,S}ACTIVER (to activate/de-activate)
> is going to be very difficult (to not say impossible) to do without IPI.
>
> If you are worry about a vCPU been interrupted in critical section, then I
> think you should tailor your guest to avoid using those registers.
Let's call it option 8 "tell the user that she needs to modify her
kernel."
> An alternative would be to use spinlock/mutex within the code to prevent a
> VCPU to access the vGIC registers while another vCPU don't want to be
> interrupted.
>
> Regarding, 4a. The only way I could think of would be to trap the instructions
> that mask/unmask interrupts. If I read correctly the Armv8 spec, it is not
> possible to do it.
>
> 7. is basically 4.a the goal would be to avoid interrupts the vCPU has much as
> possible but you may be wrong sometimes. Obviously we want to be correct most
> of the times.
>
> I understand this may not be the ideal solution, but this is probably the best
> we could come with and does not involve a lot of work because we have already
> all the information in place (we know when an interrupt was injected to a
> vCPU).
>
> The next best solution is to prevent in your guest to modify some registers of
> the vGIC at the same time as another vCPU is in a critical section.
Let's call this option 9.
I am just thinking out loud here :)
- 2 "Make the I?ACTIVER registers RZWI"
As far as I can tell it should prevent the livelock because it would
never return an ACTIVE state. It could be improved by returning the
latest ACTIVE information for local interrupts and returning zero for
interrupts routed to other pcpus. Not perfect but an option.
- 5 "maintenance interrupt"
This is good for jitter sensitive guests but not the best for the
others. We could enable it conditionally: enable maintenance
interrupts only for certain vcpus/pcpus but it is not great to have to
make this kind of difference in the implementation. However, it is
possible. Let's see if we can come up with something better.
- 7 "optimized IPI"
A tiny chance of causing issues. Let's see if we can come up with
anything better.
- 8 "tell the user to fix modify the kernel"
We could do it in addition to 7. The issue is really how we do it.
A warning message if DEBUG && if sched==null? That doesn't sound
right. We could introduce a new nojitter=true command line option for
Xen? It wouldn't really change the behavior of Xen, but it would
enable this warning. Or, it could enable the warning and also switch
the implementation of I?ACTIVER to option 2.
- 9 "prevent I?ACTIVER during critical sections"
This could be good but I have a
[ovmf test] 149528: all pass - PUSHED
flight 149528 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/149528/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf d4bc5378e003e53a1c76d106997cec4af46a133a baseline version: ovmf d6f99b2ac4296662720db76d7c23d224f5288df3 Last test of basis 149513 2020-04-08 07:13:07 Z0 days Testing same since 149528 2020-04-08 15:10:19 Z0 days1 attempts People who touched revisions under test: Laszlo Ersek Vitaly Cheptsov 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 d6f99b2ac4..d4bc5378e0 d4bc5378e003e53a1c76d106997cec4af46a133a -> xen-tested-master
Re: [PATCH 6/7] xen/guest_access: Consolidate guest access helpers in xen/guest_access.h
Hi Jan,
On 07/04/2020 09:14, Jan Beulich wrote:
On 04.04.2020 15:10, Julien Grall wrote:
From: Julien Grall
Most of the helpers to access guest memory are implemented the same way
on Arm and x86. The only differences are:
- guest_handle_{from, to}_param(): while on x86 XEN_GUEST_HANDLE()
and XEN_GUEST_HANDLE_PARAM() are the same, they are not on Arm. It
is still fine to use the Arm implementation on x86.
- __clear_guest_offset(): Interestingly the prototype does not match
between the x86 and Arm. However, the Arm one is bogus. So the x86
implementation can be used.
- guest_handle{,_subrange}_okay(): They are validly differing
because Arm is only supporting auto-translated guest and therefore
handles are always valid.
While I'm fine in principle with such consolidation, I'm afraid I
really need to ask for some historical background to be added
here. It may very well be that there's a reason for the separation
(likely to be found in the removed ia64 or ppc ports), which may
then provide a hint at why future ports may want to have these
separated. If such reasons exist, I'd prefer to avoid the back and
forth between headers. What we could do in such a case is borrow
Linux'es asm-generic/ concept, and move the "typical"
implementation there. (And of course if there were no noticable
reasons for the split, the change as it is would be fine in
general; saying so without having looked at the details of it,
yet).
Looking at the history, ia64 and ppc used to include a common header
called xen/xencomm.h from asm/guest_access.h.
This has now disappeared with the removal of the two ports.
Regarding future arch, the fact arm and x86 gives me some confidence we
are unlikely going to get a new ABI for an arch. Do you see any reason to?
Cheers,
--
Julien Grall
Re: [PATCH 1/7] xen/guest_access: Add missing emacs magics
Hi Jan, On 07/04/2020 09:05, Jan Beulich wrote: On 04.04.2020 15:10, Julien Grall wrote: From: Julien Grall Add missing emacs magics for xen/guest_access.h and asm-x86/guest_access.h. Signed-off-by: Julien Grall I don't think these are "missing"; as per ./CODING_STYLE they're permitted, but not required (and I continue to question why one form of such a comment should be preferred over possible other forms other editors may support). Nevertheless, as this is in line with what we have elsewhere: I can remove the "missing" words if you prefer. Acked-by: Jan Beulich Thank you! Cheers, -- Julien Grall
[linux-5.4 test] 149514: tolerable FAIL - PUSHED
flight 149514 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/149514/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 149388 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 149388 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-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-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-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail 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-xl-multivcpu 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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail 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-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-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-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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linuxde850633a01fa06515a89a184d6e9769c160d932 baseline version: linuxad13e142e024aa194016a32de8b9ba058fe9a6af Last test of basis 149388 2020-04-03 14:19:58 Z5 days Testing same since 149514 2020-04-08 07:39:59 Z0 days1 attempts People who touched revisions under test: Alex Deucher Alexander Usyskin Amritha Nambiar Andrew Morton Barry Marson Bibby Hsieh Bjorn Helgaas Chanwoo Choi
[qemu-mainline test] 149510: tolerable FAIL - PUSHED
flight 149510 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/149510/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-stop fail REGR. vs. 144861 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 144861 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144861 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144861 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144861 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144861 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144861 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 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-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-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 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-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-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-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuuf3bac27cc1e303e1860cc55b9b6889ba39dee587 baseline version: qemuu7697ac55fcc6178fd8fd8aa22baed13a0c8ca942 Last test of basis 144861 2019-12-16 13:06:24 Z 114 days Failing since144880 2019-12-16 20:07:08 Z 113 days 326 attempts Testing same since 149510 2020-04-08 05:00:53 Z0 days1 attempts People who touched revisions under test: "Michael S. Tsirkin" Aarushi Mehta Adrian Moreno Adrien GRASSEIN Alberto Garcia Aleksandar Markovic Aleksandar Markovic Alex Bennée Alex Richardson Alex Williamson Alexander Bulekov Alexander Popov Alexey Kardashevskiy Alexey Romko Alistair Francis Alistair Francis
Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads
Hi Stefano,
On 03/04/2020 20:41, Stefano Stabellini wrote:
On Thu, 2 Apr 2020, Julien Grall wrote:
As you know I cannot reproduce the crash myself, I asked Peng and Wei
for help in that. I cannot be certain Jeff's patch makes a difference,
but looking at the code, if you open
xen/arch/arm/vgic-v3.c:__vgic_v3_distr_common_mmio_read you can see that
the range mistake is still there:
/* Read the active status of an IRQ via GICD/GICR is not supported */
case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVER):
case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
goto read_as_zero;
So a GICD_ISACTIVER of any register but the first should end up hitting
the default case:
default:
printk(XENLOG_G_ERR
"%pv: %s: unhandled read r%d offset %#08x\n",
v, name, dabt.reg, reg);
return 0;
}
Which returns 0 (IO_ABORT).
Would you be happy to have the range fixed to be:
case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
instead?
I don't particularly like it, but it is not going to make any difference
for Linux < 5.4. So I am not opposed to it.
However, I am a bit worry the vGIC is still going to be a pile of hack.
So I think we should continue the discussion about making it better.
This includes how to implement I{C, S}ACTIVER properly and what sort of
use-cases we want to support.
Cheers,
--
Julien Grall
Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote: > On 06.04.2020 12:57, Roger Pau Monne wrote: > > Introduce a specific flag to request a HVM guest linear TLB flush, > > which is an ASID/VPID tickle that forces a guest linear to guest > > physical TLB flush for all HVM guests. > > > > This was previously unconditionally done in each pre_flush call, but > > that's not required: HVM guests not using shadow don't require linear > > TLB flushes as Xen doesn't modify the guest page tables in that case > > (ie: when using HAP). Note that shadow paging code already takes care > > of issuing the necessary flushes when the shadow page tables are > > modified. > > > > In order to keep the previous behavior modify all shadow code TLB > > flushes to also flush the guest linear to physical TLB if the guest is > > HVM. I haven't looked at each specific shadow code TLB flush in order > > to figure out whether it actually requires a guest TLB flush or not, > > so there might be room for improvement in that regard. > > > > Also perform ASID/VPID flushes when modifying the p2m tables as it's a > > requirement for AMD hardware. Finally keep the flush in > > switch_cr3_cr4, as it's not clear whether code could rely on > > switch_cr3_cr4 also performing a guest linear TLB flush. A following > > patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to > > not be necessary. > > > > Signed-off-by: Roger Pau Monné > > Reviewed-by: Jan Beulich > with one really minor remark: > > > --- a/xen/arch/x86/mm/paging.c > > +++ b/xen/arch/x86/mm/paging.c > > @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d, > > > > p2m_unlock(p2m); > > > > -flush_tlb_mask(d->dirty_cpumask); > > +flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) | > > + FLUSH_HVM_ASID_CORE); > > In cases where one case is assumed to be more likely than the other > putting the more likely one first can be viewed as a mild hint to > the compiler, and hence an extra ! may be warranted in an if() or > a conditional expression. Here, however, I don't think we can > really consider one case more likely than the other, and hence I'd > suggest to avoid the !, flipping the other two expressions > accordingly. I may take the liberty to adjust this while committing > (if I'm to be the one). That's fine, thanks. Somehow '!hap -> flush' was clearer in my mind. Roger.
RE: [PATCH 1/3] Add support for generic notifier lists
> -Original Message- > From: Maximilian Heyne > Sent: 13 March 2020 12:33 > To: xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Paul Durrant > Subject: [PATCH 1/3] Add support for generic notifier lists > > From: Anthony Liguori > > Notifiers are data-less callbacks and a notifier list is a list of registered > notifiers that all are interested in a particular event. > > We'll use this in a few patches to implement mouse change notification. > > Signed-off-by: Anthony Liguori > --- > v1 -> v2 > - Do not do memory allocations by placing list nodes in notifier > > [cherry-picked from d1e70c5e6d1472856c52969301247fe8c3c8389d > conflicts: used the sys-qeue interface and added required > LIST_REMOVE_SAFE function to that] > Signed-off-by: Maximilian Heyne Reviewed-by: Paul Durrant
RE: [PATCH 2/3] Add exit notifiers.
> -Original Message- > From: Maximilian Heyne > Sent: 13 March 2020 12:33 > To: xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Paul Durrant > Subject: [PATCH 2/3] Add exit notifiers. > > From: Gerd Hoffmann > > Hook up any cleanup work which needs to be done here. Advantages over > using atexit(3): > > (1) You get passed in a pointer to the notifier. If you embed that > into your state struct you can use container_of() to get get your > state info. > (2) You can unregister, say when un-plugging a device. > > [ v2: move code out of #ifndef _WIN32 ] > > Signed-off-by: Anthony Liguori > (cherry picked from commit fd42deeb4cb42f90084046e3ebdb4383953195e3) > Signed-off-by: Maximilian Heyne Reviewed-by: Paul Durrant
RE: [PATCH 3/3] xen: cleanup IOREQ server on exit
> -Original Message-
> From: Maximilian Heyne
> Sent: 13 March 2020 12:33
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson ; Paul Durrant
> Subject: [PATCH 3/3] xen: cleanup IOREQ server on exit
>
> Use the backported Notifier interface to register an atexit handler to
> cleanup the IOREQ server. This is required since Xen commit a5a180f9
> ("x86/domain: don't destroy IOREQ servers on soft reset") is introduced
> which requires Qemu to explicitly close the IOREQ server.
>
> This is can be seen as a backport of ba7fdd64 ("xen: cleanup IOREQ
> server on exit").
>
> Signed-off-by: Maximilian Heyne
Reviewed-by: Paul Durrant
[ovmf test] 149513: all pass - PUSHED
flight 149513 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/149513/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf d6f99b2ac4296662720db76d7c23d224f5288df3 baseline version: ovmf 3ab0dadd6618b7808a27e65d83aa3668462afcf2 Last test of basis 149504 2020-04-08 01:40:39 Z0 days Testing same since 149513 2020-04-08 07:13:07 Z0 days1 attempts People who touched revisions under test: Guomin Jiang 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 3ab0dadd66..d6f99b2ac4 d6f99b2ac4296662720db76d7c23d224f5288df3 -> xen-tested-master
Re: [RFC PATCH 00/26] Runtime paravirt patching
On Wed, Apr 08, 2020 at 03:33:52PM +0200, Jürgen Groß wrote: > On 08.04.20 14:08, Peter Zijlstra wrote: > > On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote: > > > Mechanism: the patching itself is done using stop_machine(). That is > > > not ideal -- text_poke_stop_machine() was replaced with INT3+emulation > > > via text_poke_bp(), but I'm using this to address two issues: > > > 1) emulation in text_poke() can only easily handle a small set > > > of instructions and this is problematic for inlined pv-ops (and see > > > a possible alternatives use-case below.) > > > 2) paravirt patching might have inter-dependendent ops (ex. > > > lock.queued_lock_slowpath, lock.queued_lock_unlock are paired and > > > need to be updated atomically.) > > > > And then you hope that the spinlock state transfers.. That is that both > > implementations agree what an unlocked spinlock looks like. > > > > Suppose the native one was a ticket spinlock, where unlocked means 'head > > == tail' while the paravirt one is a test-and-set spinlock, where > > unlocked means 'val == 0'. > > > > That just happens to not be the case now, but it was for a fair while. > > Sure? This would mean that before spinlock-pvops are being set no lock > is allowed to be used in the kernel, because this would block the boot > time transition of the lock variant to use. Hurm.. true. I suppose I completely forgot how paravirt spinlocks looked before it got rewritten. > Another problem I'm seeing is that runtime pvops patching would rely on > the fact that stop_machine() isn't guarded by a spinlock. It can't be, stop_machine() relies on scheduling. But yes, that another variation of 'stuff uses spinlocks'.
[linux-linus test] 149505: regressions - FAIL
flight 149505 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/149505/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine 8 reboot fail REGR. vs. 149238 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 149238 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 149238 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 149238 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 149238 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 149238 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 149238 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 149238 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 149238 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149238 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 149238 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 149238 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 149238 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 149238 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 149238 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 149238 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail 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-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-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-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass
Re: [RFC PATCH 00/26] Runtime paravirt patching
Ankur Arora writes: > A KVM host (or another hypervisor) might advertise paravirtualized > features and optimization hints (ex KVM_HINTS_REALTIME) which might > become stale over the lifetime of the guest. For instance, the > host might go from being undersubscribed to being oversubscribed > (or the other way round) and it would make sense for the guest > switch pv-ops based on that. If your host changes his advertised behaviour then you want to fix the host setup or find a competent admin. > This lockorture splat that I saw on the guest while testing this is > indicative of the problem: > > [ 1136.461522] watchdog: BUG: soft lockup - CPU#8 stuck for 22s! > [lock_torture_wr:12865] > [ 1136.461542] CPU: 8 PID: 12865 Comm: lock_torture_wr Tainted: G W L > 5.4.0-rc7+ #77 > [ 1136.461546] RIP: 0010:native_queued_spin_lock_slowpath+0x15/0x220 > > (Caused by an oversubscribed host but using mismatched native pv_lock_ops > on the gues.) And this illustrates what? The fact that you used a misconfigured setup. > This series addresses the problem by doing paravirt switching at > runtime. You're not addressing the problem. Your fixing the symptom, which is wrong to begin with. > The alternative use-case is a runtime version of apply_alternatives() > (not posted with this patch-set) that can be used for some safe subset > of X86_FEATUREs. This could be useful in conjunction with the ongoing > late microcode loading work that Mihai Carabas and others have been > working on. This has been discussed to death before and there is no safe subset as long as this hasn't been resolved: https://lore.kernel.org/lkml/alpine.deb.2.21.1909062237580.1...@nanos.tec.linutronix.de/ Thanks, tglx
Re: [XEN PATCH v4 18/18] build, include: rework compat-build-header.py
On 31.03.2020 12:31, Anthony PERARD wrote: > Replace a mix of shell script and python script by all python script. > > Remove the unnecessary "grep -v '^# [0-9]'". It is to hide the > linemarkers generated by the preprocessor. But adding -P inhibit there > generation, thus the grep isn't needed anymore. > > gcc -E -P and clang -E -P have different behavior. While both don't > generates linemarkers, gcc also removes all empty lines while clang > keep them all. We don't need those empty lines, so we don't generates > them in the final compat/%.h headers. (This replace `uniq` which was > only de-duplicating empty line.) > > The only changes in the final generated headers it that they don't > have empty lines anymore. Making them harder to read? While typically no-one needs to look at their contents, in case of problems it helps if generated files are half way accessible to a human as well. Jan
[xen-unstable-smoke test] 149523: tolerable all pass - PUSHED
flight 149523 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/149523/ 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 9be0b2747bc7381c684cfbdd3fa2e40badefbeef baseline version: xen e013e8514389b739153016349e49f5a78e34ddf0 Last test of basis 149499 2020-04-07 21:00:41 Z0 days Testing same since 149523 2020-04-08 12:00:53 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Julien Grall Tamas K Lengyel 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-amd64pass 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 e013e85143..9be0b2747b 9be0b2747bc7381c684cfbdd3fa2e40badefbeef -> smoke
Re: [XEN PATCH v4 17/18] build, include: rework compat-build-source.py
On 31.03.2020 12:31, Anthony PERARD wrote: > Improvement are: > - give the path to xlat.lst as argument > - include `grep -v` in compat-build-source.py script, we don't need to > write this in several scripted language. > - have 'xlat.lst' path as a variable. The change looks okay, but I'm unsure whether it's really worthwhile. I specifically dislike the last point above, as it makes things less easy to read. I might be willing to ack a patch with this part taken out again; faod I'm not meaning to nak the patch in its current form, but I guess I'm also not going to ack it. Jan
[PATCH v2 5/5] x86_64/mm: map and unmap page tables in destroy_m2p_mapping
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed in v2:
- no point in re-mapping l2t because it is exactly the same as
l2_ro_mpt.
- point l2_ro_mpt to the entry instead of doing l2_table_offset() all
the time.
---
xen/arch/x86/x86_64/mm.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index ae8f4dd0b9..ec5269e7fc 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -268,7 +268,8 @@ static void destroy_m2p_mapping(struct mem_hotadd_info
*info)
unsigned long i, va, rwva;
unsigned long smap = info->spfn, emap = info->epfn;
-l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]);
+l3_ro_mpt = map_l3t_from_l4e(
+idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]);
/*
* No need to clean m2p structure existing before the hotplug
@@ -290,26 +291,30 @@ static void destroy_m2p_mapping(struct mem_hotadd_info
*info)
continue;
}
-l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
-if (!(l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT))
+l2_ro_mpt = map_l2t_from_l3e(l3_ro_mpt[l3_table_offset(va)]) +
+l2_table_offset(va);
+if ( !(l2e_get_flags(*l2_ro_mpt) & _PAGE_PRESENT) )
{
i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
(1UL << (L2_PAGETABLE_SHIFT - 3)) ;
+UNMAP_DOMAIN_PAGE(l2_ro_mpt);
continue;
}
-pt_pfn = l2e_get_pfn(l2_ro_mpt[l2_table_offset(va)]);
+pt_pfn = l2e_get_pfn(*l2_ro_mpt);
if ( hotadd_mem_valid(pt_pfn, info) )
{
destroy_xen_mappings(rwva, rwva + (1UL << L2_PAGETABLE_SHIFT));
-l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
-l2e_write(_ro_mpt[l2_table_offset(va)], l2e_empty());
+l2e_write(l2_ro_mpt, l2e_empty());
}
i = ( i & ~((1UL << (L2_PAGETABLE_SHIFT - 3)) - 1)) +
(1UL << (L2_PAGETABLE_SHIFT - 3));
+UNMAP_DOMAIN_PAGE(l2_ro_mpt);
}
+UNMAP_DOMAIN_PAGE(l3_ro_mpt);
+
destroy_compat_m2p_mapping(info);
/* Brute-Force flush all TLB */
--
2.24.1.AMZN
[PATCH v2 3/5] x86_64/mm: map and unmap page tables in share_hotadd_m2p_table
From: Wei Liu
Fetch lYe by mapping and unmapping lXe instead of using the direct map,
which is now done via the lYe_from_lXe() helpers.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed in v2:
- the introduction of the macros is now lifted to a previous patch.
---
xen/arch/x86/x86_64/mm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 8e0caa7327..d23c7e4f5b 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -167,14 +167,14 @@ static int share_hotadd_m2p_table(struct mem_hotadd_info
*info)
v += n << PAGE_SHIFT )
{
n = L2_PAGETABLE_ENTRIES * L1_PAGETABLE_ENTRIES;
-l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-l3_table_offset(v)];
+l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+ l3_table_offset(v));
if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
continue;
if ( !(l3e_get_flags(l3e) & _PAGE_PSE) )
{
n = L1_PAGETABLE_ENTRIES;
-l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+l2e = l2e_from_l3e(l3e, l2_table_offset(v));
if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
continue;
m2p_start_mfn = l2e_get_mfn(l2e);
@@ -195,11 +195,11 @@ static int share_hotadd_m2p_table(struct mem_hotadd_info
*info)
v != RDWR_COMPAT_MPT_VIRT_END;
v += 1 << L2_PAGETABLE_SHIFT )
{
-l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
-l3_table_offset(v)];
+l3e = l3e_from_l4e(idle_pg_table[l4_table_offset(v)],
+ l3_table_offset(v));
if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
continue;
-l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
+l2e = l2e_from_l3e(l3e, l2_table_offset(v));
if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
continue;
m2p_start_mfn = l2e_get_mfn(l2e);
--
2.24.1.AMZN
[PATCH v2 2/5] x86_64/mm: map and unmap page tables in m2p_mapped
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed in v2:
- avoid adding goto labels, simply get the PTE and unmap quickly.
- code style fixes.
---
xen/arch/x86/x86_64/mm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index cee836ec37..8e0caa7327 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -129,14 +129,14 @@ static mfn_t alloc_hotadd_mfn(struct mem_hotadd_info
*info)
static int m2p_mapped(unsigned long spfn)
{
unsigned long va;
-l3_pgentry_t *l3_ro_mpt;
-l2_pgentry_t *l2_ro_mpt;
+l3_pgentry_t l3e_ro_mpt;
+l2_pgentry_t l2e_ro_mpt;
va = RO_MPT_VIRT_START + spfn * sizeof(*machine_to_phys_mapping);
-l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
+l3e_ro_mpt = l3e_from_l4e(idle_pg_table[l4_table_offset(va)],
+ l3_table_offset(va));
-switch ( l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
- (_PAGE_PRESENT |_PAGE_PSE))
+switch ( l3e_get_flags(l3e_ro_mpt) & (_PAGE_PRESENT | _PAGE_PSE) )
{
case _PAGE_PSE|_PAGE_PRESENT:
return M2P_1G_MAPPED;
@@ -146,9 +146,9 @@ static int m2p_mapped(unsigned long spfn)
default:
return M2P_NO_MAPPED;
}
-l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
+l2e_ro_mpt = l2e_from_l3e(l3e_ro_mpt, l2_table_offset(va));
-if (l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) & _PAGE_PRESENT)
+if ( l2e_get_flags(l2e_ro_mpt) & _PAGE_PRESENT )
return M2P_2M_MAPPED;
return M2P_NO_MAPPED;
--
2.24.1.AMZN
[PATCH v2 0/5] use new API for Xen page tables
From: Hongyan Xia This small series is basically just rewriting functions using the new API to map and unmap PTEs. Each patch is independent. Apart from mapping and unmapping page tables, no other functional change intended. --- Changed in v2: - I kept UNMAP_DOMAIN_PAGE() for now in v2, but I if people say in some cases it is an overkill and unmap_domain_page() should be used, I am okay with that and can make the change. - code cleanup and style fixes. - unmap as early as possible. Wei Liu (5): x86/shim: map and unmap page tables in replace_va_mapping x86_64/mm: map and unmap page tables in m2p_mapped x86_64/mm: map and unmap page tables in share_hotadd_m2p_table x86_64/mm: map and unmap page tables in destroy_compat_m2p_mapping x86_64/mm: map and unmap page tables in destroy_m2p_mapping xen/arch/x86/pv/shim.c | 9 --- xen/arch/x86/x86_64/mm.c | 55 ++ xen/include/asm-x86/page.h | 13 + 3 files changed, 50 insertions(+), 27 deletions(-) -- 2.24.1.AMZN
[PATCH v2 4/5] x86_64/mm: map and unmap page tables in destroy_compat_m2p_mapping
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed in v2:
- there is pretty much no point in keeping l3_ro_mpt mapped, just fetch
the l3e instead, which also cleans up the code.
---
xen/arch/x86/x86_64/mm.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index d23c7e4f5b..ae8f4dd0b9 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -220,7 +220,7 @@ static void destroy_compat_m2p_mapping(struct
mem_hotadd_info *info)
unsigned long i, va, rwva, pt_pfn;
unsigned long smap = info->spfn, emap = info->spfn;
-l3_pgentry_t *l3_ro_mpt;
+l3_pgentry_t l3e_ro_mpt;
l2_pgentry_t *l2_ro_mpt;
if ( smap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2)
)
@@ -229,11 +229,13 @@ static void destroy_compat_m2p_mapping(struct
mem_hotadd_info *info)
if ( emap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2)
)
emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
-l3_ro_mpt =
l4e_to_l3e(idle_pg_table[l4_table_offset(HIRO_COMPAT_MPT_VIRT_START)]);
+l3e_ro_mpt = l3e_from_l4e(idle_pg_table[
+ l4_table_offset(HIRO_COMPAT_MPT_VIRT_START)],
+ l3_table_offset(HIRO_COMPAT_MPT_VIRT_START));
-
ASSERT(l3e_get_flags(l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)]) &
_PAGE_PRESENT);
+ASSERT(l3e_get_flags(l3e_ro_mpt) & _PAGE_PRESENT);
-l2_ro_mpt =
l3e_to_l2e(l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)]);
+l2_ro_mpt = map_l2t_from_l3e(l3e_ro_mpt);
for ( i = smap; i < emap; )
{
@@ -255,6 +257,8 @@ static void destroy_compat_m2p_mapping(struct
mem_hotadd_info *info)
i += 1UL << (L2_PAGETABLE_SHIFT - 2);
}
+UNMAP_DOMAIN_PAGE(l2_ro_mpt);
+
return;
}
--
2.24.1.AMZN
[PATCH v2 1/5] x86/shim: map and unmap page tables in replace_va_mapping
From: Wei Liu
Also, introduce lYe_from_lXe() macros which do not rely on the direct
map when walking page tables. Unfortunately, they cannot be inline
functions due to the header dependency on domain_page.h, so keep them as
macros just like map_lYt_from_lXe().
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed in v2:
- unmap as early as possible instead of unmapping all at the end.
- use lYe_from_lXe() macros and lift them from a later patch to this
patch.
- const qualify pointers in new macros.
---
xen/arch/x86/pv/shim.c | 9 +
xen/include/asm-x86/page.h | 13 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index ed2ece8a8a..28d2076065 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -168,16 +168,17 @@ const struct platform_bad_page *__init
pv_shim_reserved_pages(unsigned int *size
static void __init replace_va_mapping(struct domain *d, l4_pgentry_t *l4start,
unsigned long va, mfn_t mfn)
{
-l4_pgentry_t *pl4e = l4start + l4_table_offset(va);
-l3_pgentry_t *pl3e = l4e_to_l3e(*pl4e) + l3_table_offset(va);
-l2_pgentry_t *pl2e = l3e_to_l2e(*pl3e) + l2_table_offset(va);
-l1_pgentry_t *pl1e = l2e_to_l1e(*pl2e) + l1_table_offset(va);
+l4_pgentry_t l4e = l4start[l4_table_offset(va)];
+l3_pgentry_t l3e = l3e_from_l4e(l4e, l3_table_offset(va));
+l2_pgentry_t l2e = l2e_from_l3e(l3e, l2_table_offset(va));
+l1_pgentry_t *pl1e = map_l1t_from_l2e(l2e) + l1_table_offset(va);
struct page_info *page = mfn_to_page(l1e_get_mfn(*pl1e));
put_page_and_type(page);
*pl1e = l1e_from_mfn(mfn, (!is_pv_32bit_domain(d) ? L1_PROT
: COMPAT_L1_PROT));
+UNMAP_DOMAIN_PAGE(pl1e);
}
static void evtchn_reserve(struct domain *d, unsigned int port)
diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index c98d8f5ede..1e16f3980d 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -196,6 +196,19 @@ static inline l4_pgentry_t l4e_from_paddr(paddr_t pa,
unsigned int flags)
#define map_l2t_from_l3e(x)(l2_pgentry_t
*)map_domain_page(l3e_get_mfn(x))
#define map_l3t_from_l4e(x)(l3_pgentry_t
*)map_domain_page(l4e_get_mfn(x))
+/* Unlike lYe_to_lXe(), lXe_from_lYe() do not rely on the direct map. */
+#define l2e_from_l3e(l3e, offset) ({\
+const l2_pgentry_t *l2t = map_l2t_from_l3e(l3e);\
+l2_pgentry_t l2e = l2t[offset]; \
+UNMAP_DOMAIN_PAGE(l2t); \
+l2e; })
+
+#define l3e_from_l4e(l4e, offset) ({\
+const l3_pgentry_t *l3t = map_l3t_from_l4e(l4e);\
+l3_pgentry_t l3e = l3t[offset]; \
+UNMAP_DOMAIN_PAGE(l3t); \
+l3e; })
+
/* Given a virtual address, get an entry offset into a page table. */
#define l1_table_offset(a) \
(((a) >> L1_PAGETABLE_SHIFT) & (L1_PAGETABLE_ENTRIES - 1))
--
2.24.1.AMZN
Re: [XEN PATCH v4 10/18] xen/build: use if_changed on built_in.o
On 08.04.2020 15:13, Andrew Cooper wrote: > On 08/04/2020 13:40, Jan Beulich wrote: >> On 31.03.2020 12:30, Anthony PERARD wrote: >>> --- a/xen/Rules.mk >>> +++ b/xen/Rules.mk >>> @@ -130,15 +130,24 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk >>> c_flags += $(CFLAGS-y) >>> a_flags += $(CFLAGS-y) $(AFLAGS-y) >>> >>> -built_in.o: $(obj-y) $(extra-y) >>> -ifeq ($(obj-y),) >>> - $(CC) $(c_flags) -c -x c /dev/null -o $@ >>> -else >>> +quiet_cmd_ld_builtin = LD $@ >>> ifeq ($(CONFIG_LTO),y) >>> - $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^) >>> +cmd_ld_builtin = \ >>> +$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) >>> else >>> - $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^) >>> +cmd_ld_builtin = \ >>> +$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) >>> endif >> How about going yet one step further and doing away with the >> ifeq here altogether: >> >> cmd_ld_builtin-y = \ >> $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) >> cmd_ld_builtin-$(CONFIG_LTO) = \ >> $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) > > Please don't. > > Logic like this is substantially harder to follow than a plain if/else > construct, and clarity is of far higher importance than optimising the > line count in the build system. I could maybe see the argument if the two definitions were far apart. This suggestion isn't about line count at all, but about clarity. In particular because of the need to use ifeq(,) rather than simple "if" constructs, I view this list model as the better alternative in all cases where it can be made use of. > This trick only works for trivial cases, and interferes with diff's when > the logic inevitably becomes less trivial. It may, but whether it actually will can't be known until such time as it would get touched. The suggested model may very well also be suitable then. Anyway, Anthony, I'm not going to insist. This is just another aspect where we would better generally settle on the preferred style to use. Jan
Re: [RFC PATCH 00/26] Runtime paravirt patching
On 08.04.20 14:08, Peter Zijlstra wrote: On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote: Mechanism: the patching itself is done using stop_machine(). That is not ideal -- text_poke_stop_machine() was replaced with INT3+emulation via text_poke_bp(), but I'm using this to address two issues: 1) emulation in text_poke() can only easily handle a small set of instructions and this is problematic for inlined pv-ops (and see a possible alternatives use-case below.) 2) paravirt patching might have inter-dependendent ops (ex. lock.queued_lock_slowpath, lock.queued_lock_unlock are paired and need to be updated atomically.) And then you hope that the spinlock state transfers.. That is that both implementations agree what an unlocked spinlock looks like. Suppose the native one was a ticket spinlock, where unlocked means 'head == tail' while the paravirt one is a test-and-set spinlock, where unlocked means 'val == 0'. That just happens to not be the case now, but it was for a fair while. Sure? This would mean that before spinlock-pvops are being set no lock is allowed to be used in the kernel, because this would block the boot time transition of the lock variant to use. Another problem I'm seeing is that runtime pvops patching would rely on the fact that stop_machine() isn't guarded by a spinlock. Juergen
Re: [XEN PATCH v4 16/18] build,xsm: Fix multiple call
On 31.03.2020 12:31, Anthony PERARD wrote: > Both script mkflask.sh and mkaccess_vector.sh generates multiple > files. Exploits the 'multi-target pattern rule' trick to call each > scripts only once. Isn't this a general fix, which may even want backporting? If so, this would better be at or near the beginning of the series. > --- a/xen/xsm/flask/Makefile > +++ b/xen/xsm/flask/Makefile > @@ -26,14 +26,14 @@ mkflask := policy/mkflask.sh > quiet_cmd_mkflask = MKFLASK $@ > cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include $(FLASK_H_DEPEND) > > -$(FLASK_H_FILES): $(FLASK_H_DEPEND) $(mkflask) FORCE > +$(patsubst include/%,\%/%,$(FLASK_H_FILES)): $(FLASK_H_DEPEND) $(mkflask) > FORCE Since what $(FLASK_H_FILES) contains is well under our control, how about the simpler $(subst include/,%/,$(FLASK_H_FILES)): ... ? Preferably with this and preferably with it moved ahead Reviewed-by: Jan Beulich Jan
Re: [XEN PATCH v4 10/18] xen/build: use if_changed on built_in.o
On 08/04/2020 13:40, Jan Beulich wrote: > On 31.03.2020 12:30, Anthony PERARD wrote: >> --- a/xen/Rules.mk >> +++ b/xen/Rules.mk >> @@ -130,15 +130,24 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk >> c_flags += $(CFLAGS-y) >> a_flags += $(CFLAGS-y) $(AFLAGS-y) >> >> -built_in.o: $(obj-y) $(extra-y) >> -ifeq ($(obj-y),) >> -$(CC) $(c_flags) -c -x c /dev/null -o $@ >> -else >> +quiet_cmd_ld_builtin = LD $@ >> ifeq ($(CONFIG_LTO),y) >> -$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^) >> +cmd_ld_builtin = \ >> +$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) >> else >> -$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^) >> +cmd_ld_builtin = \ >> +$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) >> endif > How about going yet one step further and doing away with the > ifeq here altogether: > > cmd_ld_builtin-y = \ > $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) > cmd_ld_builtin-$(CONFIG_LTO) = \ > $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) Please don't. Logic like this is substantially harder to follow than a plain if/else construct, and clarity is of far higher importance than optimising the line count in the build system. This trick only works for trivial cases, and interferes with diff's when the logic inevitably becomes less trivial. LTO support in particular needs a complete overhaul, but there is no way I'm going to touch that with a barge pole until this series is in place. ~Andrew
Re: [XEN PATCH v4 15/18] xen/build: use if_changed to build guest_%.o
On 31.03.2020 12:30, Anthony PERARD wrote: > Use if_changed for building all guest_%.o objects, and make use of > command that already exist. > > This patch make a change to the way guest_%.o files are built, and now > run the same commands that enforce unique symbols. But with patch > "xen,symbols: rework file symbols selection", ./symbols should still > select the file symbols directive intended to be used for guest_%.o > objects. I'm having trouble making the connection between the change to the symbols tool and the adjustments made here: > --- a/xen/arch/x86/mm/Makefile > +++ b/xen/arch/x86/mm/Makefile > @@ -11,11 +11,13 @@ obj-y += p2m.o p2m-pt.o > obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o > obj-y += paging.o > > -guest_walk_%.o: guest_walk.c Makefile > - $(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@ The original rules didn't do anything special to arrange for the resulting kallsyms names; these arrangements instead live at the top of the respective source files, in the form of asm()-s. Jan
Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
On 31.03.2020 12:30, Anthony PERARD wrote: > We want to use the same rune to build mm/*/guest_*.o as the one use to > build every other *.o object. The consequence it that file symbols that > the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y. > > (1) Currently we have those two file symbols: > guest_walk.c > guest_walk_2.o > (2) with CONFIG_ENFORCE_UNIQUE_SYMBOLS used on guest_walk.c, we will have: > arch/x86/mm/guest_walk.c > guest_walk_2.o > > The order in which those symbols are present may be different. > > Currently, in case (1) ./symbols chooses the *.o symbol (object file > name). But in case (2), may choose the *.c symbol (source file name with > path component) if it is first > > We want to have ./symbols choose the object file name symbol in both > cases. I guess the reason for wanting this is somehow connected to the statement at the beginning of the description, but I can't seem to be able to make the connection. > So this patch changes that ./symbols prefer the "object file > name" symbol over the "source file name with path component" symbols. > > The new intended order of preference is: > - first object file name symbol > - first source file name with path components symbol > - last source file name without any path component symbol Isn't this going to lead to ambiguities again when CONFIG_ENFORCE_UNIQUE_SYMBOLS? Several object files (in different dirs) are named the same, after all. Static symbols with the same name in such objects would hence resolve to the same kallsyms name. Jan
Re: [XEN PATCH v4 12/18] xen/build: factorise generation of the linker scripts
On 31.03.2020 12:30, Anthony PERARD wrote:
> In Arm and X86 makefile, generating the linker script is the same, so
> we can simply have both call the same macro.
>
> We need to add *.lds files into extra-y so that Rules.mk can find the
> .*.cmd dependency file and load it.
>
> Change made to the command line:
> - Use of $(CPP) instead of $(CC) -E
> - Remove -Ui386.
> We don't compile Xen for i386 anymore, so that macro is never
> defined. Also it doesn't make sense on Arm.
>
> Signed-off-by: Anthony PERARD
> ---
>
> Notes:
> v4:
> - fix rebuild by adding FORCE as dependency
> - Use $(CPP)
> - remove -Ui386
> - avoid using "define" for cmd_cc_lds_S, as adding '; \' on each line is
> still mandatory for if_changed (or cmd) macro to work.
I still don't believe in there being a need for "; \" there. This
actually breaks things, after all:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -236,6 +236,12 @@ cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags))
> $< -o $@
> %.s: %.S FORCE
> $(call if_changed,cpp_s_S)
>
> +# Linker scripts, .lds.S -> .lds
> +quiet_cmd_cc_lds_S = LDS $@
> +cmd_cc_lds_S = $(CPP) -P $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<; \
> +sed -e 's/.*\.lds\.o:/$(@F):/g' <$(dot-target).d >$(dot-target).d.new; \
> +mv -f $(dot-target).d.new $(dot-target).d
if $(CPP) or sed fail, previously the whole rule would have failed,
which no longer is the case with your use of semicolons. There
ought to be a solution to this, ideally one better than adding
"set -e" as the first command ("define" would at least deal with
the multi-line make issue, but without it being clear to me why the
semicolons would be needed I don't think I can suggest anything
there at the moment).
Jan
Re: [XEN PATCH v4 10/18] xen/build: use if_changed on built_in.o
On 31.03.2020 12:30, Anthony PERARD wrote: > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -130,15 +130,24 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk > c_flags += $(CFLAGS-y) > a_flags += $(CFLAGS-y) $(AFLAGS-y) > > -built_in.o: $(obj-y) $(extra-y) > -ifeq ($(obj-y),) > - $(CC) $(c_flags) -c -x c /dev/null -o $@ > -else > +quiet_cmd_ld_builtin = LD $@ > ifeq ($(CONFIG_LTO),y) > - $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^) > +cmd_ld_builtin = \ > +$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) > else > - $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^) > +cmd_ld_builtin = \ > +$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) > endif How about going yet one step further and doing away with the ifeq here altogether: cmd_ld_builtin-y = \ $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) cmd_ld_builtin-$(CONFIG_LTO) = \ $(LD_LTO) -r -o $@ $(filter-out $(extra-y),$(real-prereqs)) > +quiet_cmd_cc_builtin = LD $@ > +cmd_cc_builtin = \ > +$(CC) $(XEN_CFLAGS) -c -x c /dev/null -o $@ > + > +built_in.o: $(obj-y) $(extra-y) FORCE > +ifeq ($(obj-y),) > + $(call if_changed,cc_builtin) > +else > + $(call if_changed,ld_builtin) $(call if_changed,ld_builtin-y) ? As an aside (not something you introduce) this makes it even more prominent that the use of $(XEN_LDFLAGS) is asymmetric here, for whatever reason (if any). Of course there's other redundancy between the two commands which could be eliminated. Jan
Re: [RFC PATCH 00/26] Runtime paravirt patching
On 08.04.20 07:02, Ankur Arora wrote: A KVM host (or another hypervisor) might advertise paravirtualized features and optimization hints (ex KVM_HINTS_REALTIME) which might become stale over the lifetime of the guest. For instance, the Then this hint is wrong if it can't be guaranteed. host might go from being undersubscribed to being oversubscribed (or the other way round) and it would make sense for the guest switch pv-ops based on that. I think using pvops for such a feature change is just wrong. What comes next? Using pvops for being able to migrate a guest from an Intel to an AMD machine? ... There are four main sets of patches in this series: 1. PV-ops management (patches 1-10, 20): mostly infrastructure and refactoring pieces to make paravirt patching usable at runtime. For the most part scoped under CONFIG_PARAVIRT_RUNTIME. Patches 1-7, to persist part of parainstructions in memory: "x86/paravirt: Specify subsection in PVOP macros" "x86/paravirt: Allow paravirt patching post-init" "x86/paravirt: PVRTOP macros for PARAVIRT_RUNTIME" "x86/alternatives: Refactor alternatives_smp_module* "x86/alternatives: Rename alternatives_smp*, smp_alt_module "x86/alternatives: Remove stale symbols "x86/paravirt: Persist .parainstructions.runtime" Patches 8-10, develop the inerfaces to safely switch pv-ops: "x86/paravirt: Stash native pv-ops" "x86/paravirt: Add runtime_patch()" "x86/paravirt: Add primitives to stage pv-ops" Patch 20 enables switching of pv_lock_ops: "x86/paravirt: Enable pv-spinlocks in runtime_patch()" 2. Non-emulated text poking (patches 11-19) Patches 11-13 are mostly refactoring to split __text_poke() into map, unmap and poke/memcpy phases with the poke portion being re-entrant "x86/alternatives: Remove return value of text_poke*()" "x86/alternatives: Use __get_unlocked_pte() in text_poke()" "x86/alternatives: Split __text_poke()" Patches 15, 17 add the actual poking state-machine: "x86/alternatives: Non-emulated text poking" "x86/alternatives: Add patching logic in text_poke_site()" with patches 14 and 18 containing the pieces for BP handling: "x86/alternatives: Handle native insns in text_poke_loc*()" "x86/alternatives: Handle BP in non-emulated text poking" and patch 19 provides the ability to use the state-machine above in an NMI context (fixes some potential deadlocks when handling inter- dependent operations and multiple NMIs): "x86/alternatives: NMI safe runtime patching". Patch 16 provides the interface (paravirt_runtime_patch()) to use the poking mechanism developed above and patch 21 adds a selftest: "x86/alternatives: Add paravirt patching at runtime" "x86/alternatives: Paravirt runtime selftest" 3. KVM guest changes to be able to use this (patches 22-23,25-26): "kvm/paravirt: Encapsulate KVM pv switching logic" "x86/kvm: Add worker to trigger runtime patching" "x86/kvm: Guest support for dynamic hints" "x86/kvm: Add hint change notifier for KVM_HINT_REALTIME". 4. KVM host changes to notify the guest of a change (patch 24): "x86/kvm: Support dynamic CPUID hints" Testing: With paravirt patching, the code is mostly stable on Intel and AMD systems under kernbench and locktorture with paravirt toggling (with, without synthetic NMIs) in the background. Queued spinlock performance for locktorture is also on expected lines: [ 1533.221563] Writes: Total: 1048759000 Max/Min: 0/0 Fail: 0 # toggle PV spinlocks [ 1594.713699] Writes: Total: 660545 Max/Min: 0/0 Fail: 0 # PV spinlocks (in ~60 seconds) = 62,901,545 # toggle native spinlocks [ 1656.117175] Writes: Total: 111340 Max/Min: 0/0 Fail: 0 # native spinlocks (in ~60 seconds) = 2,228,295 The alternatives testing is more limited with it being used to rewrite mostly harmless X86_FEATUREs with load in the background. Patches also at: ssh://g...@github.com/terminus/linux.git alternatives-rfc-upstream-v1 Please review. Thanks Ankur [1] The precise change in memory footprint depends on config options but the following example inlines queued_spin_unlock() (which forms the bulk of the added state). The added footprint is the size of the .parainstructions.runtime section: $ objdump -h vmlinux|grep .parainstructions Idx Name Size VMA LMAFile-off Algn 27 .parainstructions 0001013c 82895000 02895000 01c95000 2**3 28 .parainstructions.runtime cd2c 828a5140 028a5140 01ca5140 2**3 $ size vmlinux text data bssdec hex filename 13726196 12302814 14094336 40123346 2643bd2 vmlinux Ankur Arora (26): x86/paravirt: Specify subsection in PVOP macros x86/paravirt: Allow paravirt patching post-init x86/paravirt: PVRTOP macros for PARAVIRT_RUNTIME x86/alternatives: Refactor
Re: [RFC PATCH 00/26] Runtime paravirt patching
On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote: > A KVM host (or another hypervisor) might advertise paravirtualized > features and optimization hints (ex KVM_HINTS_REALTIME) which might > become stale over the lifetime of the guest. For instance, the > host might go from being undersubscribed to being oversubscribed > (or the other way round) and it would make sense for the guest > switch pv-ops based on that. So what, the paravirt spinlock stuff works just fine when you're not oversubscribed. > We keep an interesting subset of pv-ops (pv_lock_ops only for now, > but PV-TLB ops are also good candidates) The PV-TLB ops also work just fine when not oversubscribed. IIRC kvm_flush_tlb_others() is pretty much the same in that case. > in .parainstructions.runtime, > while discarding the .parainstructions as usual at init. This is then > used for switching back and forth between native and paravirt mode. > ([1] lists some representative numbers of the increased memory > footprint.) > > Mechanism: the patching itself is done using stop_machine(). That is > not ideal -- text_poke_stop_machine() was replaced with INT3+emulation > via text_poke_bp(), but I'm using this to address two issues: > 1) emulation in text_poke() can only easily handle a small set > of instructions and this is problematic for inlined pv-ops (and see > a possible alternatives use-case below.) > 2) paravirt patching might have inter-dependendent ops (ex. > lock.queued_lock_slowpath, lock.queued_lock_unlock are paired and > need to be updated atomically.) And then you hope that the spinlock state transfers.. That is that both implementations agree what an unlocked spinlock looks like. Suppose the native one was a ticket spinlock, where unlocked means 'head == tail' while the paravirt one is a test-and-set spinlock, where unlocked means 'val == 0'. That just happens to not be the case now, but it was for a fair while. > The alternative use-case is a runtime version of apply_alternatives() > (not posted with this patch-set) that can be used for some safe subset > of X86_FEATUREs. This could be useful in conjunction with the ongoing > late microcode loading work that Mihai Carabas and others have been > working on. The whole late-microcode loading stuff is crazy already; you're making it take double bonghits. > Also, there are points of similarity with the ongoing static_call work > which does rewriting of indirect calls. Only in so far as that code patching is involved. An analogy would be comparing having a beer with shooting dope. They're both 'drugs'. > The difference here is that > we need to switch a group of calls atomically and given that > some of them can be inlined, need to handle a wider variety of opcodes. > > To patch safely we need to satisfy these constraints: > > - No references to insn sequences under replacement on any kernel stack >once replacement is in progress. Without this constraint we might end >up returning to an address that is in the middle of an instruction. Both ftrace and optprobes have that issue, neither of them are quite as crazy as this. > - handle inter-dependent ops: as above, lock.queued_lock_unlock(), >lock.queued_lock_slowpath() and the rest of the pv_lock_ops are >a good example. While I'm sure this is a fun problem, why are we solving it? > - handle a broader set of insns than CALL and JMP: some pv-ops end up >getting inlined. Alternatives can contain arbitrary instructions. So can optprobes. > - locking operations can be called from interrupt handlers which means >we cannot trivially use IPIs for flushing. Heck, some NMI handlers use locks.. > Handling these, necessitates that target pv-ops not be preemptible. I don't think that is a correct inferrence. > Once that is a given (for safety these need to be explicitly whitelisted > in runtime_patch()), use a state-machine with the primary CPU doing the > patching and secondary CPUs in a sync_core() loop. > > In case we hit an INT3/BP (in NMI or thread-context) we makes forward > progress by continuing the patching instead of emulating. > > One remaining issue is inter-dependent pv-ops which are also executed in > the NMI handler -- patching can potentially deadlock in case of multiple > NMIs. Handle these by pushing some of this work in the NMI handler where > we know it will be uninterrupted. I'm just seeing a lot of bonghits without sane rationale. Why is any of this important?
Re: [XEN PATCH v4 08/18] xen/build: introduce if_changed and if_changed_rule
On 31.03.2020 12:30, Anthony PERARD wrote: > The if_changed macro from Linux, in addition to check if any files > needs an update, check if the command line has changed since the last > invocation. The latter will force a rebuild if any options to the > executable have changed. > > if_changed_rule checks dependencies like if_changed, but execute > rule_$(1) instead of cmd_$(1) when a target needs to be rebuilt. A rule_ > macro can call more than one cmd_ macro. One of the cmd_ macro in a > rule need to be call using a macro that record the command line, so > cmd_and_record is introduced. It is similar to cmd_and_fixup from > Linux but without a call to fixdep which we don't have yet. (We will > later replace cmd_and_record by cmd_and_fixup.) > > Example of a rule_ macro: > define rule_cc_o_c > $(call cmd_and_record,cc_o_o) > $(call cmd,objcopy) > endef > > This needs one of the call to use cmd_and_record, otherwise no .*.cmd > file will be created, and the target will keep been rebuilt. > > In order for if_changed to works correctly, we need to load the .%.cmd > files that the macro generates, this is done by adding targets in to > the $(targets) variable. We use intermediate_targets to add %.init.o > dependency %.o to target since there aren't in obj-y. > > We also add $(MAKECMDGOALS) to targets so that when running for > example `make common/memory.i`, make will load the associated .%.cmd > dependency file. > > Beside the if_changed*, we import the machinery used for a "beautify > output". The important one is when running make with V=2 which help to > debug the makefiles by printing why a target is been rebuilt, via the > $(echo-why) macro. > > if_changed and if_changed_rule aren't used yet. > > Most of this code is copied from Linux v5.4, including the > documentation. > > Signed-off-by: Anthony PERARD Acked-by: Jan Beulich with ... > --- a/docs/misc/xen-makefiles/makefiles.rst > +++ b/docs/misc/xen-makefiles/makefiles.rst > @@ -85,3 +85,102 @@ Compilation flags > > CFLAGS-y specifies options for compiling with $(CC). > AFLAGS-y specifies assembler options. > + > + > +Build system infrastructure > +=== > + > +This chapter describe some of the macro used when building Xen. > + > +Macros > +-- > + > + > +if_changed > + if_changed is the infrastructure used for the following commands. > + > + Usage:: > + > + target: source(s) FORCE > + $(call if_changed,ld/objcopy/...) > + > + When the rule is evaluated, it is checked to see if any files > + need an update, or the command line has changed since the last > + invocation. The latter will force a rebuild if any options > + to the executable have changed. > + Any target that utilises if_changed must be listed in $(targets), > + otherwise the command line check will fail, and the target will > + always be built. > + if_changed may be used in conjunction with custom commands as > + defined in "Custom commands". > + > + Note: It is a typical mistake to forget the FORCE prerequisite. > + Another common pitfall is that whitespace is sometimes > + significant; for instance, the below will fail (note the extra space > + after the comma):: > + > + target: source(s) FORCE > + > + **WRONG!** $(call if_changed, ld/objcopy/...) > + > +Note: > + if_changed should not be used more than once per target. > + It stores the executed command in a corresponding .cmd ... the odd mixing of tabs and spaces here taken care of (I didn't check if there are more) and ... > + > +file and multiple calls would result in overwrites and ... the apparently stray blank like here dropped. Jan
Re: [XEN PATCH v4 07/18] build: Introduce documentation for xen Makefiles
On 31.03.2020 12:30, Anthony PERARD wrote: > This start explainning the variables that can be used in the many > Makefiles in xen/. > > Most of the document copies and modifies text from Linux v5.4 document > linux.git/Documentation/kbuild/makefiles.rst. Modification are mostly > to avoid mentioning kbuild. Thus I've added the SPDX tag which was > only in index.rst in linux.git. > > Signed-off-by: Anthony PERARD Acked-by: Jan Beulich with one question: > +Compilation flags > +- > + > +CFLAGS-y and AFLAGS-y > + These two flags apply only to the makefile in which they > + are assigned. They are used for all the normal cc, as and ld > + invocations happening during a recursive build. > + > + $(CFLAGS-y) is necessary because the top Makefile owns the > + variable $(XEN_CFLAGS) and uses it for compilation flags for the > + entire tree. And the variable $(CFLAGS) is modified by Config.mk > + which evaluated in every subdirs. > + > + CFLAGS-y specifies options for compiling with $(CC). > + AFLAGS-y specifies assembler options. Is it perhaps worth mentioning that c_flags and a_flags should not be fiddled with by individual Makefile-s? Jan
Re: [XEN PATCH v4 06/18] xen/build: have the root Makefile generates the CFLAGS
On 31.03.2020 12:30, Anthony PERARD wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -115,6 +115,64 @@ $(KCONFIG_CONFIG):
> include/config/%.conf include/config/%.conf.cmd: $(KCONFIG_CONFIG)
> $(MAKE) $(kconfig) syncconfig
>
> +ifeq ($(CONFIG_DEBUG),y)
> +CFLAGS += -O1
> +else
> +CFLAGS += -O2
> +endif
> +
> +ifeq ($(CONFIG_FRAME_POINTER),y)
> +CFLAGS += -fno-omit-frame-pointer
> +else
> +CFLAGS += -fomit-frame-pointer
> +endif
> +
> +CFLAGS += -nostdinc -fno-builtin -fno-common
> +CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
> +$(call cc-option-add,CFLAGS,CC,-Wvla)
> +CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
> +CFLAGS-$(CONFIG_DEBUG_INFO) += -g
> +
> +ifneq ($(CONFIG_CC_IS_CLANG),y)
> +# Clang doesn't understand this command line argument, and doesn't appear to
> +# have an suitable alternative. The resulting compiled binary does function,
I realize you only move this, but it would still be nice to adjust
this to "... a suitable alternative" on this occasion.
> +# but has an excessively large symbol table.
> +CFLAGS += -Wa,--strip-local-absolute
> +endif
> +
> +AFLAGS += -D__ASSEMBLY__
> +
> +CFLAGS += $(CFLAGS-y)
> +# allow extra CFLAGS externally via EXTRA_CFLAGS_XEN_CORE
> +CFLAGS += $(EXTRA_CFLAGS_XEN_CORE)
> +
> +# Most CFLAGS are safe for assembly files:
> +# -std=gnu{89,99} gets confused by #-prefixed end-of-line comments
> +# -flto makes no sense and annoys clang
> +AFLAGS += $(filter-out -std=gnu% -flto,$(CFLAGS)) $(AFLAGS-y)
> +
> +# LDFLAGS are only passed directly to $(LD)
> +LDFLAGS += $(LDFLAGS_DIRECT) $(LDFLAGS-y)
> +
> +ifeq ($(CONFIG_UBSAN),y)
> +CFLAGS_UBSAN := -fsanitize=undefined
> +else
> +CFLAGS_UBSAN :=
> +endif
> +
> +ifeq ($(CONFIG_LTO),y)
> +CFLAGS += -flto
> +LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
> +endif
> +
> +include $(BASEDIR)/arch/$(TARGET_ARCH)/arch.mk
> +
> +# define new variables to avoid the ones defines in Config.mk
s/defines/defined/
> @@ -140,10 +95,19 @@ obj-bin-y :=
> endif
>
> # Always build obj-bin files as binary even if they come from C source.
> -$(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
> +# FIXME LTO broken, but we would need a different way to filter -flto out
> +# $(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
While you mention this in the description, I'm still not overly
happy with it getting commented out. What's wrong with making the
construct simply act on c_flags?
Jan
Re: [XEN PATCH v4 05/18] xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)
On 31.03.2020 12:30, Anthony PERARD wrote:
> In a later patch ("xen/build: have the root Makefile generates the
> CFLAGS), we want to generate the CFLAGS in xen/Makefile, then export
> it and have Rules.mk use a CFLAGS from the environment variables. That
> changes the flavor of the CFLAGS and flags intended for one target
> (like -D__OBJECT_FILE__ and -M%) gets propagated and duplicated. So we
> start by moving such flags out of $(CFLAGS) and into $(c_flags) which
> is to be modified by only Rules.mk.
>
> __OBJECT_FILE__ is only used by arch/x86/mm/*.c files, so having it in
> $(c_flags) is enough, we don't need it in $(a_flags).
>
> For include/Makefile and as-insn we can keep using CFLAGS, but since
> it doesn't have -M* flags anymore there is no need to filter them out.
>
> The XEN_BUILD_EFI tests in arch/x86/Makefile was filtering out
> CFLAGS-y, but according to dd40177c1bc8 ("x86-64/EFI: add CFLAGS to
> check compile"), it was done to filter out -MF. CFLAGS doesn't
> have those flags anymore, so no filtering is needed.
>
> This is inspired by the way Kbuild generates CFLAGS for each targets.
>
> Signed-off-by: Anthony PERARD
> Reviewed-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Re: [RFC PATCH 19/26] x86/alternatives: NMI safe runtime patching
On Tue, Apr 07, 2020 at 10:03:16PM -0700, Ankur Arora wrote: > @@ -1807,12 +1911,20 @@ static int __maybe_unused > text_poke_late(patch_worker_t worker, void *stage) > text_poke_state.state = PATCH_SYNC_DONE; /* Start state */ > text_poke_state.primary_cpu = smp_processor_id(); > > + text_poke_state.nmi_context = nmi; > + > + if (nmi) > + register_nmi_handler(NMI_LOCAL, text_poke_nmi, > + NMI_FLAG_FIRST, "text_poke_nmi"); > /* >* Run the worker on all online CPUs. Don't need to do anything >* for offline CPUs as they come back online with a clean cache. >*/ > ret = stop_machine(patch_worker, _poke_state, cpu_online_mask); > > + if (nmi) > + unregister_nmi_handler(NMI_LOCAL, "text_poke_nmi"); > + > return ret; > } This is completely bonghits crazy.
Re: [XEN PATCH v4 04/18] xen/build: include include/config/auto.conf in main Makefile
On 31.03.2020 12:30, Anthony PERARD wrote: > --- a/xen/scripts/Kbuild.include > +++ b/xen/scripts/Kbuild.include > @@ -32,3 +32,8 @@ cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) > $(2)000 ] && echo $(3) || e > # Usage: > # $(MAKE) $(clean) dir > clean := -f $(BASEDIR)/scripts/Makefile.clean clean -C > + > +# Shorthand for kconfig > +# Usage: > +# $(MAKE) $(kconfig) target > +kconfig = -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) > SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" Is this going to be needed outside of xen/Makefile? If not, I'd like to ask that it be local to xen/Makefile. With the adjustment or with a reply clarifying to future plans Reviewed-by: Jan Beulich Jan
Re: [PATCH v9 1/3] x86/tlb: introduce a flush HVM ASIDs flag
On 06.04.2020 12:57, Roger Pau Monne wrote: > Introduce a specific flag to request a HVM guest linear TLB flush, > which is an ASID/VPID tickle that forces a guest linear to guest > physical TLB flush for all HVM guests. > > This was previously unconditionally done in each pre_flush call, but > that's not required: HVM guests not using shadow don't require linear > TLB flushes as Xen doesn't modify the guest page tables in that case > (ie: when using HAP). Note that shadow paging code already takes care > of issuing the necessary flushes when the shadow page tables are > modified. > > In order to keep the previous behavior modify all shadow code TLB > flushes to also flush the guest linear to physical TLB if the guest is > HVM. I haven't looked at each specific shadow code TLB flush in order > to figure out whether it actually requires a guest TLB flush or not, > so there might be room for improvement in that regard. > > Also perform ASID/VPID flushes when modifying the p2m tables as it's a > requirement for AMD hardware. Finally keep the flush in > switch_cr3_cr4, as it's not clear whether code could rely on > switch_cr3_cr4 also performing a guest linear TLB flush. A following > patch can remove the ASID/VPID tickle from switch_cr3_cr4 if found to > not be necessary. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich with one really minor remark: > --- a/xen/arch/x86/mm/paging.c > +++ b/xen/arch/x86/mm/paging.c > @@ -613,7 +613,8 @@ void paging_log_dirty_range(struct domain *d, > > p2m_unlock(p2m); > > -flush_tlb_mask(d->dirty_cpumask); > +flush_mask(d->dirty_cpumask, (!hap_enabled(d) ? FLUSH_TLB : 0) | > + FLUSH_HVM_ASID_CORE); In cases where one case is assumed to be more likely than the other putting the more likely one first can be viewed as a mild hint to the compiler, and hence an extra ! may be warranted in an if() or a conditional expression. Here, however, I don't think we can really consider one case more likely than the other, and hence I'd suggest to avoid the !, flipping the other two expressions accordingly. I may take the liberty to adjust this while committing (if I'm to be the one). Jan
Re: [RFC PATCH 15/26] x86/alternatives: Non-emulated text poking
On Tue, Apr 07, 2020 at 10:03:12PM -0700, Ankur Arora wrote:
> +static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage)
> +{
> + int ret;
> +
> + lockdep_assert_held(_mutex);
> +
> + if (system_state != SYSTEM_RUNNING)
> + return -EINVAL;
> +
> + text_poke_state.stage = stage;
> + text_poke_state.num_acks = cpumask_weight(cpu_online_mask);
> + text_poke_state.head = _modules;
> +
> + text_poke_state.patch_worker = worker;
> + text_poke_state.state = PATCH_SYNC_DONE; /* Start state */
> + text_poke_state.primary_cpu = smp_processor_id();
> +
> + /*
> + * Run the worker on all online CPUs. Don't need to do anything
> + * for offline CPUs as they come back online with a clean cache.
> + */
> + ret = stop_machine(patch_worker, _poke_state, cpu_online_mask);
This.. that on its own is almost a reason to NAK the entire thing. We're
all working very hard to get rid of stop_machine() and you're adding
one.
Worse, stop_machine() is notoriously crap on over-committed virt, the
exact scenario where you want it.
> +
> + return ret;
> +}
[xen-unstable-coverity test] 149517: all pass - PUSHED
flight 149517 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/149517/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen e013e8514389b739153016349e49f5a78e34ddf0 baseline version: xen 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd Last test of basis 149438 2020-04-05 09:19:59 Z3 days Testing same since 149517 2020-04-08 09:19:14 Z0 days1 attempts People who touched revisions under test: Juergen Gross 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 990b6e38d9..e013e85143 e013e8514389b739153016349e49f5a78e34ddf0 -> coverity-tested/smoke
Re: [RFC PATCH 14/26] x86/alternatives: Handle native insns in text_poke_loc*()
On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote: > @@ -1071,10 +1079,13 @@ int notrace poke_int3_handler(struct pt_regs *regs) > goto out_put; > } > > - len = text_opcode_size(tp->opcode); > + if (desc->native) > + BUG(); > + Subject: x86/alternatives: Handle native insns in text_poke_loc*() That's not really handling, is it..
Re: [PATCH v14 0/3] VM forking
On 06.04.2020 17:20, Tamas K Lengyel wrote:
> The following series implements VM forking for Intel HVM guests to allow for
> the fast creation of identical VMs without the assosciated high startup costs
> of booting or restoring the VM from a savefile.
>
> JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
>
> The fork operation is implemented as part of the "xl fork-vm" command:
> xl fork-vm -C -Q -m
>
> By default a fully functional fork is created. The user is in charge however
> to
> create the appropriate config file for the fork and to generate the QEMU save
> file before the fork-vm call is made. The config file needs to give the
> fork a new name at minimum but other settings may also require changes.
> Certain
> settings in the config file of both the parent and the fork have to be set to
> default. Details are documented.
>
> The interface also allows to split the forking into two steps:
> xl fork-vm --launch-dm no \
>-m \
>-p
> xl fork-vm --launch-dm late \
>-C \
>-Q \
>
>
> The split creation model is useful when the VM needs to be created as fast as
> possible. The forked VM can be unpaused without the device model being
> launched
> to be monitored and accessed via VMI. Note however that without its device
> model running (depending on what is executing in the VM) it is bound to
> misbehave or even crash when its trying to access devices that would be
> emulated by QEMU. We anticipate that for certain use-cases this would be an
> acceptable situation, in case for example when fuzzing is performed of code
> segments that don't access such devices.
>
> Launching the device model requires the QEMU Xen savefile to be generated
> manually from the parent VM. This can be accomplished simply by connecting to
> its QMP socket and issuing the "xen-save-devices-state" command. For example
> using the standard tool socat these commands can be used to generate the file:
> socat - UNIX-CONNECT:/var/run/xen/qmp-libxl-
> { "execute": "qmp_capabilities" }
> { "execute": "xen-save-devices-state", \
> "arguments": { "filename": "/path/to/save/qemu_state", \
> "live": false} }
>
> At runtime the forked VM starts running with an empty p2m which gets lazily
> populated when the VM generates EPT faults, similar to how altp2m views are
> populated. If the memory access is a read-only access, the p2m entry is
> populated with a memory shared entry with its parent. For write memory
> accesses
> or in case memory sharing wasn't possible (for example in case a reference is
> held by a third party), a new page is allocated and the page contents are
> copied over from the parent VM. Forks can be further forked if needed, thus
> allowing for further memory savings.
>
> A VM fork reset hypercall is also added that allows the fork to be reset to
> the
> state it was just after a fork, also accessible via xl:
> xl fork-vm --fork-reset -p
>
> This is an optimization for cases where the forks are very short-lived and run
> without a device model, so resetting saves some time compared to creating a
> brand new fork provided the fork has not aquired a lot of memory. If the fork
> has a lot of memory deduplicated it is likely going to be faster to create a
> new fork from scratch and asynchronously destroying the old one.
>
> The series has been tested with Windows VMs and functions as expected. Linux
> VMs when forked from a running VM will have a frozen VNC screen. Linux VMs at
> this time can only be forked with a working device model when the parent VM
> was
> restored from a snapshot using "xl restore -p". This is a known limitation.
> Also note that PVHVM/PVH Linux guests have not been tested. Forking most
> likely
> works but PV devices and drivers would require additional wiring to set things
> up properly since the guests are unaware of the forking taking place, unlike
> the save/restore routine where the guest is made aware of the procedure.
>
> Forking time has been measured to be 0.0007s, device model launch to be around
> 1s depending largely on the number of devices being emulated. Fork resets have
> been measured to be 0.0001s under the optimal circumstances.
>
> New in v14:
> minor adjustments
>
> Patch 1 implements the VM fork
> Patch 2 implements fork reset operation
> Patch 3 adds the toolstack-side code implementing VM forking and reset
>
> Tamas K Lengyel (3):
> xen/mem_sharing: VM forking
> x86/mem_sharing: reset a fork
I've applied these two, but ...
> xen/tools: VM forking toolstack side
... since this one doesn't have any ack or alike I'll defer to
the tool stack maintainers here.
Jan
Re: [RFC PATCH 15/26] x86/alternatives: Non-emulated text poking
On Tue, Apr 07, 2020 at 10:03:12PM -0700, Ankur Arora wrote:
> +static void __maybe_unused sync_one(void)
> +{
> + /*
> + * We might be executing in NMI context, and so cannot use
> + * IRET as a synchronizing instruction.
> + *
> + * We could use native_write_cr2() but that is not guaranteed
> + * to work on Xen-PV -- it is emulated by Xen and might not
> + * execute an iret (or similar synchronizing instruction)
> + * internally.
> + *
> + * cpuid() would trap as well. Unclear if that's a solution
> + * either.
> + */
> + if (in_nmi())
> + cpuid_eax(1);
> + else
> + sync_core();
> +}
That's not thinking staight; what do you think the INT3 does when it
happens inside an NMI ?
Re: [RFC PATCH 14/26] x86/alternatives: Handle native insns in text_poke_loc*()
On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote:
> struct text_poke_loc {
> s32 rel_addr; /* addr := _stext + rel_addr */
> - s32 rel32;
> - u8 opcode;
> + union {
> + struct {
> + s32 rel32;
> + u8 opcode;
> + } emulated;
> + struct {
> + u8 len;
> + } native;
> + };
> const u8 text[POKE_MAX_OPCODE_SIZE];
> };
NAK, this grows the structure from 16 to 20 bytes.
Re: [RFC PATCH 09/26] x86/paravirt: Add runtime_patch()
On Tue, Apr 07, 2020 at 10:03:06PM -0700, Ankur Arora wrote: > +/* > + * preempt_enable_no_resched() so we don't add any preemption points until > + * after the caller has returned. > + */ > +#define preempt_enable_runtime_patch() preempt_enable_no_resched() > +#define preempt_disable_runtime_patch() preempt_disable() NAK, this is probably a stright preemption bug, also, afaict, there aren't actually any users of this in the patch-set.
[xen-unstable test] 149502: regressions - FAIL
flight 149502 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/149502/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 149478 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149431 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 149478 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 149478 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 149478 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 149478 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 149478 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 149478 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 149478 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 149478 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 149478 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-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-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail 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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-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-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-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 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-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop 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-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-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: xen e013e8514389b739153016349e49f5a78e34ddf0 baseline version: xen 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd Last test of basis 149478 2020-04-07 01:51:22 Z1 days Testing same since 149502 2020-04-08 00:06:59 Z0 days1 attempts
Ping: [PATCH V7] x86/altp2m: Hypercall to set altp2m view visibility
Hi Kevin,
This is a kind reminder if you can have another look at the new version
of this patch.
Thanks,
Alex
On 30.03.2020 09:54, Alexandru Isaila wrote:
At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.
The new xc_altp2m_set_visibility() solves this by making views invisible
to vmfunc.
This is done by having a separate arch.altp2m_working_eptp that is
populated and made invalid in the same places as altp2m_eptp. This is
written to EPTP_LIST_ADDR.
The views are made in/visible by marking them with INVALID_MFN or
copying them back from altp2m_eptp.
To have consistency the visibility also applies to
p2m_switch_domain_altp2m_by_id().
The usage of this hypercall is aimed at dom0 having a logic with a number of
views
created and at some time there is a need to be sure that only some of the views
can be switched, saving the rest and making them visible when the time
is right.
Note: If altp2m mode is set to mixed the guest is able to change the view
visibility and then call vmfunc.
Signed-off-by: Alexandru Isaila
---
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: George Dunlap
CC: Jan Beulich
CC: Julien Grall
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: "Roger Pau Monné"
CC: Jun Nakajima
CC: Kevin Tian
---
Changes since V6:
- Update commit message.
Changes since V5:
- Change idx type from uint16_t to unsigned int
- Add rc var and dropped the err return from p2m_get_suppress_ve().
Changes since V4:
- Move p2m specific things from hvm to p2m.c
- Add comment for altp2m_idx bounds check
- Add altp2m_list_lock/unlock().
Changes since V3:
- Change var name form altp2m_idx to idx to shorten line length
- Add bounds check for idx
- Update commit message
- Add comment in xenctrl.h.
Changes since V2:
- Drop hap_enabled() check
- Reduce the indentation depth in hvm.c
- Fix assignment indentation
- Drop pad2.
Changes since V1:
- Drop double view from title.
---
tools/libxc/include/xenctrl.h | 7 +++
tools/libxc/xc_altp2m.c | 24 +++
xen/arch/x86/hvm/hvm.c | 14 ++
xen/arch/x86/hvm/vmx/vmx.c | 2 +-
xen/arch/x86/mm/hap/hap.c | 15 +++
xen/arch/x86/mm/p2m-ept.c | 1 +
xen/arch/x86/mm/p2m.c | 34 +++--
xen/include/asm-x86/domain.h| 1 +
xen/include/asm-x86/p2m.h | 4
xen/include/public/hvm/hvm_op.h | 9 +
10 files changed, 108 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index fc6e57a1a0..2e6e652678 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1943,6 +1943,13 @@ int xc_altp2m_change_gfn(xc_interface *handle, uint32_t
domid,
xen_pfn_t new_gfn);
int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
uint32_t vcpuid, uint16_t *p2midx);
+/*
+ * Set view visibility for xc_altp2m_switch_to_view and vmfunc.
+ * Note: If altp2m mode is set to mixed the guest is able to change the view
+ * visibility and then call vmfunc.
+ */
+int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, bool visible);
/**
* Mem paging operations.
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index 46fb725806..6987c9541f 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -410,3 +410,27 @@ int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle,
uint32_t domid,
xc_hypercall_buffer_free(handle, arg);
return rc;
}
+
+int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, bool visible)
+{
+int rc;
+
+DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+
+arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+arg->cmd = HVMOP_altp2m_set_visibility;
+arg->domain = domid;
+arg->u.set_visibility.altp2m_idx = view_id;
+arg->u.set_visibility.visible = visible;
+
+rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+ HYPERCALL_BUFFER_AS_ARG(arg));
+
+xc_hypercall_buffer_free(handle, arg);
+return rc;
+}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a3d115b650..375e9cf368 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4511,6 +4511,7 @@ static int do_altp2m_op(
case HVMOP_altp2m_get_mem_access:
case HVMOP_altp2m_change_gfn:
case HVMOP_altp2m_get_p2m_idx:
+case HVMOP_altp2m_set_visibility:
break;
default:
@@ -4788,6 +4789,19 @@ static int do_altp2m_op(
break;
Re: [PATCH 3/5] x86_64/mm: map and unmap page tables in share_hotadd_m2p_table
On Wed, 2020-04-01 at 14:29 +0200, Jan Beulich wrote:
> On 23.03.2020 10:41, Hongyan Xia wrote:
> > --- a/xen/include/asm-x86/page.h
> > +++ b/xen/include/asm-x86/page.h
> > @@ -196,6 +196,24 @@ static inline l4_pgentry_t
> > l4e_from_paddr(paddr_t pa, unsigned int flags)
> > #define map_l2t_from_l3e(x)(l2_pgentry_t
> > *)map_domain_page(l3e_get_mfn(x))
> > #define map_l3t_from_l4e(x)(l3_pgentry_t
> > *)map_domain_page(l4e_get_mfn(x))
> >
> > +#define l1e_from_l2e(l2e, off) ({ \
> > +l1_pgentry_t *l1t = map_l1t_from_l2e(l2e); \
> > +l1_pgentry_t l1e = l1t[off];\
> > +UNMAP_DOMAIN_PAGE(l1t); \
> > +l1e; })
> > +
> > +#define l2e_from_l3e(l3e, off) ({ \
> > +l2_pgentry_t *l2t = map_l2t_from_l3e(l3e); \
> > +l2_pgentry_t l2e = l2t[off];\
> > +UNMAP_DOMAIN_PAGE(l2t); \
> > +l2e; })
> > +
> > +#define l3e_from_l4e(l4e, off) ({ \
> > +l3_pgentry_t *l3t = map_l3t_from_l4e(l4e); \
> > +l3_pgentry_t l3e = l3t[off];\
> > +UNMAP_DOMAIN_PAGE(l3t); \
> > +l3e; })
>
> There's a reason these are macros rather than inline functions,
> I assume? (This reason would be nice to be stated in the
> description.)
While converting them into inline functions, I realised I cannot do
that due to the header mess. Converting into inline functions needs the
domain_page.h header, which opens a can of worms if I include it here
(page.h). Keeping them as macros works around this issue.
I will add this in the description.
Hongyan
Re: [PATCH] x86/xen: make xen_pvmmu_arch_setup() static
On 08.04.20 04:46, Jason Yan wrote: Fix the following sparse warning: arch/x86/xen/setup.c:998:12: warning: symbol 'xen_pvmmu_arch_setup' was not declared. Should it be static? Reported-by: Hulk Robot Signed-off-by: Jason Yan Reviewed-by: Juergen Gross Juergen
RE: [PATCH 0/3] Cleanup IOREQ server on exit
> -Original Message- > From: Maximilian Heyne > Sent: 07 April 2020 10:16 > To: xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Paul Durrant > Subject: Re: [PATCH 0/3] Cleanup IOREQ server on exit > > Could someone please have a look at this patch? It solves an actual issue: > Try soft-reset with qemu-xen-traditional and it will fail. > I'll take a look today. Ian, obviously we know that qemu trad is largely dead but this series does address a serious shortcoming. Could you take a look? Paul
[PATCH] x86/EFI: also fill boot_tsc_stamp on the xen.efi boot path
Commit e3a379c35eff ("x86/time: always count s_time from Xen boot")
introducing this missed adjusting this path as well.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
static struct file __initdata ucode;
static multiboot_info_t __initdata mbi = {
@@ -673,6 +674,8 @@ static void __init efi_arch_cpu(void)
uint32_t eax = cpuid_eax(0x8000);
uint32_t *caps = boot_cpu_data.x86_capability;
+boot_tsc_stamp = rdtsc();
+
caps[cpufeat_word(X86_FEATURE_HYPERVISOR)] = cpuid_ecx(1);
if ( (eax >> 16) == 0x8000 && eax > 0x8000 )
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -10,6 +10,7 @@ extern char __2M_init_start[], __2M_init
extern char __2M_rwdata_start[], __2M_rwdata_end[];
extern unsigned long xenheap_initial_phys_start;
+extern uint64_t boot_tsc_stamp;
void early_cpu_init(void);
void early_time_init(void);
Re: [PATCH] MAINTAINERS: Remove all S: entries
On 07.04.2020 18:15, Ian Jackson wrote: > Feature support status is tracked in SUPPORT.md nowadays. It is, yes. > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -69,16 +69,6 @@ Descriptions of section entries: > L: Mailing list that is relevant to this area > W: Web-page with status/info > T: SCM tree type and location. Type is one of: git, hg, quilt, stgit. > - S: Status, one of the following: > -Supported: Someone is actually paid to look after this. > -Maintained: Someone actually looks after it. > -Odd Fixes: It has a maintainer but they don't have time to do > - much other than throw the odd patch in. See below.. > -Orphan: No current maintainer [but maybe you could take the > - role as you write your new code]. > -Obsolete:Old code. Something tagged obsolete generally means > - it has been replaced by a better system and you > - should be using that. I agree with Julien: What we express here is not really overlapping with SUPPORT.md - the may be cases where this is so, but there are also ones where it's not. Jan
[ovmf test] 149504: all pass - PUSHED
flight 149504 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/149504/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 3ab0dadd6618b7808a27e65d83aa3668462afcf2 baseline version: ovmf 9bb1f080c45f7253f9270662d55865a8718cebc8 Last test of basis 149497 2020-04-07 19:10:25 Z0 days Testing same since 149504 2020-04-08 01:40:39 Z0 days1 attempts People who touched revisions under test: Guomin Jiang GuoMinJ 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 9bb1f080c4..3ab0dadd66 3ab0dadd6618b7808a27e65d83aa3668462afcf2 -> xen-tested-master
[libvirt test] 149508: regressions - FAIL
flight 149508 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/149508/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182 build-i386-libvirt6 libvirt-buildfail REGR. vs. 146182 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 146182 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 146182 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a version targeted for testing: libvirt 24b7ac78173517b37bb2cf06b2bcac4305411f0a baseline version: libvirt a1cd25b919509be2645dbe6f952d5263e0d4e4e5 Last test of basis 146182 2020-01-17 06:00:23 Z 82 days Failing since146211 2020-01-18 04:18:52 Z 81 days 78 attempts Testing same since 149508 2020-04-08 04:19:29 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Arnaud Patard Boris Fiuczynski Christian Ehrhardt Christian Schoenebeck Collin Walling Daniel Henrique Barboza Daniel P. Berrangé Daniel Veillard Dario Faggioli Erik Skultety Gaurav Agrawal Han Han Jim Fehlig Jiri Denemark Jonathon Jongsma Julio Faracco Ján Tomko Laine Stump Lin Ma Marc-André Lureau Marek Marczykowski-Górecki Mauro S. M. Rodrigues Michal Privoznik Nikolay Shirokovskiy Pavel Hrdina Pavel Mores Peter Krempa Pino Toscano Prathamesh Chavan Rafael Fonseca Richard W.M. Jones Rikard Falkeborn Ryan Moeller Sahid Orentino Ferdjaoui Sebastian Mitterle Seeteena Thoufeek Stefan Berger Stefan Berger Stefan Hajnoczi Thomas Huth Wu Qingliang Your Name Zhang Bo zhenwei pi Zhimin Feng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd
