[Xen-devel] [ovmf test] 125120: all pass - PUSHED
flight 125120 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125120/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 895b87e38015e0698c6a5c0633e0156b038a56f1 baseline version: ovmf c6a14de3ef30291918f3b15436cf6a75db413eea Last test of basis 125105 2018-07-11 09:40:42 Z0 days Testing same since 125119 2018-07-12 00:40:43 Z0 days2 attempts People who touched revisions under test: Gary Lin Jiaxin Wu Wu Jiaxin 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 c6a14de3ef..895b87e380 895b87e38015e0698c6a5c0633e0156b038a56f1 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125119: regressions - FAIL
flight 125119 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125119/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 6 kernel-build fail REGR. vs. 125105 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 895b87e38015e0698c6a5c0633e0156b038a56f1 baseline version: ovmf c6a14de3ef30291918f3b15436cf6a75db413eea Last test of basis 125105 2018-07-11 09:40:42 Z0 days Testing same since 125119 2018-07-12 00:40:43 Z0 days1 attempts People who touched revisions under test: Gary Lin Jiaxin Wu Wu Jiaxin 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 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 895b87e38015e0698c6a5c0633e0156b038a56f1 Author: Jiaxin Wu Date: Mon Jul 2 09:48:12 2018 +0800 NetworkPkg/HttpDxe: Fix the bug when parsing HTTP(S) message body. *v2: Resolve the conflict commit. *v3: Fixed the failure if BodyLength in HTTP token is less than the received size of HTTPS message. HttpBodyParserCallback function is to parse the HTTP(S) message body so as to confirm whether there is the next message header. But it doesn't record the parsing message data/length correctly. This patch is refine the parsing logic so as to fix the potential failure. Cc: Ye Ting Cc: Fu Siyuan Cc: Gary Lin Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin Reviewed-by: Fu Siyuan Reviewed-by: Ye Ting Tested-by: Gary Lin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.8-testing test] 125065: tolerable FAIL - PUSHED
flight 125065 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125065/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125040 pass in 125065 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail in 125040 pass in 125065 test-armhf-armhf-xl 7 xen-boot fail pass in 125040 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125040 like 124221 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125040 like 124351 test-armhf-armhf-xl 13 migrate-support-check fail in 125040 never pass test-armhf-armhf-xl 14 saverestore-support-check fail in 125040 never pass test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 124283 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 124283 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 124351 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124351 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124351 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124351 test-amd64-amd64-xl-rtds 10 debian-install fail like 124351 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 124351 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 124351 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 124351 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 124351 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-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-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass build-amd64-prev 7 xen-build/dist-test fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass build-i386-prev 7 xen-build/dist-test fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10
[Xen-devel] [xen-unstable-smoke test] 125117: tolerable all pass - PUSHED
flight 125117 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125117/ 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 f1ad5ff73e7d07e6a18488430583168a857f2847 baseline version: xen f3d275cb5eae88295b14fce6b022290e939f6a28 Last test of basis 125101 2018-07-11 08:00:29 Z0 days Testing same since 125117 2018-07-11 20:00:22 Z0 days1 attempts People who touched revisions under test: Jan Beulich Julien Grall Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f3d275cb5e..f1ad5ff73e f1ad5ff73e7d07e6a18488430583168a857f2847 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 02/21] xen/arm: make allocate_memory work for non 1:1 mapped guests
On Tue, 10 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 10/07/18 00:02, Stefano Stabellini wrote:
> > On Mon, 9 Jul 2018, Julien Grall wrote:
> > > On 07/07/18 00:11, Stefano Stabellini wrote:
> > > >mfn_t smfn;
> > > >paddr_t start, size;
> > > > +struct membank *bank;
> > > > smfn = page_to_mfn(pg);
> > > >start = mfn_to_maddr(smfn);
> > >
> > > The new code is pretty horrible to read. Can you please add some comments
> > > to
> > > help understanding it?
> > >
> > > Here is already an example where you set start to MFN. But then override
> > > after
> > > with none comment to understand why.
> > >
> > > Also, this code as always assumed MFN == GFN so start was making sense.
> > > Now,
> > > you re-purpose it to just the guest-physical address. So more likely you
> > > want
> > > to rework the code a bit.
> >
> > I'll add more comments in the code. Next time the patch will be clearer.
> > This is a snippet to give you an idea, but it might be best for you to
> > just wait for the next version before reading this again.
> >
> > /*
> > * smfn: the address of the set of pages to map
> > * start: the address in guest pseudo-physical memory where to map
> > *the pages
>
> The best way is to rename start to gaddr or better provide a frame. So there
> are no need for such self-explanatory comment. However, my main issue was not
> the name itself...
Sure, I can do
> > */
> > smfn = page_to_mfn(pg);
> > start = mfn_to_maddr(smfn);
>
> ... but this specific line. This should have been in a else.
This goes away with having separate functions for DomUs
> > size = pfn_to_paddr(1UL << order);
> > if ( !is_hardware_domain(d) )
>
> Why is_hardware_domain(d)? None of the code below is assuming it is an
> hardware domain and we should not assume the 1:1 mapping. That was the exact
> reason of the BUG_ON(!is_domain_direct_mapped(d)) in the caller and not
> !is_hardware_domain(d).
Yeah, I should have used is_domain_direct_mapped. This also goes away
with having separate functions.
> > {
> > /*
> > * Dom0 is 1:1 mapped, so start is the same as (smfn <<
> > * PAGE_SHIFT).
>
> This comment is misplaced.
>
> > *
> > * Instead, DomU memory is provided in two banks:
>
> Why instead? The comment should be split.
OK
> > * GUEST_RAM0_BASE - GUEST_RAM0_BASE + GUEST_RAM0_SIZE
> > * GUEST_RAM1_BASE - GUEST_RAM1_BASE + GUEST_RAM1_SIZE
> > *
> > * Find the right start address for DomUs accordingly.
> > */
> >
> >
> > > >size = pfn_to_paddr(1UL << order);
> > > > +if ( !map_11 )
> > >
> > > I am not sure why map_11 would mean DomU? I don't see any reason to not
> > > allow
> > > that for Dom0. Note that I am not asking to do it, just having clearer
> > > name.
> >
> > Good point. I think I should just drop the option, which is just
> > confusing, and keep using is_hardware_domain(d) checks like in
> > allocate_memory. Otherwise let me know if you have a better idea.
>
> TBH, I dislike the way you re-purpose the 2 functions. 80% of this code is not
> necessary because you will never merge the range before the bank or deal with
> 1:1 mappings.
I have introduced two separate functions now, I am not so sure it's an
actual improvement.
> Furthermore, I just spotted a few issues with that code:
> 1) If you request 4GB for a guest and the memory has been allocated in
> one chunk, all the RAM will be starting at GUEST_RAM1_SIZE. While we
> officially don't support guest with hardcoded memory layout, there are some
> existing. Such change will break them depending on your memory layout at boot.
I fixed this.
> 2) If in the future we decide to add more banks (this may happen with
> PCI passthrough), then you have to add yet another if.
>
> What is the problem to provide a separate function to allocate memory for
> non-direct domain? You could just pass the base and the size of the region to
> populate.
You'll see the new functions in the next series. I think there is more
than 20% in common with the older functions. Anyhow, you'll have a
chance to comment on them on the next series.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.11-testing test] 125064: trouble: broken/fail/pass
flight 125064 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125064/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu broken test-armhf-armhf-xl-multivcpu 4 host-install(4) broken REGR. vs. 124792 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-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-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-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-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: xen 1eb6544a567e3e5133fafe0c4ef3545c5138d0e4 baseline version: xen eb17ff9ce6a99a8761d3f4768703691f34043356 Last test of basis 124914 2018-07-02 11:27:44 Z9 days Testing same since 125064 2018-07-09 14:06:53 Z2 days1 attempts People who touched revisions under test: Ian Jackson jobs:
Re: [Xen-devel] [PATCH v2 06/21] xen/arm: do not pass dt_host to make_memory_node and make_hypervisor_node
On Tue, 10 Jul 2018, Julien Grall wrote: > Hi, > > On 09/07/18 22:51, Stefano Stabellini wrote: > > > I would replace this with a BUG_ON(evtchn != 0). > > > > I agree with the principle, but I think you meant > > BUG_ON(d->arch.evtchn_irq <= 0) ? > > The IRQ is an unsigned number. So why <= 0? Ah yes, it should be BUG_ON(d->arch.evtchn_irq == 0). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 01/21] xen/arm: rename get_11_allocation_size to get_allocation_size
On Mon, 9 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 07/07/18 00:11, Stefano Stabellini wrote:
> > ... and remove the BUG_ON(!dom0_11_mapping) in allocate_memory.
>
> Please rebase your work on staging. This code has changed a bit since Xen
> 4.11-rc6.
I'll do
> > A follow-up patch will make the function work with non 1:1 mapped
> > guests.
> >
> > No functional changes.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v2:
> > - new patch
> > ---
> > xen/arch/arm/domain_build.c | 22 --
> > 1 file changed, 8 insertions(+), 14 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 11cdf05..182e3d5 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -79,7 +79,7 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
> > return alloc_vcpu(dom0, 0, 0);
> > }
> > -static unsigned int get_11_allocation_size(paddr_t size)
> > +static unsigned int get_allocation_size(paddr_t size)
> > {
> > /*
> >* get_order_from_bytes returns the order greater than or equal to
> > @@ -251,21 +251,15 @@ static void allocate_memory(struct domain *d, struct
> > kernel_info *kinfo)
> > get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
> > const unsigned int min_order = get_order_from_bytes(MB(4));
> > struct page_info *pg;
> > -unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
> > +unsigned int order = get_allocation_size(kinfo->unassigned_mem);
> > int i;
> > bool lowmem = true;
> > unsigned int bits;
> > -/*
> > - * TODO: Implement memory bank allocation when DOM0 is not direct
> > - * mapped
> > - */
> > -BUG_ON(!dom0_11_mapping);
>
> New code is using is_domain_direct_mapped(d).
Thanks for the head's up
> > -
> > -printk("Allocating 1:1 mappings totalling %ldMB for dom0:\n",
> > +printk("Allocating 1:1 mappings totalling %ldMB for dom%d:\n",
>
> This is not mention i nthe command message.
I'll mention the change
> At the same time, please fix the typo s/totalling/totaling/
"Totalling" is actually accepted in British English.
> > /* Don't want format this as PRIpaddr (16 digit hex) */
> > - (unsigned long)(kinfo->unassigned_mem >> 20));
> > + (unsigned long)(kinfo->unassigned_mem >> 20), d->domain_id);
> > kinfo->mem.nr_banks = 0;
> > @@ -303,7 +297,7 @@ static void allocate_memory(struct domain *d, struct
> > kernel_info *kinfo)
> >* If we failed to allocate bank0 under 4GB, continue allocating
> >* memory from above 4GB and fill in banks.
> >*/
> > -order = get_11_allocation_size(kinfo->unassigned_mem);
> > +order = get_allocation_size(kinfo->unassigned_mem);
> > while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
> > {
> > pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
> > @@ -314,7 +308,7 @@ static void allocate_memory(struct domain *d, struct
> > kernel_info *kinfo)
> > if ( lowmem && order < min_low_order)
> > {
> > D11PRINT("Failed at min_low_order, allow high
> > allocations\n");
> > -order = get_11_allocation_size(kinfo->unassigned_mem);
> > +order = get_allocation_size(kinfo->unassigned_mem);
> > lowmem = false;
> > continue;
> > }
> > @@ -334,7 +328,7 @@ static void allocate_memory(struct domain *d, struct
> > kernel_info *kinfo)
> > if ( lowmem )
> > {
> > D11PRINT("Allocation below bank 0, allow high
> > allocations\n");
> > -order = get_11_allocation_size(kinfo->unassigned_mem);
> > +order = get_allocation_size(kinfo->unassigned_mem);
> > lowmem = false;
> > continue;
> > }
> > @@ -349,7 +343,7 @@ static void allocate_memory(struct domain *d, struct
> > kernel_info *kinfo)
> >* Success, next time around try again to get the largest order
> >* allocation possible.
> >*/
> > -order = get_11_allocation_size(kinfo->unassigned_mem);
> > +order = get_allocation_size(kinfo->unassigned_mem);
> > }
> > if ( kinfo->unassigned_mem )
> >
>
> Cheers,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.7-testing baseline-only test] 74955: regressions - FAIL
This run is configured for baseline tests only. flight 74955 xen-4.7-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74955/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 15 guest-saverestore.2 fail REGR. vs. 74942 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail like 74942 test-armhf-armhf-libvirt 12 guest-start fail like 74942 test-armhf-armhf-xl 12 guest-start fail like 74942 test-armhf-armhf-xl-xsm 12 guest-start fail like 74942 test-armhf-armhf-xl-multivcpu 12 guest-start fail like 74942 test-armhf-armhf-xl-midway 12 guest-start fail like 74942 test-armhf-armhf-libvirt-xsm 12 guest-start fail like 74942 test-armhf-armhf-xl-credit2 12 guest-start fail like 74942 test-armhf-armhf-xl-rtds 12 guest-start fail like 74942 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74942 test-armhf-armhf-xl-vhd 10 debian-di-installfail like 74942 test-armhf-armhf-libvirt-raw 10 debian-di-installfail like 74942 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail 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-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 280a5568939c4a5832be787c8e0c23a19f30935a baseline version: xen e7956461f76f4b6e9d7d1d99daabdeef9ea09f62 Last test of basis74942 2018-07-07 03:22:03 Z4 days Testing same since74955 2018-07-11 11:15:32 Z0 days1 attempts People who touched revisions under test: Jan Beulich jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl
[Xen-devel] [ovmf baseline-only test] 74956: all pass
This run is configured for baseline tests only. flight 74956 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74956/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c6a14de3ef30291918f3b15436cf6a75db413eea baseline version: ovmf 99fd30431d565412707f7a1e1a23461d10d07e85 Last test of basis74954 2018-07-11 09:49:41 Z0 days Testing same since74956 2018-07-11 11:56:44 Z0 days1 attempts People who touched revisions under test: Zenith432 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit c6a14de3ef30291918f3b15436cf6a75db413eea Author: Zenith432 Date: Tue Jul 10 16:50:36 2018 +0800 BaseTools/GenFw: Disable support for R_X86_64_32S REF:https://bugzilla.tianocore.org/show_bug.cgi?id=999 Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zenith432 Reviewed-by: Liming Gao commit ecbaa856da0c94b7054f795d001ee3f5aaee033e Author: Zenith432 Date: Mon Jul 9 20:58:15 2018 +0800 BaseTools/GenFw: Add X64 GOTPCREL Support to GenFw Adds support for the following X64 ELF relocations to GenFw R_X86_64_GOTPCREL R_X86_64_GOTPCRELX R_X86_64_REX_GOTPCRELX Background: The GCC49 and GCC5 toolchains use the small pie model for X64. In the small pie model, gcc emits a GOTPCREL relocation whenever C code takes the address of a global function. The emission of GOTPCREL is mitigated by several factors 1. In GCC49, all global symbols are declared hidden thereby eliminating the emission of GOTPCREL. 2. In GCC5, LTO is used. In LTO, the complier first creates intermediate representation (IR) files. During the static link stage, the LTO compiler combines all IR files as a single compilation unit, using linker symbol assistance to generate code. Any global symbols defined in the IR that are not referenced from outside the IR are converted to local symbols - thereby eliminating the emission of GOTPCREL for them. 3. The linker (binutils ld) further transforms any GOTPCREL used with the movq opcode to a direct rip-relative relocation used with the leaq opcode. This linker optimization can be disabled with the option -Wl,--no-relax. Furthermore, gcc is able to emit GOTPCREL with other opcodes - pushq opcode for passing arguments to functions. - addq/subq opcodes for pointer arithmetic. These other opcode uses are not transformed by the linker. Ultimately, in GCC5 there are some emissions of GOTPCREL that survive all these mitigations - if C code takes the address of a global function defined in assembly code - and performs pointer arithmetic on the address - then the GOTPCREL remains in the final linker product. A GOTPCREL relocation today causes the build to stop since GenFw does not handle them. It is possible to eliminate any remaining GOTPCREL emissions by manually declaring the global symbols causing them to have hidden visibility. This patch is offered instead to allow GenFw to handle any residual GOTPCREL. Cc: Shi Steven Cc: Yonghong Zhu Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zenith432 Reviewed-by: Liming Gao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Recent 4.9 kernel not booting as dom0
On Thu, Jul 5, 2018 at 6:57 AM Juergen Gross wrote: > > On 05/07/18 12:19, Juergen Gross wrote: > > On 04/07/18 20:16, Karl Johnson wrote: > >> Hello, > >> > >> I'm building dom0 kernel RPMs for the CentOS Xen project > >> (https://github.com/CentOS-virt7/xen-kernel) and it seems that the 4.9 > >> branch isn't booting anymore as dom0. I recently built 4.9.110 and > >> 4.9.111, both give black screen and reboot while booting dom0. Our last > >> successful version is 4.9.105 therefore something must be wrong between > >> 4.9.106 and 4.9.110. > >> > >> I checked the OSSTEST for linux-4.9 and the last working flight was > >> 4.9.101. Is there a known issue with Xen and Linux 4.9? > > > > I think I've found the reason. Testing a patch right now. > > It worked. I have already sent it to stable. In case you want to try > it I'm attaching it for reference. > > > Juergen Thanks, the patch has been rolled in stable and it works. [root@node-tmp1 ~]# cat /proc/version Linux version 4.9.112-32.el6.x86_64 (mockbu...@build.aerisnetwork.net) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC) ) #1 SMP Wed Jul 11 13:03:26 EDT 2018 Karl ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 7/7] xen/arm: setup: Move in init code only used at boot in setup.c
On Mon, 2 Jul 2018, Julien Grall wrote:
> Some of the functions implemented in setup.c are only used at boot but
> not yet marked as such.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Stefano Stabellini
>
> ---
> Changes in v2:
> - Add Stefano's reviewed-by
> ---
> xen/arch/arm/setup.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 1d6f6bf37e..fe7384fd30 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -175,7 +175,7 @@ static void __init processor_id(void)
> check_local_cpu_errata();
> }
>
> -void dt_unreserved_regions(paddr_t s, paddr_t e,
> +void __init dt_unreserved_regions(paddr_t s, paddr_t e,
>void (*cb)(paddr_t, paddr_t), int first)
> {
> int i, nr = fdt_num_mem_rsv(device_tree_flattened);
> @@ -201,9 +201,9 @@ void dt_unreserved_regions(paddr_t s, paddr_t e,
> cb(s, e);
> }
>
> -struct bootmodule *add_boot_module(bootmodule_kind kind,
> - paddr_t start, paddr_t size,
> - const char *cmdline)
> +struct bootmodule __init *add_boot_module(bootmodule_kind kind,
> + paddr_t start, paddr_t size,
> + const char *cmdline)
I have just spotted this minor alignment issue. I fixed on commit.
> {
> struct bootmodules *mods =
> struct bootmodule *mod;
> @@ -434,7 +434,7 @@ static paddr_t __init get_xen_paddr(void)
> return paddr;
> }
>
> -static void init_pdx(void)
> +static void __init init_pdx(void)
> {
> paddr_t bank_start, bank_size, bank_end;
>
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 5/7] xen: Don't build libelf for Arm
On Mon, 2 Jul 2018, Julien Grall wrote: > Now that ELF support has been dropped to boot Dom0, no-one is using > libelf within the hypervisor. > > Introduce a config option to select libelf on x86 and keep unselected > for Arm. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- > Changes in v2: > - Rename HAS_ELF to NEEDS_LIBELF > --- > xen/arch/x86/Kconfig | 1 + > xen/common/Kconfig | 3 +++ > xen/common/Makefile | 2 +- > 3 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig > index f64fc56739..c75f0526d8 100644 > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -24,6 +24,7 @@ config X86 > select HAS_PDX > select HAS_UBSAN > select HAS_VPCI if !PV_SHIM_EXCLUSIVE > + select NEEDS_LIBELF > select NUMA > > config ARCH_DEFCONFIG > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index 9043dce937..d4c0951a24 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -44,6 +44,9 @@ config HAS_GDBSX > config HAS_IOPORTS > bool > > +config NEEDS_LIBELF > + bool > + > config NEEDS_LIST_SORT > bool > > diff --git a/xen/common/Makefile b/xen/common/Makefile > index 24d4752ccc..b3e0b0ebf4 100644 > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -78,5 +78,5 @@ obj-$(CONFIG_TMEM) += $(tmem-y) > subdir-$(CONFIG_COVERAGE) += coverage > subdir-$(CONFIG_UBSAN) += ubsan > > -subdir-y += libelf > +subdir-$(CONFIG_NEEDS_LIBELF) += libelf > subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt > -- > 2.11.0 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-upstream-4.9-testing test] 125062: regressions - FAIL
flight 125062 qemu-upstream-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125062/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 6 xen-install fail REGR. vs. 116784 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 116784 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116750 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116784 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 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 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-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-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuuaad23066e4b27296d219b9123393fbe2a5a885bb baseline version: qemuub397ed6a586b0a93e9a8b47f5b3008fac34f5f37 Last test of basis 116784 2017-12-02 21:48:33 Z 220 days Testing same since 125062 2018-07-09 13:38:53 Z2 days1 attempts People who touched revisions under test: Dr. David Alan Gilbert Eric Blake Gerd Hoffmann John Thomson Max Reitz Paolo Bonzini Samuel Thibault jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt
Re: [Xen-devel] [PATCH 4/8] x86/AMD: distinguish compute units from hyper-threads
On Wed, Jul 11, 2018 at 06:07:42AM -0600, Jan Beulich wrote:
> Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
> the difference is not very big. The most relevant change (requiring some
> code restructuring) is that the topoext feature no longer means there is
> a valid CU ID.
>
> Take the opportunity and convert wrongly plain int variables in
> set_cpu_sibling_map() to unsigned int.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -504,17 +504,23 @@ static void amd_get_topology(struct cpui
> u32 eax, ebx, ecx, edx;
>
> cpuid(0x801e, , , , );
> -c->compute_unit_id = ebx & 0xFF;
> c->x86_num_siblings = ((ebx >> 8) & 0x3) + 1;
> +
> + if (c->x86 < 0x17)
> + c->compute_unit_id = ebx & 0xFF;
> + else {
> + c->cpu_core_id = ebx & 0xFF;
> + c->x86_max_cores /= c->x86_num_siblings;
> + }
> }
>
> if (opt_cpu_info)
> printk("CPU %d(%d) -> Processor %d, %s %d\n",
> cpu, c->x86_max_cores, c->phys_proc_id,
> - cpu_has(c, X86_FEATURE_TOPOEXT) ? "Compute Unit" :
> - "Core",
> - cpu_has(c, X86_FEATURE_TOPOEXT) ? c->compute_unit_id :
> - c->cpu_core_id);
> + c->compute_unit_id != INVALID_CUID ? "Compute Unit"
> + : "Core",
> + c->compute_unit_id != INVALID_CUID ?
> c->compute_unit_id
> + : c->cpu_core_id);
> }
>
> static void early_init_amd(struct cpuinfo_x86 *c)
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -236,33 +236,41 @@ static void link_thread_siblings(int cpu
> cpumask_set_cpu(cpu2, per_cpu(cpu_core_mask, cpu1));
> }
>
> -static void set_cpu_sibling_map(int cpu)
> +static void set_cpu_sibling_map(unsigned int cpu)
> {
> -int i;
> +unsigned int i;
> struct cpuinfo_x86 *c = cpu_data;
>
> cpumask_set_cpu(cpu, _sibling_setup_map);
>
> cpumask_set_cpu(cpu, socket_cpumask[cpu_to_socket(cpu)]);
> +cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
> +cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>
> if ( c[cpu].x86_num_siblings > 1 )
> {
> for_each_cpu ( i, _sibling_setup_map )
> {
> -if ( cpu_has(c, X86_FEATURE_TOPOEXT) ) {
> -if ( (c[cpu].phys_proc_id == c[i].phys_proc_id) &&
> - (c[cpu].compute_unit_id == c[i].compute_unit_id) )
> +if ( cpu == i || c[cpu].phys_proc_id != c[i].phys_proc_id )
> +continue;
> +if ( c[cpu].compute_unit_id != INVALID_CUID &&
> + c[i].compute_unit_id != INVALID_CUID )
> +{
> +if ( c[cpu].compute_unit_id == c[i].compute_unit_id )
> link_thread_siblings(cpu, i);
> -} else if ( (c[cpu].phys_proc_id == c[i].phys_proc_id) &&
> -(c[cpu].cpu_core_id == c[i].cpu_core_id) ) {
> -link_thread_siblings(cpu, i);
> }
> +else if ( c[cpu].cpu_core_id != XEN_INVALID_CORE_ID &&
> + c[i].cpu_core_id != XEN_INVALID_CORE_ID )
> +{
> +if ( c[cpu].cpu_core_id == c[i].cpu_core_id )
> +link_thread_siblings(cpu, i);
> +}
> +else
> +printk(XENLOG_WARNING
> + "CPU%u: unclear relationship with CPU%u\n",
> + cpu, i);
> }
> }
> -else
> -{
> -cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
> -}
>
> if ( c[cpu].x86_max_cores == 1 )
> {
>
>
>
>
Side note: if cpu_core_id isn't the logical cpu, it might be worth
updating the comments in processor.h
Reviewed-by: Brian Woods
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] 4.9.3 preparations
08641a9e8870d3b174d95aaa55ecba43387563b5 would be nice to have included. Stew -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of Jan Beulich Sent: Wednesday, July 4, 2018 6:42 AM To: xen-devel Cc: anthony.per...@citrix.com; Ian Jackson ; Stefano Stabellini ; Wei Liu ; Lars Kurth Subject: [Xen-devel] 4.9.3 preparations All, this is supposed to go out in about 3 weeks time. Please point out backport candidates you find missing from its staging branch, but which you consider relevant. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 0/3] Fixes to build with lld 6.0.0
>>> On 11.07.18 at 17:34, wrote: > Hello, > > The following 3 patches allow building the hypervisor with lld 6.0.0. > > The only difference between v2 is the split into multiple patches. > > Thanks, Roger. > > Roger Pau Monne (3): > xen/x86: replace '||' usage in the linker script > xen/compiler: introduce a define for weak symbols > xen/x86: declare the efi symbol as weak Reviewed-by: Jan Beulich Patch 2 should have been Cc-ed to Konrad and Ross though. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/8] x86/shim: fully ignore "nosmp" and "maxcpus="
On Wed, Jul 11, 2018 at 06:11:36AM -0600, Jan Beulich wrote: > In the shim case, the number of CPUs should be solely controlled by the > guest configuration file. Make sure the command line options are fully > (and not just partially) ignored. > > Signed-off-by: Jan Beulich Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 1/3] xen/x86: replace '||' usage in the linker script
With '|'. The result is the same, and the later works with lld. Fixes
the following error when building Xen with lld:
ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \
/root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
ld: error: xen.lds:260: malformed number: |
>>> ASSERT(__image_base__ > (261 >> 8) * 0x) | (261 <<
>>> 39))) + ((1 << 39) / 2)) + (64 << 30)) + (1 << 30)) + (1 << 30))) ||
>>>
>>> ^
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Daniel Kiper
---
xen/arch/x86/xen.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 70afedd31d..326e885402 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -331,7 +331,7 @@ SECTIONS
.comment 0 : { *(.comment) }
}
-ASSERT(__image_base__ > XEN_VIRT_START ||
+ASSERT(__image_base__ > XEN_VIRT_START |
__2M_rwdata_end <= XEN_VIRT_END - NR_CPUS * PAGE_SIZE,
"Xen image overlaps stubs area")
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 3/3] xen/x86: declare the efi symbol as weak
This allows removing the DEFINED conditional in the linker script, and
fixes compilation with lld:
ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \
/root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
ld: error: xen.lds:233: symbol not found: efi
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Daniel Kiper
---
xen/arch/x86/xen.lds.S | 2 --
xen/include/xen/efi.h | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 326e885402..9fa40a6d48 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -304,8 +304,6 @@ SECTIONS
} :text
#endif
- efi = DEFINED(efi) ? efi : .;
-
/* Sections to be discarded */
/DISCARD/ : {
*(.exit.text)
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 44b7d3ec3a..5678df72f9 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -21,7 +21,7 @@ struct efi {
unsigned long smbios3; /* SMBIOS v3 table */
};
-extern struct efi efi;
+extern struct efi __weak efi;
#ifndef __ASSEMBLY__
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/3] xen/compiler: introduce a define for weak symbols
And replace the open-coded versions already in tree. No functional
change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Daniel Kiper
---
xen/include/xen/compiler.h | 2 ++
xen/include/xen/livepatch_payload.h | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index a7e05681c9..001f589655 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -18,6 +18,8 @@
#define __packed __attribute__((__packed__))
+#define __weak__attribute__((weak))
+
#if (!defined(__clang__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 5))
#define unreachable() do {} while (1)
#else
diff --git a/xen/include/xen/livepatch_payload.h
b/xen/include/xen/livepatch_payload.h
index 8f38cc2c60..4a1a96d054 100644
--- a/xen/include/xen/livepatch_payload.h
+++ b/xen/include/xen/livepatch_payload.h
@@ -24,7 +24,7 @@ typedef void livepatch_unloadcall_t(void);
* executed in series by the livepatch infrastructure at patch load time.
*/
#define LIVEPATCH_LOAD_HOOK(_fn) \
-livepatch_loadcall_t *__attribute__((weak)) \
+livepatch_loadcall_t *__weak \
const livepatch_load_data_##_fn __section(".livepatch.hooks.load") =
_fn;
/*
@@ -33,7 +33,7 @@ typedef void livepatch_unloadcall_t(void);
* Same as LOAD hook with s/load/unload/
*/
#define LIVEPATCH_UNLOAD_HOOK(_fn) \
- livepatch_unloadcall_t *__attribute__((weak)) \
+ livepatch_unloadcall_t *__weak \
const livepatch_unload_data_##_fn __section(".livepatch.hooks.unload")
= _fn;
#endif /* __XEN_LIVEPATCH_PAYLOAD_H__ */
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 0/3] Fixes to build with lld 6.0.0
Hello, The following 3 patches allow building the hypervisor with lld 6.0.0. The only difference between v2 is the split into multiple patches. Thanks, Roger. Roger Pau Monne (3): xen/x86: replace '||' usage in the linker script xen/compiler: introduce a define for weak symbols xen/x86: declare the efi symbol as weak xen/arch/x86/xen.lds.S | 4 +--- xen/include/xen/compiler.h | 2 ++ xen/include/xen/efi.h | 2 +- xen/include/xen/livepatch_payload.h | 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) -- 2.17.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: setup pv irq ops vector earlier
On 07/11/2018 01:08 AM, Juergen Gross wrote: > On 11/07/18 00:26, Boris Ostrovsky wrote: >> On 07/02/2018 06:00 AM, Juergen Gross wrote: >>> Setting pv_irq_ops for Xen PV domains should be done as early as >>> possible in order to support e.g. very early printk() usage. >> Will printk() work as result of this move? We still, for example, >> haven't set up console. > It will print to the kernel print buffer, so the output will be > available later. Right, haven't thought about it. > >> This will (probably) allow us not to crash (due to STI and such) but I >> am not sure "support" is the right term here. > Not crashing is big plus IMO. :-) Actually, no, this is not sufficient. You need to move xen_vcpu_info_reset(0) up as well. Otherwise you will not be able to dereference the percpu xen_vcpu in xen_save_fl(). -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/8] x86/shim: fully ignore "nosmp" and "maxcpus="
On Wed, Jul 11, 2018 at 06:11:36AM -0600, Jan Beulich wrote: > In the shim case, the number of CPUs should be solely controlled by the > guest configuration file. Make sure the command line options are fully > (and not just partially) ignored. > > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné I agree with Andrew that it should be mentioned in the command line document. Sorry for not doing that before. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Rich Persaud > Sent: 11 July 2018 15:06 > To: Xen-devel > Cc: committ...@xenproject.org; Lars Kurth ; > car...@cardoe.com; George Dunlap ; Tamas K > Lengyel > Subject: Re: [Xen-devel] [Notes for xen summit 2018 design session] Process > changes: is the 6 monthly release Cadence too short, Security Process, ... > > On Jul 5, 2018, at 22:54, Tamas K Lengyel > wrote: > > > >> On Thu, Jul 5, 2018 at 12:52 PM George Dunlap > wrote: > >> > >>> > Again, there was a sense that some of the issues we are seeing could > be solved if we had better > CI capability: in other words, some of the issues we were seeing could > be resolved by > * Better CI capability as suggested in the Release Cadence discussion > * Improving some of the internal working practices of the security team > * Before we commit to a change (such as improved batching), we > should try them first informally. > E.g. the security team could try and work towards more predictable > dates for batches vs. a > concrete process change > >>> > >>> My feeling on CI is clear in this thread and other threads. But I think > >>> what would help OSSTEST bottlenecks if we do better at separating up > >>> different parts of the testing process into more parallel tasks that > >>> also provide feedback to the contributor faster. I'll obviously never > >>> suggest the GitHub/GitLab PR/MR model to a ML driven project because > I > >>> wouldn't survive the hate mail but there is something that those models > >>> do provide. > >> > >> FWIW we (IanJ, Wei, Roger, Anthony and I) just had a fairly extended > discussion about this in our team meeting today, and everyone basically > agreed that there are some things about the web-based PR model that are > *really* nice: > >> > >> 1. Effective tracking of submission state — open / assigned to a reviewer / > merged / rejected > >> 2. Automation > >> 3. Not having to marshal git commits into email, and then marshal them > back into git commits again > >> > >> On the other hand, the general consensus, from people who had used > such websites “in anger” (as they say here in the UK) was that they really > didn’t like the way that reviews worked. Email was seen as: > >> 1. Much more convenient for giving feedback and having discussions > >> 2. Easier for people to “listen in” on other people’s reviews > >> 3. More accessible for posterity > >> > >> In the end we generally agreed that it was an idea worth thinking about > more. Not sure how the wider community feels, but there are at least a > decent cohort who wouldn’t send you hate mail. :-) > > > > I for one would very much welcome a PR-style model. Keeping track of > > patches in emails I need to review is not fun (and I'm pretty bad at > > it) and then just to find a patch that doesn't even compile is a waste > > of everyone's time. Automatic style checks and compile checks are the > > bare minimum I would consider any project should have today. There is > > already a Travis CI script shipped with Xen yet it's not used when > > patches are submitted.. Perhaps the reviews are more accessible for > > posterity but I personally never end up reading old reviews, even in > > the depths of the worst code archeology it's always just looking at > > git blame and commit messages. Giving feedback and discussions I also > > find a lot more easier to navigate on say Github then on the > > mailinglist - and I do get email copies of PRs and can reply inline > > via email if I want to.. We are already keeping track of open patch > > series on Jira - or at least there was an attempt to do so, not sure > > how up-to-date that is - but that's not the right way as that requires > > manual porting of tasks from the mailinglist. Perhaps it should be the > > other way around. > > > > Just my 2c. > > > > Tamas > > OpenXT uses JIRA for issue tracking and Github for pull requests and > approval workflow. JIRA can link issues to PRs, based on ticket number in > the PR description. > > Both JIRA and Github can mirror issue/PR comments and content to email > (individual or mailing list). Replies to these emails will be associated with > issues/PRs, if the sender has an account on the service. > > Would there be interest in testing a Gitlab/Github workflow in a Xen sub > project, where contributors are already inclined to use such tools? Windows > PV drivers could be a candidate, as QubesOS uses Github PRs and the volume > of changes is not high. > Personally I'm not a fan of web based workflows. I think that mailing lists work much better for review as my experience of using web review tools has been that it is nearly impossible to comment on a patch as a whole and when comments are mirrored to email they end up some sort of digest in reverse chronological order. That said, pulling the final reviewed code from a branch is certainly much
[Xen-devel] [OSSTEST PATCH 3/4] PDU: ipmi: Only log the first cmd run
This quietens the output again.
Signed-off-by: Ian Jackson
---
Osstest/PDU/ipmi.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Osstest/PDU/ipmi.pm b/Osstest/PDU/ipmi.pm
index f3a50c9..b6621db 100644
--- a/Osstest/PDU/ipmi.pm
+++ b/Osstest/PDU/ipmi.pm
@@ -50,11 +50,12 @@ sub pdu_power_state {
my $onoff= $on ? "on" : "off";
my @cmd = (qw(ipmitool -H), $mo->{Mgmt},
- '-U',$mo->{User}, '-P',$mo->{Pass});
+
+my $cmd_logged;
my $getstatus = sub {
my @scmd = (@cmd, qw(power status));
-logm("PDU IMPI: @scmd");
+logm("PDU IMPI: @scmd") unless $cmd_logged++;
open IPMI, "-|", @scmd or die $!;
my $status = do { local $/=undef; ; };
$?=0; $!=0;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 4/4] PDU: ipmi: Pass further options to ipmitool
This is useful, for example, for passing `-I lanplus'.
Signed-off-by: Ian Jackson
---
Osstest/PDU/ipmi.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Osstest/PDU/ipmi.pm b/Osstest/PDU/ipmi.pm
index b6621db..d411d97 100644
--- a/Osstest/PDU/ipmi.pm
+++ b/Osstest/PDU/ipmi.pm
@@ -50,6 +50,8 @@ sub pdu_power_state {
my $onoff= $on ? "on" : "off";
my @cmd = (qw(ipmitool -H), $mo->{Mgmt},
+ '-U',$mo->{User}, '-P',$mo->{Pass},
+ @{ $mo->{Opts} });
my $cmd_logged;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 1/4] PDU: ipmi: Use arrays rather than strings for cmd
This allows arguments with spaces, etc.
No functional change with the existing configurations I know about.
It would be good to fix this before any configurations are created
where this would make a difference...
Signed-off-by: Ian Jackson
---
Osstest/PDU/ipmi.pm | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Osstest/PDU/ipmi.pm b/Osstest/PDU/ipmi.pm
index dbf211f..f3a50c9 100644
--- a/Osstest/PDU/ipmi.pm
+++ b/Osstest/PDU/ipmi.pm
@@ -49,11 +49,17 @@ sub pdu_power_state {
my ($mo, $on) = @_;
my $onoff= $on ? "on" : "off";
-my $cmd = "ipmitool -H $mo->{Mgmt} -U $mo->{User} -P $mo->{Pass}";
+my @cmd = (qw(ipmitool -H), $mo->{Mgmt},
+ '-U',$mo->{User}, '-P',$mo->{Pass});
my $getstatus = sub {
-my $status = `$cmd power status`
-or die "Cannot retrieve current power status";
+my @scmd = (@cmd, qw(power status));
+logm("PDU IMPI: @scmd");
+open IPMI, "-|", @scmd or die $!;
+my $status = do { local $/=undef; ; };
+$?=0; $!=0;
+close IPMI and $status or
+die "Cannot retrieve current power status ($? $!)";
chomp($status);
logm("$status (want $onoff)");
$status =~ s/^Chassis Power is (on|off)$/$1/
@@ -66,7 +72,7 @@ sub pdu_power_state {
return;
}
-system_checked("$cmd power $onoff");
+system_checked((@cmd, qw(power), $onoff));
my $count = 60;
for (;;) {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 2/4] PDU: pause: Honour OSSTEST_PDU_NOPAUSE
For debugging.
Signed-off-by: Ian Jackson
---
Osstest/PDU/pause.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/Osstest/PDU/pause.pm b/Osstest/PDU/pause.pm
index 9e839c6..b5f0322 100644
--- a/Osstest/PDU/pause.pm
+++ b/Osstest/PDU/pause.pm
@@ -46,6 +46,7 @@ sub new {
sub pdu_power_state {
my ($mo, $on) = @_;
+return if $ENV{OSSTEST_PDU_NOPAUSE};
my $delay = $mo->[!!$on];
logm("power: pdu operation pausing for ${delay}s");
sleep $delay;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 4/8] cr-publish-flight-logs: Refactor rsync -e option construction
Previously this was hardcoded. Now we make a variable @ssh, and use
rsync's quoting scheme to transform it into a value suitable for -e.
No overall functional change, although now the rsync command contains
additional quotes in the -e option.
Signed-off-by: Ian Jackson
---
cr-publish-flight-logs | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cr-publish-flight-logs b/cr-publish-flight-logs
index 539318d..9e13652 100755
--- a/cr-publish-flight-logs
+++ b/cr-publish-flight-logs
@@ -61,8 +61,9 @@ sub copydir ($$) {
return unless $c{"${cfgbase}Publish"};
my $src = $c{$cfgbase}.$subdir."/";
my $dst = $c{"${cfgbase}Publish"}.$subdir;
+my @ssh = qw(ssh -o batchmode=yes);
my @cmd= qw(rsync --compress --compress-level=9 --stats --delete -auH);
-push @cmd, '-e', 'ssh -o batchmode=yes';
+push @cmd, '-e', join(' ', map { s/\'/''/g; "'$_'"; } @ssh);
#--bwlimit=50
push @cmd, $src, $dst;
print "+ @cmd\n";
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 2/8] Publish: Default LogsPublish and ResultsPublish from Publish
And delete the explicit settings from production-config.
No functional change.
Signed-off-by: Ian Jackson
---
Osstest.pm| 4 ++--
production-config | 3 ---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/Osstest.pm b/Osstest.pm
index 3377ea3..738ed4f 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -255,8 +255,8 @@ END
my $pubbaseprefix = $c{PubBaseDir} ? "$c{PubBaseDir}/" : "";
foreach my $l (qw(logs results)) {
my $u = ucfirst $l;
- next if defined $c{$u};
- $c{"${u}"} = "$pubbaseprefix$l";
+ $c{"${u}"} //= "$pubbaseprefix$l";
+ $c{"${u}Publish"} //= "$c{Publish}/$l" if defined $c{Publish};
}
$c{Stash} //= $c{Logs};
diff --git a/production-config b/production-config
index 48b1e8e..df02cd3 100644
--- a/production-config
+++ b/production-config
@@ -59,9 +59,6 @@ ReportHtmlUnpubBaseUrl="http://osstest/~osstest/pub/logs/;
Publish osstest@www:/var/www/osstest
GlobalLockDir /home/osstest/testing.git
-LogsPublish= "$c{Publish}/logs"
-ResultsPublish= "$c{Publish}/results"
-
HarnessPublishGitUserHost osst...@xenbits.xen.org
HarnessPublishGitRepoDir ext/osstest-massachusetts.git
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 5/8] Publish: Introduce publish_ssh_opts
We need to pass it $cfgbase because this will soon be configurable.
No functional change right now.
Signed-off-by: Ian Jackson
---
Osstest/Management.pm | 10 --
cr-publish-flight-logs | 3 ++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/Osstest/Management.pm b/Osstest/Management.pm
index 2c875a7..c1ed2ac 100644
--- a/Osstest/Management.pm
+++ b/Osstest/Management.pm
@@ -27,7 +27,7 @@ BEGIN {
our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
$VERSION = 1.00;
@ISA = qw(Exporter);
-@EXPORT = qw(
+@EXPORT = qw(publish_ssh_opts
);
%EXPORT_TAGS = (
'logs' => [qw(logs_select onloghost logcfg
@@ -40,7 +40,12 @@ BEGIN {
}
our ($logcfgbase, $loghost, $logdir);
-our @logsshopts= qw(-o batchmode=yes);
+our @logsshopts;
+
+sub publish_ssh_opts ($) {
+my ($cfgbase) = @_; # LogsPublish or ResultsPublish
+return (qw(-o batchmode=yes));
+}
sub logs_select ($) {
($logcfgbase) = @_;
@@ -48,6 +53,7 @@ sub logs_select ($) {
return 0 unless $cfgvalue;
if ($cfgvalue =~ m/\:/) {
($loghost, $logdir) = ($`,$'); #');
+ @logsshopts = publish_ssh_opts($logcfgbase);
} else {
($loghost, $logdir) = (undef, $cfgvalue);
}
diff --git a/cr-publish-flight-logs b/cr-publish-flight-logs
index 9e13652..7249d03 100755
--- a/cr-publish-flight-logs
+++ b/cr-publish-flight-logs
@@ -21,6 +21,7 @@ use strict qw(refs vars);
use Fcntl qw(:flock);
BEGIN { unshift @INC, qw(.); }
use Osstest;
+use Osstest::Management;
our %c;
@@ -61,7 +62,7 @@ sub copydir ($$) {
return unless $c{"${cfgbase}Publish"};
my $src = $c{$cfgbase}.$subdir."/";
my $dst = $c{"${cfgbase}Publish"}.$subdir;
-my @ssh = qw(ssh -o batchmode=yes);
+my @ssh = (qw(ssh), publish_ssh_opts("${cfgbase}Publish"));
my @cmd= qw(rsync --compress --compress-level=9 --stats --delete -auH);
push @cmd, '-e', join(' ', map { s/\'/''/g; "'$_'"; } @ssh);
#--bwlimit=50
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 0/8] Log publication from Citrix Cambridge
From: Ian Jackson
We finally have a VM host for publishing the test logs from the Citrix
instance of osstest. It needs an ssh bounce to get to the actual
public webserver, so we add support for that.
With this, and appropriate ssh keys, osst...@osstest.xs can run
cr-publish-flight-logs, cr-ensure-disk-space
Ian Jackson (8):
cr-ensure-disk-space: With -D, print check_space command
Publish: Default LogsPublish and ResultsPublish from Publish
cr-publish-flight-logs: Refactor copydir args
cr-publish-flight-logs: Refactor rsync -e option construction
Publish: Introduce publish_ssh_opts
Publish: Introduce {Logs,Results}PublishSshOpts
Publish: Cambridge: Publish to new public host
Publish: Cambridge: Get the public URL right
Osstest.pm | 5 +++--
Osstest/Management.pm | 10 --
cr-ensure-disk-space| 5 -
cr-publish-flight-logs | 14 +-
production-config | 3 ---
production-config-cambridge | 5 -
6 files changed, 28 insertions(+), 14 deletions(-)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 6/8] Publish: Introduce {Logs, Results}PublishSshOpts
Signed-off-by: Ian Jackson
---
Osstest.pm| 1 +
Osstest/Management.pm | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Osstest.pm b/Osstest.pm
index 738ed4f..85a6e78 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -257,6 +257,7 @@ END
my $u = ucfirst $l;
$c{"${u}"} //= "$pubbaseprefix$l";
$c{"${u}Publish"} //= "$c{Publish}/$l" if defined $c{Publish};
+ $c{"${u}PublishSshOpts"} //= $c{PublishSshOpts} // [];
}
$c{Stash} //= $c{Logs};
diff --git a/Osstest/Management.pm b/Osstest/Management.pm
index c1ed2ac..4edb361 100644
--- a/Osstest/Management.pm
+++ b/Osstest/Management.pm
@@ -44,7 +44,7 @@ our @logsshopts;
sub publish_ssh_opts ($) {
my ($cfgbase) = @_; # LogsPublish or ResultsPublish
-return (qw(-o batchmode=yes));
+return (qw(-o batchmode=yes), @{$c{"${cfgbase}SshOpts"}});
}
sub logs_select ($) {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 8/8] Publish: Cambridge: Get the public URL right
This URL is now accessible, although there are some webserver tweaks
remaining to do.
Signed-off-by: Ian Jackson
---
production-config-cambridge | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/production-config-cambridge b/production-config-cambridge
index b1360ba..8647feb 100644
--- a/production-config-cambridge
+++ b/production-config-cambridge
@@ -48,7 +48,7 @@ TestHostKeypairPath /export/home/osstest/.ssh/id_rsa_osstest
GitCacheProxy git://git-cache.daemon.osstest.xs.citrite.net:9419/
-PubBaseUrl http://osstest.xs.citrite.net/~osstest/testlogs
+PubBaseUrl http://osstest.xensource.com/osstest
ReportHtmlPubBaseUrl="$c{PubBaseUrl}/logs"
ResultsHtmlPubBaseUrl="$c{PubBaseUrl}/results"
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 3/8] cr-publish-flight-logs: Refactor copydir args
Have it take $cfgbase and $subdir instead. This allows us to lift the
config test into it. And it will be even more useful in a moment.
No functional change.
Signed-off-by: Ian Jackson
---
cr-publish-flight-logs | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/cr-publish-flight-logs b/cr-publish-flight-logs
index 1e5a49d..539318d 100755
--- a/cr-publish-flight-logs
+++ b/cr-publish-flight-logs
@@ -57,7 +57,10 @@ if ($push_harness) {
}
sub copydir ($$) {
-my ($src,$dst) = @_;
+my ($cfgbase,$subdir) = @_;
+return unless $c{"${cfgbase}Publish"};
+my $src = $c{$cfgbase}.$subdir."/";
+my $dst = $c{"${cfgbase}Publish"}.$subdir;
my @cmd= qw(rsync --compress --compress-level=9 --stats --delete -auH);
push @cmd, '-e', 'ssh -o batchmode=yes';
#--bwlimit=50
@@ -66,6 +69,5 @@ sub copydir ($$) {
$!=0; $?=0; system @cmd; die "rsync $? $!" if $? or $!;
}
-copydir("$c{Logs}/$flight/", "$c{LogsPublish}/$flight")
-if $flight && $c{LogsPublish};
-copydir("$c{Results}/", "$c{ResultsPublish}") if $c{ResultsPublish};
+copydir(qw(Logs), "/$flight") if $flight;
+copydir(qw(Results), '');
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 7/8] Publish: Cambridge: Publish to new public host
Signed-off-by: Ian Jackson --- production-config-cambridge | 3 +++ 1 file changed, 3 insertions(+) diff --git a/production-config-cambridge b/production-config-cambridge index f557614..b1360ba 100644 --- a/production-config-cambridge +++ b/production-config-cambridge @@ -41,6 +41,9 @@ OverlayLocal /export/home/osstest/overlay-local LogsMinSpaceMby= 10*1e3 LogsMinExpireAge= 86400*4 +Publish osstest@10.59.48.19:/var/www/osstest +PublishSshOpts= ['-o','ProxyCommand ssh -W 10.59.48.19:22 osstest@10.59.128.11'] + TestHostKeypairPath /export/home/osstest/.ssh/id_rsa_osstest GitCacheProxy git://git-cache.daemon.osstest.xs.citrite.net:9419/ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [OSSTEST PATCH 1/8] cr-ensure-disk-space: With -D, print check_space command
Signed-off-by: Ian Jackson
---
cr-ensure-disk-space | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/cr-ensure-disk-space b/cr-ensure-disk-space
index 7091314..3e0288f 100755
--- a/cr-ensure-disk-space
+++ b/cr-ensure-disk-space
@@ -25,6 +25,7 @@ BEGIN { unshift @INC, qw(.); }
use Osstest;
use Osstest::Management qw(:logs);
use Fcntl qw(:flock);
+use Data::Dumper;
our $dryrun= 0;
our $force;
@@ -56,7 +57,9 @@ csreadconfig();
logs_select $cfgbase or exit 0;
sub check_space () {
-open P, "-|", onloghost "df --block-size=1M -P $logdir" or die $!;
+my @cmd = onloghost "df --block-size=1M -P $logdir";
+print DEBUG "check_space: ", Dumper(\@cmd);
+open P, "-|", @cmd or die $!;
$_= ;
m/^filesystem/i or die "$_ ?";
$_= ;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
On Jul 5, 2018, at 22:54, Tamas K Lengyel wrote: > >> On Thu, Jul 5, 2018 at 12:52 PM George Dunlap >> wrote: >> >>> Again, there was a sense that some of the issues we are seeing could be solved if we had better CI capability: in other words, some of the issues we were seeing could be resolved by * Better CI capability as suggested in the Release Cadence discussion * Improving some of the internal working practices of the security team * Before we commit to a change (such as improved batching), we should try them first informally. E.g. the security team could try and work towards more predictable dates for batches vs. a concrete process change >>> >>> My feeling on CI is clear in this thread and other threads. But I think >>> what would help OSSTEST bottlenecks if we do better at separating up >>> different parts of the testing process into more parallel tasks that >>> also provide feedback to the contributor faster. I'll obviously never >>> suggest the GitHub/GitLab PR/MR model to a ML driven project because I >>> wouldn't survive the hate mail but there is something that those models >>> do provide. >> >> FWIW we (IanJ, Wei, Roger, Anthony and I) just had a fairly extended >> discussion about this in our team meeting today, and everyone basically >> agreed that there are some things about the web-based PR model that are >> *really* nice: >> >> 1. Effective tracking of submission state — open / assigned to a reviewer / >> merged / rejected >> 2. Automation >> 3. Not having to marshal git commits into email, and then marshal them back >> into git commits again >> >> On the other hand, the general consensus, from people who had used such >> websites “in anger” (as they say here in the UK) was that they really didn’t >> like the way that reviews worked. Email was seen as: >> 1. Much more convenient for giving feedback and having discussions >> 2. Easier for people to “listen in” on other people’s reviews >> 3. More accessible for posterity >> >> In the end we generally agreed that it was an idea worth thinking about >> more. Not sure how the wider community feels, but there are at least a >> decent cohort who wouldn’t send you hate mail. :-) > > I for one would very much welcome a PR-style model. Keeping track of > patches in emails I need to review is not fun (and I'm pretty bad at > it) and then just to find a patch that doesn't even compile is a waste > of everyone's time. Automatic style checks and compile checks are the > bare minimum I would consider any project should have today. There is > already a Travis CI script shipped with Xen yet it's not used when > patches are submitted.. Perhaps the reviews are more accessible for > posterity but I personally never end up reading old reviews, even in > the depths of the worst code archeology it's always just looking at > git blame and commit messages. Giving feedback and discussions I also > find a lot more easier to navigate on say Github then on the > mailinglist - and I do get email copies of PRs and can reply inline > via email if I want to.. We are already keeping track of open patch > series on Jira - or at least there was an attempt to do so, not sure > how up-to-date that is - but that's not the right way as that requires > manual porting of tasks from the mailinglist. Perhaps it should be the > other way around. > > Just my 2c. > > Tamas OpenXT uses JIRA for issue tracking and Github for pull requests and approval workflow. JIRA can link issues to PRs, based on ticket number in the PR description. Both JIRA and Github can mirror issue/PR comments and content to email (individual or mailing list). Replies to these emails will be associated with issues/PRs, if the sender has an account on the service. Would there be interest in testing a Gitlab/Github workflow in a Xen sub project, where contributors are already inclined to use such tools? Windows PV drivers could be a candidate, as QubesOS uses Github PRs and the volume of changes is not high. The value of these services is not just the metadata archive and structure that it brings to dev workflow, but the ever-expanding ecosystem of analytics tools that can use the historical data. Yes, in theory, similar data can be extracted from xen-devel archives, but it often requires custom tooling. Case in point - the lack of accessible quantitative data to substantiate the intuitions expressed in this thread, about the differences in dev patterns with 6-month vs. longer release cycles. Rich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 07/16] x86/shadow: fetch CPL just once in sh_page_fault()
>>> On 11.07.18 at 15:46, wrote: > At 07:29 -0600 on 11 Jul (1531294179), Jan Beulich wrote: >> This isn't as much of an optimization than to avoid triggering a gcc bug >> affecting 5.x ... 7.x, triggered by any asm() put inside the ad hoc >> "rewalk" loop and taking as an (output?) operand a register variable >> tied to %rdx (an "rdx" clobber is fine). The issue is due to an apparent >> collision in register use with the modulo operation in vtlb_hash(), >> which (with optimization enabled) involves a multiplication of two >> 64-bit values with the upper half (in %rdx) of the 128-bit result being >> of interest. >> >> Such an asm() was originally meant to be implicitly introduced into the >> code when converting most indirect calls through the hvm_funcs table to >> direct calls (via alternative instruction patching); that model was >> switched to clobbers due to further compiler problems, but I think the >> change here is worthwhile nevertheless. >> >> Signed-off-by: Jan Beulich > > I don't quite follow what the compiler bug does here -- it would be nice > to say what effect it has on the final code. In any case, the code > change is fine. There was no final code - it was an Internal Compiler Error. > Reviewed-by: Tim Deegan Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 10/16] x86/HVM: patch indirect calls through hvm_funcs to direct ones
>>> On 11.07.18 at 15:42, wrote:
> This is intentionally not touching hooks used rarely (or not at all)
> during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
> as well as nested, VM event, and altp2m ones (they can all be done
> later, if so desired). Virtual Interrupt delivery ones will be dealt
> with in a subsequent patch.
>
> Signed-off-by: Jan Beulich
Should have Cc-ed you, Paul, right away.
Jan
> ---
> Needless to say that I'm pretty unhappy about the workaround I had to
> add to hvm_set_rdtsc_exiting(). Improvement suggestions welcome.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2017,7 +2017,7 @@ static int hvmemul_write_msr(
> static int hvmemul_wbinvd(
> struct x86_emulate_ctxt *ctxt)
> {
> -hvm_funcs.wbinvd_intercept();
> +alternative_vcall0(hvm_funcs.wbinvd_intercept);
> return X86EMUL_OKAY;
> }
>
> @@ -2035,7 +2035,7 @@ static int hvmemul_get_fpu(
> struct vcpu *curr = current;
>
> if ( !curr->fpu_dirtied )
> -hvm_funcs.fpu_dirty_intercept();
> +alternative_vcall0(hvm_funcs.fpu_dirty_intercept);
> else if ( type == X86EMUL_FPU_fpu )
> {
> const typeof(curr->arch.xsave_area->fpu_sse) *fpu_ctxt =
> @@ -2152,7 +2152,7 @@ static void hvmemul_put_fpu(
> {
> curr->fpu_dirtied = false;
> stts();
> -hvm_funcs.fpu_leave(curr);
> +alternative_vcall1(hvm_funcs.fpu_leave, curr);
> }
> }
> }
> @@ -2314,7 +2314,8 @@ static int _hvm_emulate_one(struct hvm_e
> if ( hvmemul_ctxt->intr_shadow != new_intr_shadow )
> {
> hvmemul_ctxt->intr_shadow = new_intr_shadow;
> -hvm_funcs.set_interrupt_shadow(curr, new_intr_shadow);
> +alternative_vcall2(hvm_funcs.set_interrupt_shadow,
> + curr, new_intr_shadow);
> }
>
> if ( hvmemul_ctxt->ctxt.retire.hlt &&
> @@ -2451,7 +2452,8 @@ void hvm_emulate_init_once(
>
> memset(hvmemul_ctxt, 0, sizeof(*hvmemul_ctxt));
>
> -hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(curr);
> +hvmemul_ctxt->intr_shadow =
> +alternative_call1(hvm_funcs.get_interrupt_shadow, curr);
> hvmemul_get_seg_reg(x86_seg_cs, hvmemul_ctxt);
> hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -271,13 +271,24 @@ void hvm_set_rdtsc_exiting(struct domain
> {
> struct vcpu *v;
>
> +#if __GNUC__ >= 7
> +/*
> + * gcc from 7.x onwards warns about ternary operators with their middle
> operand
> + * omitted and the controlling expression itself being of _Bool type.
> + */
> +# pragma GCC diagnostic push
> +# pragma GCC diagnostic ignored "-Wparentheses"
> +#endif
> for_each_vcpu ( d, v )
> -hvm_funcs.set_rdtsc_exiting(v, enable);
> +alternative_vcall2(hvm_funcs.set_rdtsc_exiting, v, enable);
> +#if __GNUC__ >= 7
> +# pragma GCC diagnostic pop
> +#endif
> }
>
> void hvm_get_guest_pat(struct vcpu *v, u64 *guest_pat)
> {
> -if ( !hvm_funcs.get_guest_pat(v, guest_pat) )
> +if ( !alternative_call2(hvm_funcs.get_guest_pat, v, guest_pat) )
> *guest_pat = v->arch.hvm_vcpu.pat_cr;
> }
>
> @@ -302,7 +313,7 @@ int hvm_set_guest_pat(struct vcpu *v, u6
> return 0;
> }
>
> -if ( !hvm_funcs.set_guest_pat(v, guest_pat) )
> +if ( !alternative_call2(hvm_funcs.set_guest_pat, v, guest_pat) )
> v->arch.hvm_vcpu.pat_cr = guest_pat;
>
> return 1;
> @@ -342,7 +353,7 @@ bool hvm_set_guest_bndcfgs(struct vcpu *
> /* nothing, best effort only */;
> }
>
> -return hvm_funcs.set_guest_bndcfgs(v, val);
> +return alternative_call2(hvm_funcs.set_guest_bndcfgs, v, val);
> }
>
> /*
> @@ -502,7 +513,8 @@ void hvm_migrate_pirqs(struct vcpu *v)
> static bool hvm_get_pending_event(struct vcpu *v, struct x86_event *info)
> {
> info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
> -return hvm_funcs.get_pending_event(v, info);
> +
> +return alternative_call2(hvm_funcs.get_pending_event, v, info);
> }
>
> void hvm_do_resume(struct vcpu *v)
> @@ -1684,7 +1696,7 @@ void hvm_inject_event(const struct x86_e
> }
> }
>
> -hvm_funcs.inject_event(event);
> +alternative_vcall1(hvm_funcs.inject_event, event);
> }
>
> int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
> @@ -2271,7 +2283,7 @@ int hvm_set_cr0(unsigned long value, boo
> (!rangeset_is_empty(d->iomem_caps) ||
>!rangeset_is_empty(d->arch.ioport_caps) ||
>has_arch_pdevs(d)) )
> -hvm_funcs.handle_cd(v, value);
> +alternative_vcall2(hvm_funcs.handle_cd, v, value);
>
> hvm_update_cr(v, 0, value);
>
> @@ -3515,7 +3527,8 @@ int hvm_msr_read_intercept(unsigned int
> goto gp_fault;
> /* If ret == 0 then this is not an MCE MSR, see other MSRs. */
> ret = ((ret == 0)
>
[Xen-devel] [PATCH 16/16] x86/cpuidle: patch some indirect calls to direct ones
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
(from where cpuidle_init_cpu() runs the first time) the pointers need to
start out as NULL.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -102,8 +102,6 @@ bool lapic_timer_init(void)
return true;
}
-static uint64_t (*__read_mostly tick_to_ns)(uint64_t) = acpi_pm_tick_to_ns;
-
void (*__read_mostly pm_idle_save)(void);
unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER - 1;
integer_param("max_cstate", max_cstate);
@@ -289,9 +287,9 @@ static uint64_t acpi_pm_ticks_elapsed(ui
return ((0x - t1) + t2 +1);
}
-uint64_t (*__read_mostly cpuidle_get_tick)(void) = get_acpi_pm_tick;
-static uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t)
-= acpi_pm_ticks_elapsed;
+uint64_t (*__read_mostly cpuidle_get_tick)(void);
+static uint64_t (*__read_mostly tick_to_ns)(uint64_t);
+static uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t);
static void print_acpi_power(uint32_t cpu, struct acpi_processor_power *power)
{
@@ -547,7 +545,7 @@ void update_idle_stats(struct acpi_proce
struct acpi_processor_cx *cx,
uint64_t before, uint64_t after)
{
-int64_t sleep_ticks = ticks_elapsed(before, after);
+int64_t sleep_ticks = alternative_call2(ticks_elapsed, before, after);
/* Interrupts are disabled */
spin_lock(>stat_lock);
@@ -555,7 +553,8 @@ void update_idle_stats(struct acpi_proce
cx->usage++;
if ( sleep_ticks > 0 )
{
-power->last_residency = tick_to_ns(sleep_ticks) / 1000UL;
+power->last_residency = alternative_call1(tick_to_ns, sleep_ticks) /
+1000UL;
cx->time += sleep_ticks;
}
power->last_state = >states[0];
@@ -635,7 +634,7 @@ static void acpi_processor_idle(void)
if ( cx->type == ACPI_STATE_C1 || local_apic_timer_c2_ok )
{
/* Get start time (ticks) */
-t1 = cpuidle_get_tick();
+t1 = alternative_call0(cpuidle_get_tick);
/* Trace cpu idle entry */
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
@@ -644,7 +643,7 @@ static void acpi_processor_idle(void)
/* Invoke C2 */
acpi_idle_do_entry(cx);
/* Get end time (ticks) */
-t2 = cpuidle_get_tick();
+t2 = alternative_call0(cpuidle_get_tick);
trace_exit_reason(irq_traced);
/* Trace cpu idle exit */
TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,
@@ -666,7 +665,7 @@ static void acpi_processor_idle(void)
lapic_timer_off();
/* Get start time (ticks) */
-t1 = cpuidle_get_tick();
+t1 = alternative_call0(cpuidle_get_tick);
/* Trace cpu idle entry */
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
@@ -717,7 +716,7 @@ static void acpi_processor_idle(void)
}
/* Get end time (ticks) */
-t2 = cpuidle_get_tick();
+t2 = alternative_call0(cpuidle_get_tick);
/* recovering TSC */
cstate_restore_tsc();
@@ -827,11 +826,20 @@ int cpuidle_init_cpu(unsigned int cpu)
{
unsigned int i;
-if ( cpu == 0 && boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
+if ( cpu == 0 && system_state < SYS_STATE_active )
{
-cpuidle_get_tick = get_stime_tick;
-ticks_elapsed = stime_ticks_elapsed;
-tick_to_ns = stime_tick_to_ns;
+if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
+{
+cpuidle_get_tick = get_stime_tick;
+ticks_elapsed = stime_ticks_elapsed;
+tick_to_ns = stime_tick_to_ns;
+}
+else
+{
+cpuidle_get_tick = get_acpi_pm_tick;
+ticks_elapsed = acpi_pm_ticks_elapsed;
+tick_to_ns = acpi_pm_tick_to_ns;
+}
}
acpi_power = xzalloc(struct acpi_processor_power);
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -778,7 +778,7 @@ static void mwait_idle(void)
if (!(lapic_timer_reliable_states & (1 << cstate)))
lapic_timer_off();
- before = cpuidle_get_tick();
+ before = alternative_call0(cpuidle_get_tick);
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->type, before, exp, pred);
update_last_cx_stat(power, cx, before);
@@ -786,7 +786,7 @@ static void mwait_idle(void)
if (cpu_is_haltable(cpu))
mwait_idle_with_hints(eax, MWAIT_ECX_INTERRUPT_BREAK);
- after = cpuidle_get_tick();
+ after = alternative_call0(cpuidle_get_tick);
Re: [Xen-devel] [PATCH 07/16] x86/shadow: fetch CPL just once in sh_page_fault()
At 07:29 -0600 on 11 Jul (1531294179), Jan Beulich wrote: > This isn't as much of an optimization than to avoid triggering a gcc bug > affecting 5.x ... 7.x, triggered by any asm() put inside the ad hoc > "rewalk" loop and taking as an (output?) operand a register variable > tied to %rdx (an "rdx" clobber is fine). The issue is due to an apparent > collision in register use with the modulo operation in vtlb_hash(), > which (with optimization enabled) involves a multiplication of two > 64-bit values with the upper half (in %rdx) of the 128-bit result being > of interest. > > Such an asm() was originally meant to be implicitly introduced into the > code when converting most indirect calls through the hvm_funcs table to > direct calls (via alternative instruction patching); that model was > switched to clobbers due to further compiler problems, but I think the > change here is worthwhile nevertheless. > > Signed-off-by: Jan Beulich I don't quite follow what the compiler bug does here -- it would be nice to say what effect it has on the final code. In any case, the code change is fine. Reviewed-by: Tim Deegan Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 15/16] x86/genapic: patch indirect calls to direct ones
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void send_IPI_mask(const cpumask_t *mask, int vector)
{
-genapic.send_IPI_mask(mask, vector);
+alternative_vcall2(genapic.send_IPI_mask, mask, vector);
}
void send_IPI_self(int vector)
{
-genapic.send_IPI_self(vector);
+alternative_vcall1(genapic.send_IPI_self, vector);
}
/*
--- a/xen/include/asm-x86/mach-generic/mach_apic.h
+++ b/xen/include/asm-x86/mach-generic/mach_apic.h
@@ -15,8 +15,18 @@
#define TARGET_CPUS ((const typeof(cpu_online_map) *)_online_map)
#define init_apic_ldr (genapic.init_apic_ldr)
#define clustered_apic_check (genapic.clustered_apic_check)
-#define cpu_mask_to_apicid (genapic.cpu_mask_to_apicid)
-#define vector_allocation_cpumask(cpu) (genapic.vector_allocation_cpumask(cpu))
+#define cpu_mask_to_apicid(mask) ({ \
+ /* \
+* There are a number of places where the address of a local variable \
+* gets passed here. The use of ?: in alternative_call1() triggers an \
+* "address of ... is always true" warning in such a case with at least
\
+* gcc 7. Hence the seemingly pointless local variable here. \
+*/ \
+ const cpumask_t *m_ = (mask); \
+ alternative_call1(genapic.cpu_mask_to_apicid, m_); \
+})
+#define vector_allocation_cpumask(cpu) \
+ alternative_call1(genapic.vector_allocation_cpumask, cpu)
static inline void enable_apic_mode(void)
{
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 14/16] x86/genapic: remove indirection from genapic hook accesses
Instead of loading a pointer at each use site, have a single runtime
instance of struct genapic, copying into it from the individual
instances. The individual instances can this way also be moved to .init
(also adjust apic_probe[] at this occasion).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -944,8 +944,8 @@ void __init x2apic_bsp_setup(void)
force_iommu = 1;
-genapic = apic_x2apic_probe();
-printk("Switched to APIC driver %s.\n", genapic->name);
+genapic = *apic_x2apic_probe();
+printk("Switched to APIC driver %s.\n", genapic.name);
if ( !x2apic_enabled )
{
--- a/xen/arch/x86/genapic/bigsmp.c
+++ b/xen/arch/x86/genapic/bigsmp.c
@@ -42,7 +42,7 @@ static __init int probe_bigsmp(void)
return def_to_bigsmp;
}
-const struct genapic apic_bigsmp = {
+const struct genapic __initconstrel apic_bigsmp = {
APIC_INIT("bigsmp", probe_bigsmp),
GENAPIC_PHYS
};
--- a/xen/arch/x86/genapic/default.c
+++ b/xen/arch/x86/genapic/default.c
@@ -20,7 +20,7 @@ static __init int probe_default(void)
return 1;
}
-const struct genapic apic_default = {
+const struct genapic __initconstrel apic_default = {
APIC_INIT("default", probe_default),
GENAPIC_FLAT
};
--- a/xen/arch/x86/genapic/probe.c
+++ b/xen/arch/x86/genapic/probe.c
@@ -15,11 +15,9 @@
#include
#include
-extern const struct genapic apic_bigsmp;
+struct genapic __read_mostly genapic;
-const struct genapic *__read_mostly genapic;
-
-const struct genapic *apic_probe[] __initdata = {
+const struct genapic *const __initconstrel apic_probe[] = {
_bigsmp,
_default, /* must be last */
NULL,
@@ -36,11 +34,11 @@ void __init generic_bigsmp_probe(void)
* - we find more than 8 CPUs in acpi LAPIC listing with xAPIC support
*/
- if (!cmdline_apic && genapic == _default)
+ if (!cmdline_apic && genapic.name == apic_default.name)
if (apic_bigsmp.probe()) {
- genapic = _bigsmp;
+ genapic = apic_bigsmp;
printk(KERN_INFO "Overriding APIC driver with %s\n",
- genapic->name);
+ genapic.name);
}
}
@@ -50,7 +48,7 @@ static int __init genapic_apic_force(con
for (i = 0; apic_probe[i]; i++)
if (!strcmp(apic_probe[i]->name, str)) {
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
rc = 0;
}
@@ -66,18 +64,18 @@ void __init generic_apic_probe(void)
record_boot_APIC_mode();
check_x2apic_preenabled();
- cmdline_apic = changed = (genapic != NULL);
+ cmdline_apic = changed = !!genapic.name;
for (i = 0; !changed && apic_probe[i]; i++) {
if (apic_probe[i]->probe()) {
changed = 1;
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
}
}
if (!changed)
- genapic = _default;
+ genapic = apic_default;
- printk(KERN_INFO "Using APIC driver %s\n", genapic->name);
+ printk(KERN_INFO "Using APIC driver %s\n", genapic.name);
}
/* These functions can switch the APIC even after the initial ->probe() */
@@ -88,9 +86,9 @@ int __init mps_oem_check(struct mp_confi
for (i = 0; apic_probe[i]; ++i) {
if (apic_probe[i]->mps_oem_check(mpc,oem,productid)) {
if (!cmdline_apic) {
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
printk(KERN_INFO "Switched to APIC driver
`%s'.\n",
- genapic->name);
+ genapic.name);
}
return 1;
}
@@ -104,9 +102,9 @@ int __init acpi_madt_oem_check(char *oem
for (i = 0; apic_probe[i]; ++i) {
if (apic_probe[i]->acpi_madt_oem_check(oem_id, oem_table_id)) {
if (!cmdline_apic) {
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
printk(KERN_INFO "Switched to APIC driver
`%s'.\n",
- genapic->name);
+ genapic.name);
}
return 1;
}
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -163,7 +163,7 @@ static void send_IPI_mask_x2apic_cluster
local_irq_restore(flags);
}
-static const struct genapic apic_x2apic_phys = {
+static const struct genapic __initconstrel apic_x2apic_phys = {
APIC_INIT("x2apic_phys", NULL),
.int_delivery_mode =
[Xen-devel] [PATCH 13/16] x86/genapic: drop .target_cpus() hook
All flavors specify target_cpus_all() anyway - replace use of the hook
by _online_map.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/genapic/delivery.c
+++ b/xen/arch/x86/genapic/delivery.c
@@ -5,12 +5,6 @@
#include
#include
-
-const cpumask_t *target_cpus_all(void)
-{
- return _online_map;
-}
-
/*
* LOGICAL FLAT DELIVERY MODE (multicast via bitmask to <= 8 logical APIC IDs).
*/
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -169,7 +169,6 @@ static const struct genapic apic_x2apic_
.int_dest_mode = 0 /* physical delivery */,
.init_apic_ldr = init_apic_ldr_x2apic_phys,
.clustered_apic_check = clustered_apic_check_x2apic,
-.target_cpus = target_cpus_all,
.vector_allocation_cpumask = vector_allocation_cpumask_phys,
.cpu_mask_to_apicid = cpu_mask_to_apicid_phys,
.send_IPI_mask = send_IPI_mask_x2apic_phys,
@@ -182,7 +181,6 @@ static const struct genapic apic_x2apic_
.int_dest_mode = 1 /* logical delivery */,
.init_apic_ldr = init_apic_ldr_x2apic_cluster,
.clustered_apic_check = clustered_apic_check_x2apic,
-.target_cpus = target_cpus_all,
.vector_allocation_cpumask = vector_allocation_cpumask_x2apic_cluster,
.cpu_mask_to_apicid = cpu_mask_to_apicid_x2apic_cluster,
.send_IPI_mask = send_IPI_mask_x2apic_cluster,
--- a/xen/include/asm-x86/genapic.h
+++ b/xen/include/asm-x86/genapic.h
@@ -33,7 +33,6 @@ struct genapic {
int int_dest_mode;
void (*init_apic_ldr)(void);
void (*clustered_apic_check)(void);
- const cpumask_t *(*target_cpus)(void);
const cpumask_t *(*vector_allocation_cpumask)(int cpu);
unsigned int (*cpu_mask_to_apicid)(const cpumask_t *cpumask);
void (*send_IPI_mask)(const cpumask_t *mask, int vector);
@@ -51,7 +50,6 @@ struct genapic {
extern const struct genapic *genapic;
extern const struct genapic apic_default;
-const cpumask_t *target_cpus_all(void);
void send_IPI_self_legacy(uint8_t vector);
void init_apic_ldr_flat(void);
@@ -64,7 +62,6 @@ const cpumask_t *vector_allocation_cpuma
.int_dest_mode = 1 /* logical delivery */, \
.init_apic_ldr = init_apic_ldr_flat, \
.clustered_apic_check = clustered_apic_check_flat, \
- .target_cpus = target_cpus_all, \
.vector_allocation_cpumask = vector_allocation_cpumask_flat, \
.cpu_mask_to_apicid = cpu_mask_to_apicid_flat, \
.send_IPI_mask = send_IPI_mask_flat, \
@@ -80,7 +77,6 @@ const cpumask_t *vector_allocation_cpuma
.int_dest_mode = 0 /* physical delivery */, \
.init_apic_ldr = init_apic_ldr_phys, \
.clustered_apic_check = clustered_apic_check_phys, \
- .target_cpus = target_cpus_all, \
.vector_allocation_cpumask = vector_allocation_cpumask_phys, \
.cpu_mask_to_apicid = cpu_mask_to_apicid_phys, \
.send_IPI_mask = send_IPI_mask_phys, \
--- a/xen/include/asm-x86/mach-generic/mach_apic.h
+++ b/xen/include/asm-x86/mach-generic/mach_apic.h
@@ -12,7 +12,7 @@
/* The following are dependent on APIC delivery mode (logical vs. physical). */
#define INT_DELIVERY_MODE (genapic->int_delivery_mode)
#define INT_DEST_MODE (genapic->int_dest_mode)
-#define TARGET_CPUS (genapic->target_cpus())
+#define TARGET_CPUS ((const typeof(cpu_online_map) *)_online_map)
#define init_apic_ldr (genapic->init_apic_ldr)
#define clustered_apic_check (genapic->clustered_apic_check)
#define cpu_mask_to_apicid (genapic->cpu_mask_to_apicid)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 12/16] x86: patch ctxt_switch_masking() indirect call to direct one
Signed-off-by: Jan Beulich --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -196,7 +196,7 @@ void ctxt_switch_levelling(const struct } if (ctxt_switch_masking) - ctxt_switch_masking(next); + alternative_vcall1(ctxt_switch_masking, next); } bool_t opt_cpu_info; ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 11/16] x86/HVM: patch vINTR indirect calls through hvm_funcs to direct ones
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explictly)
initialized function pointer.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -111,10 +111,15 @@ static void vlapic_clear_irr(int vector,
vlapic_clear_vector(vector, >regs->data[APIC_IRR]);
}
-static int vlapic_find_highest_irr(struct vlapic *vlapic)
+static void sync_pir_to_irr(struct vcpu *v)
{
if ( hvm_funcs.sync_pir_to_irr )
-hvm_funcs.sync_pir_to_irr(vlapic_vcpu(vlapic));
+alternative_vcall1(hvm_funcs.sync_pir_to_irr, v);
+}
+
+static int vlapic_find_highest_irr(struct vlapic *vlapic)
+{
+sync_pir_to_irr(vlapic_vcpu(vlapic));
return vlapic_find_highest_vector(>regs->data[APIC_IRR]);
}
@@ -143,7 +148,7 @@ bool vlapic_test_irq(const struct vlapic
return false;
if ( hvm_funcs.test_pir &&
- hvm_funcs.test_pir(const_vlapic_vcpu(vlapic), vec) )
+ alternative_call2(hvm_funcs.test_pir, const_vlapic_vcpu(vlapic), vec)
)
return true;
return vlapic_test_vector(vec, >regs->data[APIC_IRR]);
@@ -165,10 +170,10 @@ void vlapic_set_irq(struct vlapic *vlapi
vlapic_clear_vector(vec, >regs->data[APIC_TMR]);
if ( hvm_funcs.update_eoi_exit_bitmap )
-hvm_funcs.update_eoi_exit_bitmap(target, vec, trig);
+alternative_vcall3(hvm_funcs.update_eoi_exit_bitmap, target, vec,
trig);
if ( hvm_funcs.deliver_posted_intr )
-hvm_funcs.deliver_posted_intr(target, vec);
+alternative_vcall2(hvm_funcs.deliver_posted_intr, target, vec);
else if ( !vlapic_test_and_set_irr(vec, vlapic) )
vcpu_kick(target);
}
@@ -448,7 +453,7 @@ void vlapic_EOI_set(struct vlapic *vlapi
vlapic_clear_vector(vector, >regs->data[APIC_ISR]);
if ( hvm_funcs.handle_eoi )
-hvm_funcs.handle_eoi(vector);
+alternative_vcall1(hvm_funcs.handle_eoi, vector);
vlapic_handle_EOI(vlapic, vector);
@@ -1457,8 +1462,7 @@ static int lapic_save_regs(struct domain
for_each_vcpu ( d, v )
{
-if ( hvm_funcs.sync_pir_to_irr )
-hvm_funcs.sync_pir_to_irr(v);
+sync_pir_to_irr(v);
s = vcpu_vlapic(v);
if ( (rc = hvm_save_entry(LAPIC_REGS, v->vcpu_id, h, s->regs)) != 0 )
@@ -1561,7 +1565,8 @@ static int lapic_load_regs(struct domain
lapic_load_fixup(s);
if ( hvm_funcs.process_isr )
-hvm_funcs.process_isr(vlapic_find_highest_isr(s), v);
+alternative_vcall2(hvm_funcs.process_isr,
+ vlapic_find_highest_isr(s), v);
vlapic_adjust_i8259_target(d);
lapic_rearm(s);
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2280,12 +2280,6 @@ static struct hvm_function_table __initd
.nhvm_vcpu_vmexit_event = nvmx_vmexit_event,
.nhvm_intr_blocked= nvmx_intr_blocked,
.nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources,
-.update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap,
-.process_isr = vmx_process_isr,
-.deliver_posted_intr = vmx_deliver_posted_intr,
-.sync_pir_to_irr = vmx_sync_pir_to_irr,
-.test_pir = vmx_test_pir,
-.handle_eoi = vmx_handle_eoi,
.nhvm_hap_walk_L1_p2m = nvmx_hap_walk_L1_p2m,
.enable_msr_interception = vmx_enable_msr_interception,
.is_singlestep_supported = vmx_is_singlestep_supported,
@@ -2413,26 +2407,23 @@ const struct hvm_function_table * __init
setup_ept_dump();
}
-if ( !cpu_has_vmx_virtual_intr_delivery )
+if ( cpu_has_vmx_virtual_intr_delivery )
{
-vmx_function_table.update_eoi_exit_bitmap = NULL;
-vmx_function_table.process_isr = NULL;
-vmx_function_table.handle_eoi = NULL;
-}
-else
+vmx_function_table.update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap;
+vmx_function_table.process_isr = vmx_process_isr;
+vmx_function_table.handle_eoi = vmx_handle_eoi;
vmx_function_table.virtual_intr_delivery_enabled = true;
+}
if ( cpu_has_vmx_posted_intr_processing )
{
alloc_direct_apic_vector(_intr_vector,
pi_notification_interrupt);
if ( iommu_intpost )
alloc_direct_apic_vector(_wakeup_vector, pi_wakeup_interrupt);
-}
-else
-{
-vmx_function_table.deliver_posted_intr = NULL;
-vmx_function_table.sync_pir_to_irr = NULL;
-vmx_function_table.test_pir = NULL;
+
+vmx_function_table.deliver_posted_intr = vmx_deliver_posted_intr;
+vmx_function_table.sync_pir_to_irr = vmx_sync_pir_to_irr;
+vmx_function_table.test_pir= vmx_test_pir;
}
if ( cpu_has_vmx_tsc_scaling )
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
[Xen-devel] [PATCH 10/16] x86/HVM: patch indirect calls through hvm_funcs to direct ones
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent patch.
Signed-off-by: Jan Beulich
---
Needless to say that I'm pretty unhappy about the workaround I had to
add to hvm_set_rdtsc_exiting(). Improvement suggestions welcome.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2017,7 +2017,7 @@ static int hvmemul_write_msr(
static int hvmemul_wbinvd(
struct x86_emulate_ctxt *ctxt)
{
-hvm_funcs.wbinvd_intercept();
+alternative_vcall0(hvm_funcs.wbinvd_intercept);
return X86EMUL_OKAY;
}
@@ -2035,7 +2035,7 @@ static int hvmemul_get_fpu(
struct vcpu *curr = current;
if ( !curr->fpu_dirtied )
-hvm_funcs.fpu_dirty_intercept();
+alternative_vcall0(hvm_funcs.fpu_dirty_intercept);
else if ( type == X86EMUL_FPU_fpu )
{
const typeof(curr->arch.xsave_area->fpu_sse) *fpu_ctxt =
@@ -2152,7 +2152,7 @@ static void hvmemul_put_fpu(
{
curr->fpu_dirtied = false;
stts();
-hvm_funcs.fpu_leave(curr);
+alternative_vcall1(hvm_funcs.fpu_leave, curr);
}
}
}
@@ -2314,7 +2314,8 @@ static int _hvm_emulate_one(struct hvm_e
if ( hvmemul_ctxt->intr_shadow != new_intr_shadow )
{
hvmemul_ctxt->intr_shadow = new_intr_shadow;
-hvm_funcs.set_interrupt_shadow(curr, new_intr_shadow);
+alternative_vcall2(hvm_funcs.set_interrupt_shadow,
+ curr, new_intr_shadow);
}
if ( hvmemul_ctxt->ctxt.retire.hlt &&
@@ -2451,7 +2452,8 @@ void hvm_emulate_init_once(
memset(hvmemul_ctxt, 0, sizeof(*hvmemul_ctxt));
-hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(curr);
+hvmemul_ctxt->intr_shadow =
+alternative_call1(hvm_funcs.get_interrupt_shadow, curr);
hvmemul_get_seg_reg(x86_seg_cs, hvmemul_ctxt);
hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -271,13 +271,24 @@ void hvm_set_rdtsc_exiting(struct domain
{
struct vcpu *v;
+#if __GNUC__ >= 7
+/*
+ * gcc from 7.x onwards warns about ternary operators with their middle operand
+ * omitted and the controlling expression itself being of _Bool type.
+ */
+# pragma GCC diagnostic push
+# pragma GCC diagnostic ignored "-Wparentheses"
+#endif
for_each_vcpu ( d, v )
-hvm_funcs.set_rdtsc_exiting(v, enable);
+alternative_vcall2(hvm_funcs.set_rdtsc_exiting, v, enable);
+#if __GNUC__ >= 7
+# pragma GCC diagnostic pop
+#endif
}
void hvm_get_guest_pat(struct vcpu *v, u64 *guest_pat)
{
-if ( !hvm_funcs.get_guest_pat(v, guest_pat) )
+if ( !alternative_call2(hvm_funcs.get_guest_pat, v, guest_pat) )
*guest_pat = v->arch.hvm_vcpu.pat_cr;
}
@@ -302,7 +313,7 @@ int hvm_set_guest_pat(struct vcpu *v, u6
return 0;
}
-if ( !hvm_funcs.set_guest_pat(v, guest_pat) )
+if ( !alternative_call2(hvm_funcs.set_guest_pat, v, guest_pat) )
v->arch.hvm_vcpu.pat_cr = guest_pat;
return 1;
@@ -342,7 +353,7 @@ bool hvm_set_guest_bndcfgs(struct vcpu *
/* nothing, best effort only */;
}
-return hvm_funcs.set_guest_bndcfgs(v, val);
+return alternative_call2(hvm_funcs.set_guest_bndcfgs, v, val);
}
/*
@@ -502,7 +513,8 @@ void hvm_migrate_pirqs(struct vcpu *v)
static bool hvm_get_pending_event(struct vcpu *v, struct x86_event *info)
{
info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
-return hvm_funcs.get_pending_event(v, info);
+
+return alternative_call2(hvm_funcs.get_pending_event, v, info);
}
void hvm_do_resume(struct vcpu *v)
@@ -1684,7 +1696,7 @@ void hvm_inject_event(const struct x86_e
}
}
-hvm_funcs.inject_event(event);
+alternative_vcall1(hvm_funcs.inject_event, event);
}
int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
@@ -2271,7 +2283,7 @@ int hvm_set_cr0(unsigned long value, boo
(!rangeset_is_empty(d->iomem_caps) ||
!rangeset_is_empty(d->arch.ioport_caps) ||
has_arch_pdevs(d)) )
-hvm_funcs.handle_cd(v, value);
+alternative_vcall2(hvm_funcs.handle_cd, v, value);
hvm_update_cr(v, 0, value);
@@ -3515,7 +3527,8 @@ int hvm_msr_read_intercept(unsigned int
goto gp_fault;
/* If ret == 0 then this is not an MCE MSR, see other MSRs. */
ret = ((ret == 0)
- ? hvm_funcs.msr_read_intercept(msr, msr_content)
+ ? alternative_call2(hvm_funcs.msr_read_intercept,
+ msr, msr_content)
: X86EMUL_OKAY);
break;
}
@@ -3672,7 +3685,8 @@ int hvm_msr_write_intercept(unsigned int
goto gp_fault;
/* If ret == 0 then this
[Xen-devel] [PATCH 09/16] x86: infrastructure to allow converting certain indirect calls to direct ones
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls, making necessary a second passs through the
alternative patching code. Therefore some adjustments beyond the
recognition of the new special pattern are necessary there.
Note that patching such sites more than once is not supported (and the
supplied macros also don't provide any means to do so).
Also a note on alternative_call_clobber(): The particular compiler error
("unable to find a register to spill") was observed on gcc 7.x only,
other than the similar one in shadow code that was taken care of earlier
in the series. I hope it is acceptable to require invoking that macro in
a small set of places.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -160,8 +160,9 @@ text_poke(void *addr, const void *opcode
* APs have less capabilities than the boot processor are not handled.
* Tough. Make sure you disable such features by hand.
*/
-void init_or_livepatch apply_alternatives(struct alt_instr *start,
- struct alt_instr *end)
+static void init_or_livepatch _apply_alternatives(struct alt_instr *start,
+ struct alt_instr *end,
+ bool force)
{
struct alt_instr *a, *base;
@@ -200,6 +201,13 @@ void init_or_livepatch apply_alternative
if ( ALT_ORIG_PTR(base) != orig )
base = a;
+/* Skip patch sites already handled during the first pass. */
+if ( a->priv )
+{
+ASSERT(force);
+continue;
+}
+
/* If there is no replacement to make, see about optimising the nops.
*/
if ( !boot_cpu_has(a->cpuid) )
{
@@ -207,7 +215,7 @@ void init_or_livepatch apply_alternative
if ( base->priv )
continue;
-base->priv = 1;
+a->priv = 1;
/* Nothing useful to do? */
if ( a->pad_len <= 1 )
@@ -212,13 +220,64 @@ void init_or_livepatch apply_alternative
continue;
}
-base->priv = 1;
-
memcpy(buf, repl, a->repl_len);
/* 0xe8/0xe9 are relative branches; fix the offset. */
if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
-*(int32_t *)(buf + 1) += repl - orig;
+{
+/*
+ * Detect the special case of indirect-to-direct branch patching:
+ * - replacement is a direct CALL/JMP (opcodes 0xE8/0xE9; already
+ * checked above),
+ * - replacement's displacement is -5 (pointing back at the very
+ * insn, which makes no sense in a real replacement insn),
+ * - original is an indirect CALL/JMP (opcodes 0xFF/2 or 0xFF/4)
+ * using RIP-relative addressing.
+ * Some function targets may not be available when we come here
+ * the first time. Defer patching of those until the post-presmp-
+ * initcalls re-invocation. If at that point the target pointer is
+ * still NULL, insert "UD2; UD0" (for ease of recognition) instead
+ * of CALL/JMP.
+ */
+if ( a->cpuid == X86_FEATURE_ALWAYS &&
+ *(int32_t *)(buf + 1) == -5 &&
+ a->orig_len >= 6 &&
+ orig[0] == 0xff &&
+ orig[1] == (*buf & 1 ? 0x25 : 0x15) )
+{
+long disp = *(int32_t *)(orig + 2);
+const uint8_t *dest = *(void **)(orig + 6 + disp);
+
+if ( dest )
+{
+disp = dest - (orig + 5);
+ASSERT(disp == (int32_t)disp);
+*(int32_t *)(buf + 1) = disp;
+}
+else if ( force )
+{
+buf[0] = 0x0f;
+buf[1] = 0x0b;
+buf[2] = 0x0f;
+buf[3] = 0xff;
+buf[4] = 0xff;
+}
+else
+continue;
+}
+else if ( force && system_state < SYS_STATE_active )
+ASSERT_UNREACHABLE();
+else
+*(int32_t *)(buf + 1) += repl - orig;
+}
+else if ( force && system_state < SYS_STATE_active )
+ASSERT_UNREACHABLE();
/* RIP-relative addressing is easy to check for in VEX-encoded insns.
*/
else if ( a->repl_len >= 8 &&
(*buf & ~1) == 0xc4 &&
@@ -232,12 +291,21 @@ void init_or_livepatch apply_alternative
(buf[4 - (*buf & 1)] & ~0x38) == 0x05 )
*(int32_t *)(buf + 5 - (*buf & 1))
[Xen-devel] [PATCH 08/16] x86/alternatives: allow using assembler macros in favor of C ones
As was validly pointed out as motivation for similar Linux side changes
(https://lkml.org/lkml/2018/6/22/677), using long sequences of
directives and auxiliary instructions, like is commonly the case when
setting up an alternative patch site, gcc can be mislead into believing
an asm() to be more heavy weight than it really is. By presenting it
with an assembler macro invocation instead, this can be avoided.
Initially I wanted to outright change the C macros ALTERNATIVE() and
ALTERNATIVE_2() to invoke the respective assembler ones, but doing so
would require quite a bit of cleanup of some use sites, because of the
exra necessary quoting combined with the need that each assembler macro
argument must consist of just a single string literal. We can consider
working towards that subsequently.
For now, set the stage of using the assembler macros here by providing a
new generated header, being the slightly massaged pre-processor output
of (for now just) alternative-asm.h. The massaging is primarily to be
able to properly track the build dependency: For this, we need the C
compiler to see the inclusion, which means we shouldn't directly use an
asm(". include ...") directive.
The dependency added to asm-offsets.s is not a true one; it's just the
easiest approach I could think of to make sure the new header gets
generated early on, without having to fiddle with xen/Makefile (and
introducing some x86-specific construct there).
Signed-off-by: Jan Beulich
--- a/.gitignore
+++ b/.gitignore
@@ -293,6 +293,7 @@ xen/.config.old
xen/System.map
xen/arch/arm/asm-offsets.s
xen/arch/arm/xen.lds
+xen/arch/x86/asm-macros.i
xen/arch/x86/asm-offsets.s
xen/arch/x86/boot/mkelf32
xen/arch/x86/xen.lds
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -209,9 +209,22 @@ $(TARGET).efi: prelink-efi.o $(note_file
efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o:
$(BASEDIR)/arch/x86/efi/built_in.o
efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o: ;
-asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
+asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
$(BASEDIR)/include/asm-x86/asm-macros.h
$(CC) $(filter-out -Wa$(comma)% -flto,$(CFLAGS)) -S -o $@ $<
+asm-macros.i: CFLAGS += -D__ASSEMBLY__ -P
+
+$(BASEDIR)/include/asm-x86/asm-macros.h: asm-macros.i Makefile
+ echo '#if 0' >$@.new
+ echo '.if 0' >>$@.new
+ echo '#endif' >>$@.new
+ echo 'asm ( ".include \"$@\"" );' >>$@.new
+ echo '#if 0' >>$@.new
+ echo '.endif' >>$@.new
+ cat $< >>$@.new
+ echo '#endif' >>$@.new
+ $(call move-if-changed,$@.new,$@)
+
xen.lds: xen.lds.S
$(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
@@ -231,6 +244,7 @@ efi/mkreloc: efi/mkreloc.c
.PHONY: clean
clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
+ rm -f asm-macros.i $(BASEDIR)/include/asm-x86/asm-macros.*
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
--- /dev/null
+++ b/xen/arch/x86/asm-macros.c
@@ -0,0 +1 @@
+#include
--- a/xen/include/asm-x86/alternative.h
+++ b/xen/include/asm-x86/alternative.h
@@ -1,11 +1,12 @@
#ifndef __X86_ALTERNATIVE_H__
#define __X86_ALTERNATIVE_H__
+#ifdef __ASSEMBLY__
#include
-
-#ifndef __ASSEMBLY__
+#else
#include
#include
+#include
struct __packed alt_instr {
int32_t orig_offset; /* original instruction */
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 07/16] x86/shadow: fetch CPL just once in sh_page_fault()
This isn't as much of an optimization than to avoid triggering a gcc bug
affecting 5.x ... 7.x, triggered by any asm() put inside the ad hoc
"rewalk" loop and taking as an (output?) operand a register variable
tied to %rdx (an "rdx" clobber is fine). The issue is due to an apparent
collision in register use with the modulo operation in vtlb_hash(),
which (with optimization enabled) involves a multiplication of two
64-bit values with the upper half (in %rdx) of the 128-bit result being
of interest.
Such an asm() was originally meant to be implicitly introduced into the
code when converting most indirect calls through the hvm_funcs table to
direct calls (via alternative instruction patching); that model was
switched to clobbers due to further compiler problems, but I think the
change here is worthwhile nevertheless.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2817,6 +2817,7 @@ static int sh_page_fault(struct vcpu *v,
uint32_t rc, error_code;
bool walk_ok;
int version;
+unsigned int cpl;
const struct npfec access = {
.read_access = 1,
.write_access = !!(regs->error_code & PFEC_write_access),
@@ -2967,6 +2968,8 @@ static int sh_page_fault(struct vcpu *v,
return 0;
}
+cpl = is_pv_vcpu(v) ? (regs->ss & 3) : hvm_get_cpl(v);
+
rewalk:
error_code = regs->error_code;
@@ -3023,8 +3026,7 @@ static int sh_page_fault(struct vcpu *v,
* If this corner case comes about accidentally, then a security-relevant
* bug has been tickled.
*/
-if ( !(error_code & (PFEC_insn_fetch|PFEC_user_mode)) &&
- (is_pv_vcpu(v) ? (regs->ss & 3) : hvm_get_cpl(v)) == 3 )
+if ( !(error_code & (PFEC_insn_fetch|PFEC_user_mode)) && cpl == 3 )
error_code |= PFEC_implicit;
/* The walk is done in a lock-free style, with some sanity check
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 06/16] x86: allow producing .i or .s for multiply compiled files
Since the generic pattern rules don't match those, explicit rules need to be put in place for this to work. Signed-off-by: Jan Beulich --- a/xen/Makefile +++ b/xen/Makefile @@ -249,6 +249,17 @@ FORCE: %/: FORCE $(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o +build-intermediate = $(eval $(call build-intermediate-closure,$(1))) +define build-intermediate-closure +$(1): FORCE + $(MAKE) -f $(BASEDIR)/Rules.mk -C $$(@D) $$(@F) +endef + +$(foreach base,arch/x86/mm/guest_walk_% \ + arch/x86/mm/hap/guest_walk_%level \ + arch/x86/mm/shadow/guest_%, \ +$(foreach ext,o i s,$(call build-intermediate,$(base).$(ext + kconfig := silentoldconfig oldconfig config menuconfig defconfig \ nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig \ randconfig --- a/xen/arch/x86/mm/Makefile +++ b/xen/arch/x86/mm/Makefile @@ -13,3 +13,9 @@ obj-y += mem_access.o guest_walk_%.o: guest_walk.c Makefile $(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@ + +guest_walk_%.i: guest_walk.c Makefile + $(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@ + +guest_walk_%.s: guest_walk.c Makefile + $(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@ --- a/xen/arch/x86/mm/hap/Makefile +++ b/xen/arch/x86/mm/hap/Makefile @@ -7,3 +7,9 @@ obj-y += nested_ept.o guest_walk_%level.o: guest_walk.c Makefile $(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@ + +guest_walk_%level.i: guest_walk.c Makefile + $(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@ + +guest_walk_%level.s: guest_walk.c Makefile + $(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@ --- a/xen/arch/x86/mm/shadow/Makefile +++ b/xen/arch/x86/mm/shadow/Makefile @@ -6,3 +6,9 @@ endif guest_%.o: multi.c Makefile $(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@ + +guest_%.i: multi.c Makefile + $(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -c $< -o $@ + +guest_%.s: multi.c Makefile + $(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -DGUEST_PAGING_LEVELS=$* -S $< -o $@ ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 05/16] x86/HVM: add wrapper for hvm_funcs.set_tsc_offset()
It's used in quite a few places, and hence doing so eases subsequent
adjustment to how these (indirect) calls are carried out.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/domain.c
+++ b/xen/arch/x86/hvm/domain.c
@@ -317,9 +317,9 @@ int arch_set_info_hvm_guest(struct vcpu
/* Sync AP's TSC with BSP's. */
v->arch.hvm_vcpu.cache_tsc_offset =
-v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
-hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset,
- v->domain->arch.hvm_domain.sync_tsc);
+d->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
+hvm_set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset,
+ d->arch.hvm_domain.sync_tsc);
paging_update_paging_modes(v);
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -417,7 +417,7 @@ static void hvm_set_guest_tsc_fixed(stru
delta_tsc = guest_tsc - tsc;
v->arch.hvm_vcpu.cache_tsc_offset = delta_tsc;
-hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset, at_tsc);
+hvm_set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset, at_tsc);
}
#define hvm_set_guest_tsc(v, t) hvm_set_guest_tsc_fixed(v, t, 0)
@@ -435,7 +435,7 @@ static void hvm_set_guest_tsc_adjust(str
{
v->arch.hvm_vcpu.cache_tsc_offset += tsc_adjust
- v->arch.hvm_vcpu.msr_tsc_adjust;
-hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset, 0);
+hvm_set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset, 0);
v->arch.hvm_vcpu.msr_tsc_adjust = tsc_adjust;
}
@@ -3934,8 +3934,8 @@ void hvm_vcpu_reset_state(struct vcpu *v
/* Sync AP's TSC with BSP's. */
v->arch.hvm_vcpu.cache_tsc_offset =
v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
-hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset,
- d->arch.hvm_domain.sync_tsc);
+hvm_set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset,
+ d->arch.hvm_domain.sync_tsc);
v->arch.hvm_vcpu.msr_tsc_adjust = 0;
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1082,7 +1082,7 @@ static void load_shadow_guest_state(stru
hvm_inject_hw_exception(TRAP_gp_fault, 0);
}
-hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset, 0);
+hvm_set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset, 0);
vvmcs_to_shadow_bulk(v, ARRAY_SIZE(vmentry_fields), vmentry_fields);
@@ -1288,7 +1288,7 @@ static void load_vvmcs_host_state(struct
hvm_inject_hw_exception(TRAP_gp_fault, 0);
}
-hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset, 0);
+hvm_set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset, 0);
set_vvmcs(v, VM_ENTRY_INTR_INFO, 0);
}
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -2198,9 +2198,9 @@ void tsc_set_info(struct domain *d,
* will sync their TSC to BSP's sync_tsc.
*/
d->arch.hvm_domain.sync_tsc = rdtsc();
-hvm_funcs.set_tsc_offset(d->vcpu[0],
-
d->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset,
- d->arch.hvm_domain.sync_tsc);
+hvm_set_tsc_offset(d->vcpu[0],
+ d->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset,
+ d->arch.hvm_domain.sync_tsc);
}
}
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -347,6 +347,12 @@ static inline void hvm_cpuid_policy_chan
hvm_funcs.cpuid_policy_changed(v);
}
+static inline void hvm_set_tsc_offset(struct vcpu *v, uint64_t offset,
+ uint64_t at_tsc)
+{
+hvm_funcs.set_tsc_offset(v, offset, at_tsc);
+}
+
/*
* Called to ensure than all guest-specific mappings in a tagged TLB are
* flushed; does *not* flush Xen's TLB entries, and on processors without a
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 04/16] x86/HVM: drop vmfunc_intercept
Commit a1b1572833 ("VMX: add VMFUNC leaf 0 (EPTP switching) to
emulator") needlessly introduced it, and no user has appeared since.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -76,7 +76,6 @@ static void vmx_fpu_dirty_intercept(void
static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content);
static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content);
static void vmx_invlpg(struct vcpu *v, unsigned long vaddr);
-static int vmx_vmfunc_intercept(struct cpu_user_regs *regs);
/* Values for domain's ->arch.hvm_domain.pi_ops.flags. */
#define PI_CSW_FROM (1u << 0)
@@ -2312,7 +2311,6 @@ static struct hvm_function_table __initd
.fpu_dirty_intercept = vmx_fpu_dirty_intercept,
.msr_read_intercept = vmx_msr_read_intercept,
.msr_write_intercept = vmx_msr_write_intercept,
-.vmfunc_intercept = vmx_vmfunc_intercept,
.handle_cd= vmx_handle_cd,
.set_info_guest = vmx_set_info_guest,
.set_rdtsc_exiting= vmx_set_rdtsc_exiting,
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -176,7 +176,6 @@ struct hvm_function_table {
void (*fpu_dirty_intercept)(void);
int (*msr_read_intercept)(unsigned int msr, uint64_t *msr_content);
int (*msr_write_intercept)(unsigned int msr, uint64_t msr_content);
-int (*vmfunc_intercept)(struct cpu_user_regs *regs);
void (*handle_cd)(struct vcpu *v, unsigned long value);
void (*set_info_guest)(struct vcpu *v);
void (*set_rdtsc_exiting)(struct vcpu *v, bool_t);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 03/16] x86/HVM: switch virtual_intr_delivery_enabled() hook to simple boolean
From: Suravee Suthikulpanit
This patch modifies the hvm_funcs.virtual_intr_delivery_enabled()
to become a bool variable as VMX does and SVM will simply return a
static value.
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Jan Beulich
---
Extracted from an SVM/AVIC series patch.
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1258,14 +1258,6 @@ void vlapic_adjust_i8259_target(struct d
pt_adjust_global_vcpu_target(v);
}
-int vlapic_virtual_intr_delivery_enabled(void)
-{
-if ( hvm_funcs.virtual_intr_delivery_enabled )
-return hvm_funcs.virtual_intr_delivery_enabled();
-else
-return 0;
-}
-
int vlapic_has_pending_irq(struct vcpu *v)
{
struct vlapic *vlapic = vcpu_vlapic(v);
@@ -1278,7 +1270,7 @@ int vlapic_has_pending_irq(struct vcpu *
if ( irr == -1 )
return -1;
-if ( vlapic_virtual_intr_delivery_enabled() &&
+if ( hvm_funcs.virtual_intr_delivery_enabled &&
!nestedhvm_vcpu_in_guestmode(v) )
return irr;
@@ -1316,7 +1308,7 @@ int vlapic_ack_pending_irq(struct vcpu *
int isr;
if ( !force_ack &&
- vlapic_virtual_intr_delivery_enabled() )
+ hvm_funcs.virtual_intr_delivery_enabled )
return 1;
/* If there's no chance of using APIC assist then bail now. */
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1948,11 +1948,6 @@ static void vmx_update_eoi_exit_bitmap(s
vmx_clear_eoi_exit_bitmap(v, vector);
}
-static int vmx_virtual_intr_delivery_enabled(void)
-{
-return cpu_has_vmx_virtual_intr_delivery;
-}
-
static void vmx_process_isr(int isr, struct vcpu *v)
{
unsigned long status;
@@ -2331,7 +2326,6 @@ static struct hvm_function_table __initd
.nhvm_intr_blocked= nvmx_intr_blocked,
.nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources,
.update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap,
-.virtual_intr_delivery_enabled = vmx_virtual_intr_delivery_enabled,
.process_isr = vmx_process_isr,
.deliver_posted_intr = vmx_deliver_posted_intr,
.sync_pir_to_irr = vmx_sync_pir_to_irr,
@@ -2470,6 +2464,8 @@ const struct hvm_function_table * __init
vmx_function_table.process_isr = NULL;
vmx_function_table.handle_eoi = NULL;
}
+else
+vmx_function_table.virtual_intr_delivery_enabled = true;
if ( cpu_has_vmx_posted_intr_processing )
{
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -97,6 +97,9 @@ struct hvm_function_table {
/* Necessary hardware support for alternate p2m's? */
bool altp2m_supported;
+/* Hardware virtual interrupt delivery enable? */
+bool virtual_intr_delivery_enabled;
+
/* Indicate HAP capabilities. */
unsigned int hap_capabilities;
@@ -195,7 +198,6 @@ struct hvm_function_table {
/* Virtual interrupt delivery */
void (*update_eoi_exit_bitmap)(struct vcpu *v, u8 vector, u8 trig);
-int (*virtual_intr_delivery_enabled)(void);
void (*process_isr)(int isr, struct vcpu *v);
void (*deliver_posted_intr)(struct vcpu *v, u8 vector);
void (*sync_pir_to_irr)(struct vcpu *v);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 02/16] VMX: don't unconditionally set the tsc_scaling.setup hook
Instead of checking hvm_tsc_scaling_supported inside the hook function,
install the hook only when setting state such that said predicate
becomes true.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1283,7 +1283,7 @@ static void vmx_handle_cd(struct vcpu *v
static void vmx_setup_tsc_scaling(struct vcpu *v)
{
-if ( !hvm_tsc_scaling_supported || v->domain->arch.vtsc )
+if ( v->domain->arch.vtsc )
return;
vmx_vmcs_enter(v);
@@ -2346,7 +2346,6 @@ static struct hvm_function_table __initd
.altp2m_vcpu_emulate_vmfunc = vmx_vcpu_emulate_vmfunc,
.tsc_scaling = {
.max_ratio = VMX_TSC_MULTIPLIER_MAX,
-.setup = vmx_setup_tsc_scaling,
},
};
@@ -2486,7 +2485,10 @@ const struct hvm_function_table * __init
}
if ( cpu_has_vmx_tsc_scaling )
+{
vmx_function_table.tsc_scaling.ratio_frac_bits = 48;
+vmx_function_table.tsc_scaling.setup = vmx_setup_tsc_scaling;
+}
if ( cpu_has_mpx && cpu_has_vmx_mpx )
{
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 01/16] VMX: reduce number of posted-interrupt hooks
Three of the four hooks are not exposed outside of vmx.c, and all of
them have only a single possible non-NULL value. So there's no reason to
use hooks here - a simple set of flag indicators is sufficient (and we
don't even need a flag for the VM entry one, as it's always
(de-)activated together the the vCPU blocking hook, which needs to
remain an actual function pointer). This is the more that with the
Spectre v2 workarounds indirect calls have become more expensive.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -78,6 +78,10 @@ static int vmx_msr_write_intercept(unsig
static void vmx_invlpg(struct vcpu *v, unsigned long vaddr);
static int vmx_vmfunc_intercept(struct cpu_user_regs *regs);
+/* Values for domain's ->arch.hvm_domain.pi_ops.flags. */
+#define PI_CSW_FROM (1u << 0)
+#define PI_CSW_TO (1u << 1)
+
struct vmx_pi_blocking_vcpu {
struct list_head list;
spinlock_t lock;
@@ -330,8 +334,7 @@ void vmx_pi_hooks_assign(struct domain *
* This can make sure the PI (especially the NDST feild) is
* in proper state when we call vmx_vcpu_block().
*/
-d->arch.hvm_domain.pi_ops.switch_from = vmx_pi_switch_from;
-d->arch.hvm_domain.pi_ops.switch_to = vmx_pi_switch_to;
+d->arch.hvm_domain.pi_ops.flags = PI_CSW_FROM | PI_CSW_TO;
for_each_vcpu ( d, v )
{
@@ -347,7 +350,6 @@ void vmx_pi_hooks_assign(struct domain *
}
d->arch.hvm_domain.pi_ops.vcpu_block = vmx_vcpu_block;
-d->arch.hvm_domain.pi_ops.do_resume = vmx_pi_do_resume;
}
/* This function is called when pcidevs_lock is held */
@@ -384,8 +386,7 @@ void vmx_pi_hooks_deassign(struct domain
* 'switch_to' hook function.
*/
d->arch.hvm_domain.pi_ops.vcpu_block = NULL;
-d->arch.hvm_domain.pi_ops.switch_from = NULL;
-d->arch.hvm_domain.pi_ops.do_resume = NULL;
+d->arch.hvm_domain.pi_ops.flags = PI_CSW_FROM;
for_each_vcpu ( d, v )
vmx_pi_unblock_vcpu(v);
@@ -929,8 +930,8 @@ static void vmx_ctxt_switch_from(struct
vmx_restore_host_msrs();
vmx_save_dr(v);
-if ( v->domain->arch.hvm_domain.pi_ops.switch_from )
-v->domain->arch.hvm_domain.pi_ops.switch_from(v);
+if ( v->domain->arch.hvm_domain.pi_ops.flags & PI_CSW_FROM )
+vmx_pi_switch_from(v);
}
static void vmx_ctxt_switch_to(struct vcpu *v)
@@ -938,8 +939,8 @@ static void vmx_ctxt_switch_to(struct vc
vmx_restore_guest_msrs(v);
vmx_restore_dr(v);
-if ( v->domain->arch.hvm_domain.pi_ops.switch_to )
-v->domain->arch.hvm_domain.pi_ops.switch_to(v);
+if ( v->domain->arch.hvm_domain.pi_ops.flags & PI_CSW_TO )
+vmx_pi_switch_to(v);
}
@@ -4307,8 +4308,8 @@ bool vmx_vmenter_helper(const struct cpu
if ( nestedhvm_vcpu_in_guestmode(curr) && vcpu_nestedhvm(curr).stale_np2m
)
return false;
-if ( curr->domain->arch.hvm_domain.pi_ops.do_resume )
-curr->domain->arch.hvm_domain.pi_ops.do_resume(curr);
+if ( curr->domain->arch.hvm_domain.pi_ops.vcpu_block )
+vmx_pi_do_resume(curr);
if ( !cpu_has_vmx_vpid )
goto out;
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -80,20 +80,13 @@ struct hvm_ioreq_server {
* and actually has a physical device assigned .
*/
struct hvm_pi_ops {
-/* Hook into ctx_switch_from. */
-void (*switch_from)(struct vcpu *v);
-
-/* Hook into ctx_switch_to. */
-void (*switch_to)(struct vcpu *v);
+unsigned int flags;
/*
* Hook into arch_vcpu_block(), which is called
* from vcpu_block() and vcpu_do_poll().
*/
void (*vcpu_block)(struct vcpu *);
-
-/* Hook into the vmentry path. */
-void (*do_resume)(struct vcpu *v);
};
#define MAX_NR_IOREQ_SERVERS 8
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 125104: all pass - PUSHED
flight 125104 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/125104/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 784d607328d1205ced136be9f87c76ee51bcac5e baseline version: freebsd 22dad49e0cc4b54f18127cf74d71dd8967458ac8 Last test of basis 125060 2018-07-09 09:19:03 Z2 days Testing same since 125104 2018-07-11 09:18:44 Z0 days1 attempts People who touched revisions under test: ae alc araujo bdrewery brooks bwidawsk cy dab daichi delphij garga gonzo ian imp jhibbits kevans kib manu markj np pfg rmacklem sef smh tuexen wma jobs: build-amd64-freebsd-againpass build-amd64-freebsd 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/freebsd.git 22dad49e0cc..784d607328d 784d607328d1205ced136be9f87c76ee51bcac5e -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] automation/build: build ovmf
Install nasm and build ovmf with gcc on x86.
Signed-off-by: Wei Liu
---
I have tested stretch 64 bit and 32 bit containers.
I haven't tested the build script itself.
---
automation/build/centos/7.2.dockerfile | 1 +
automation/build/debian/jessie.dockerfile | 1 +
automation/build/debian/stretch-i386.dockerfile | 1 +
automation/build/debian/stretch.dockerfile | 1 +
automation/build/ubuntu/trusty.dockerfile | 1 +
automation/build/ubuntu/xenial.dockerfile | 1 +
automation/scripts/build| 2 ++
7 files changed, 8 insertions(+)
diff --git a/automation/build/centos/7.2.dockerfile
b/automation/build/centos/7.2.dockerfile
index b9b626a9b1..c2f46b694c 100644
--- a/automation/build/centos/7.2.dockerfile
+++ b/automation/build/centos/7.2.dockerfile
@@ -46,4 +46,5 @@ RUN rpm --rebuilddb && \
dev86 \
xz-devel \
bzip2 \
+nasm \
&& yum clean all
diff --git a/automation/build/debian/jessie.dockerfile
b/automation/build/debian/jessie.dockerfile
index 9bb1bdf104..bd04209f7f 100644
--- a/automation/build/debian/jessie.dockerfile
+++ b/automation/build/debian/jessie.dockerfile
@@ -41,6 +41,7 @@ RUN apt-get update && \
checkpolicy \
wget \
git \
+nasm \
&& \
apt-get autoremove -y && \
apt-get clean && \
diff --git a/automation/build/debian/stretch-i386.dockerfile
b/automation/build/debian/stretch-i386.dockerfile
index 5b77c90db3..ec37a5fbf8 100644
--- a/automation/build/debian/stretch-i386.dockerfile
+++ b/automation/build/debian/stretch-i386.dockerfile
@@ -43,6 +43,7 @@ RUN apt-get update && \
checkpolicy \
wget \
git \
+nasm \
&& \
apt-get autoremove -y && \
apt-get clean && \
diff --git a/automation/build/debian/stretch.dockerfile
b/automation/build/debian/stretch.dockerfile
index f068457ab6..9be09c5377 100644
--- a/automation/build/debian/stretch.dockerfile
+++ b/automation/build/debian/stretch.dockerfile
@@ -41,6 +41,7 @@ RUN apt-get update && \
checkpolicy \
wget \
git \
+nasm \
&& \
apt-get autoremove -y && \
apt-get clean && \
diff --git a/automation/build/ubuntu/trusty.dockerfile
b/automation/build/ubuntu/trusty.dockerfile
index cc750873e3..1d04bccbdf 100644
--- a/automation/build/ubuntu/trusty.dockerfile
+++ b/automation/build/ubuntu/trusty.dockerfile
@@ -41,6 +41,7 @@ RUN apt-get update && \
checkpolicy \
wget \
git \
+nasm \
&& \
apt-get autoremove -y && \
apt-get clean && \
diff --git a/automation/build/ubuntu/xenial.dockerfile
b/automation/build/ubuntu/xenial.dockerfile
index aa551c1b5c..37869e39ed 100644
--- a/automation/build/ubuntu/xenial.dockerfile
+++ b/automation/build/ubuntu/xenial.dockerfile
@@ -41,6 +41,7 @@ RUN apt-get update && \
checkpolicy \
wget \
git \
+nasm \
&& \
apt-get autoremove -y && \
apt-get clean && \
diff --git a/automation/scripts/build b/automation/scripts/build
index 8bbca15a51..054226bd73 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -24,6 +24,8 @@ fi
if [[ "${XEN_TARGET_ARCH}" == "arm64" || "${XEN_TARGET_ARCH}" == "arm32" ]];
then
cfgargs+=("--disable-tools") # we don't have the cross depends installed
+elif [[ "${CC}" != "clang" ]]; then
+cfgargs+=("--enable-ovmf") # build ovmf with gcc on x86, arm doesn't use
in-tree ovmf
fi
./configure "${cfgargs[@]}"
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 00/16] x86: indirect call overhead reduction
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific hardware details, and hence the pointers used never
change once set. Here we can use alternatives patching to get rid of
the indirection.
From patch 8 onwards dependencies exist on earlier, yet to be reviewed
patches ("x86/alternatives: fully leverage automatic NOP filling" as well
as the "x86: improve PDX <-> PFN and alike translations" series at the
very least). I nevertheless wanted to enable a first round of review of
the series, the more that some of the patches (not just initial ones)
could perhaps be taken irrespective of those dependencies.
Further areas where indirect calls could be eliminated (and that I've put
on my todo list in case the general concept here is deemed reasonable)
are IOMMU, cpufreq, vPMU, and XSM. For some of these, the ARM side
would need dealing with as well - I'm not sure whether replacing indirect
calls by direct ones is worthwhile there as well; if not, the wrappers
would simply need to become function invocations in the ARM case.
01: VMX: reduce number of posted-interrupt hooks
02: VMX: don't unconditionally set the tsc_scaling.setup hook
03: x86/HVM: switch virtual_intr_delivery_enabled() hook to simple boolean
04: x86/HVM: drop vmfunc_intercept
05: x86/HVM: add wrapper for hvm_funcs.set_tsc_offset()
06: x86: allow producing .i or .s for multiply compiled files
07: x86/shadow: fetch CPL just once in sh_page_fault()
08: x86/alternatives: allow using assembler macros in favor of C ones
09: x86: infrastructure to allow converting certain indirect calls to direct
ones
10: x86/HVM: patch indirect calls through hvm_funcs to direct ones
11: x86/HVM: patch vINTR indirect calls through hvm_funcs to direct ones
12: x86: patch ctxt_switch_masking() indirect call to direct one
13: x86/genapic: drop .target_cpus() hook
14: x86/genapic: remove indirection from genapic hook accesses
15: x86/genapic: patch indirect calls to direct ones
16: x86/cpuidle: patch some indirect calls to direct ones
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 11/13] memory: add get_paged_gfn() as a wrapper...
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 11 July 2018 14:05
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; Ian Jackson ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ; Wei Liu
> Subject: Re: [PATCH v2 11/13] memory: add get_paged_gfn() as a wrapper...
>
> On 07/11/2018 01:31 PM, Paul Durrant wrote:
> >>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> >>> index c6b99c4116..510f37f100 100644
> >>> --- a/xen/common/grant_table.c
> >>> +++ b/xen/common/grant_table.c
> >>> @@ -375,39 +375,23 @@ static int get_paged_frame(unsigned long gfn,
> >> mfn_t *mfn,
> >>> struct page_info **page, bool readonly,
> >>> struct domain *rd)
> >>> {
> >>> -int rc = GNTST_okay;
> >>> -p2m_type_t p2mt;
> >>> -
> >>> -*mfn = INVALID_MFN;
> >>> -*page = get_page_from_gfn(rd, gfn, ,
> >>> - readonly ? P2M_ALLOC : P2M_UNSHARE);
> >>> -if ( !*page )
> >>> -{
> >>> -#ifdef P2M_SHARED_TYPES
> >>> -if ( p2m_is_shared(p2mt) )
> >>> -return GNTST_eagain;
> >>> -#endif
> >>> -#ifdef P2M_PAGES_TYPES
> >>> -if ( p2m_is_paging(p2mt) )
> >>> -{
> >>> -p2m_mem_paging_populate(rd, gfn);
> >>> -return GNTST_eagain;
> >>> -}
> >>> -#endif
> >>> -return GNTST_bad_page;
> >>> -}
> >>> +int rc;
> >>>
> >>> -if ( p2m_is_foreign(p2mt) )
> >> [snip]
> >>> {
> >> [snip]
> >>> -put_page(*page);
> >>> -*page = NULL;
> >>> -
> >>
> >> Comparing before-and-after, this seems to remove this
> 'p2m_is_foreign()'
> >> check. Am I missing something?
> >>
> >
> > I may be. I thought p2m_is_ram() ruled out foreign pages
> (p2m_is_any_ram() being the way to include foreign maps if required). I'll
> check.
>
> Looks like you're right. But then, are you sure that's what we want for
> the other callers? Might we not need to do an emulation that ends up
> writing into a foreign mapping, for instance?
If we do then I'd expect the emulation to know the domid that owns the page and
thus the page would not be foreign to the specified domid. In fact, for x86 at
least, get_page_from_gfn() will fail unless the domid of the page owner is
specified so there's no prospect of the page being foreign in the p2mt check
anyway.
Paul
>
> -George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 11/13] memory: add get_paged_gfn() as a wrapper...
On 07/11/2018 01:31 PM, Paul Durrant wrote:
>>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>>> index c6b99c4116..510f37f100 100644
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -375,39 +375,23 @@ static int get_paged_frame(unsigned long gfn,
>> mfn_t *mfn,
>>> struct page_info **page, bool readonly,
>>> struct domain *rd)
>>> {
>>> -int rc = GNTST_okay;
>>> -p2m_type_t p2mt;
>>> -
>>> -*mfn = INVALID_MFN;
>>> -*page = get_page_from_gfn(rd, gfn, ,
>>> - readonly ? P2M_ALLOC : P2M_UNSHARE);
>>> -if ( !*page )
>>> -{
>>> -#ifdef P2M_SHARED_TYPES
>>> -if ( p2m_is_shared(p2mt) )
>>> -return GNTST_eagain;
>>> -#endif
>>> -#ifdef P2M_PAGES_TYPES
>>> -if ( p2m_is_paging(p2mt) )
>>> -{
>>> -p2m_mem_paging_populate(rd, gfn);
>>> -return GNTST_eagain;
>>> -}
>>> -#endif
>>> -return GNTST_bad_page;
>>> -}
>>> +int rc;
>>>
>>> -if ( p2m_is_foreign(p2mt) )
>> [snip]
>>> {
>> [snip]
>>> -put_page(*page);
>>> -*page = NULL;
>>> -
>>
>> Comparing before-and-after, this seems to remove this 'p2m_is_foreign()'
>> check. Am I missing something?
>>
>
> I may be. I thought p2m_is_ram() ruled out foreign pages (p2m_is_any_ram()
> being the way to include foreign maps if required). I'll check.
Looks like you're right. But then, are you sure that's what we want for
the other callers? Might we not need to do an emulation that ends up
writing into a foreign mapping, for instance?
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/Makefile: Bump version to 4.11.1-pre for ongoing 4.11 stable branch
Ian Jackson writes ("[PATCH] xen/Makefile: Bump version to 4.11.1-pre for
ongoing 4.11 stable branch"):
> I will push this change on Wednesday, after 4.11 is released, and then
> 4.11 can be handed over to the stable maintainers.
Now done. staging-4.11 is open for business.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-next test] 125059: regressions - FAIL
flight 125059 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/125059/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. vs. 124994 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 17 guest-start.2fail REGR. vs. 124994 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail blocked in 124994 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail blocked in 124994 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 124994 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 124994 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 124994 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 124994 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124994 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 124994 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124994 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124994 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-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-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linuxd00d6d9a339d613f812e26c59d6b5983faa1af24 baseline version: linuxfc36def997cfd6cbff3eda4f82853a5c311c5466 Last test of basis
Re: [Xen-devel] [PATCH v2 12/13] x86: add iommu_ops to modify and flush IOMMU mappings
> -Original Message- > From: George Dunlap [mailto:george.dun...@citrix.com] > Sent: 11 July 2018 12:46 > To: Paul Durrant ; xen-devel@lists.xenproject.org > Cc: Jan Beulich ; Andrew Cooper > ; George Dunlap > ; Ian Jackson ; Julien > Grall ; Konrad Rzeszutek Wilk > ; Stefano Stabellini ; Tim > (Xen.org) ; Wei Liu > Subject: Re: [PATCH v2 12/13] x86: add iommu_ops to modify and flush > IOMMU mappings > > On 07/07/2018 12:05 PM, Paul Durrant wrote: > > This patch adds iommu_ops to add (map) or remove (unmap) frames in the > > domain's IOMMU mappings, and an iommu_op to synchronize (flush) > those > > manipulations with the hardware. > > > > Mappings added by the map operation are tracked and only those > mappings > > may be removed by a subsequent unmap operation. Frames are specified > by the > > owning domain and GFN. It is, of course, permissable for a domain to map > > its own frames using DOMID_SELF. > > > > NOTE: The owning domain and GFN must also be specified in the unmap > > operation, as well as the BFN, so that they can be cross-checked > > with the existent mapping. > > > > Signed-off-by: Paul Durrant > > The code on the whole looks correct, but I don't see any reference > counting. The call to get_paged_gfn() in iommuop_unmap() kind of > underlines the issue -- what's to stop the following sequence of events? > > * iommuop_map() page A > * share(A) > * DMA write into A # > I don't follow. In iommuop_map() we do a get_paged_gfn() and that reference is retained. In iommuop_unmap() there is another call to get_paged_gfn() but that is there to check that the specified gfn matches the mfn that's looked up in the IOMMU. Only if they match is the original page ref dropped. Paul > -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 8/8] efi: drop original xen.efi code and build mechanism
>>> On 11.07.18 at 13:57, wrote: > On Tue, Jul 10, 2018 at 08:05:56AM -0600, Jan Beulich wrote: >> >>> On 10.07.18 at 13:35, wrote: >> > On Fri, Jul 06, 2018 at 09:16:38AM -0600, Jan Beulich wrote: >> >> >>> On 06.07.18 at 16:46, wrote: >> >> > OK, xen.mb.efi does not need relocs because: >> >> > - we generate PE file from xen-syms file like we do with ELF output; >> >> > so, the code in the PE file is the same like in the ELF file; >> >> > hence, if ELF works why PE should not, >> >> > - all addressing is relative to %rip as it is in ELF file, >> >> >> >> What are the several hundred base relocs in xen.efi doing then? Sure >> >> some of them wouldn't really be needed, but I doubt that's true for >> >> all of them. The first and foremost case of non-RIP-relative addressing >> >> is data with static initializers pointing elsewhere in the image. These >> >> need relocations applied to work. >> >> >> >> Once again - a fundamental criteria is whether your binary can be used >> >> in place of the current xen.efi. I can't convince myself that you've >> >> actually tried that out. At the very least I'd expect the static array in >> >> PrintErrMesg() to present problems here. >> > >> > Ugh... You are right. I forgot about that. Sadly the problem applies to >> > the EFI boot code in the xen.gz too. So, both things have to be fixed. >> > At first sight it seems to me that we can leave relocs in the xen-syms >> > and then attach them to the xen.mb.efi/xen.gz somehow. It would be nice >> > to do that just only for the EFI boot code. Should not we put it in >> > separate section then? Another question is the size of the .reloc section. >> > We do not know it in advance. So, probably we should build the code in >> > two steps as we do now. Or prealloc a static place and fill it later. >> > This way we would have just one phase build. >> >> Any static allocation/reservation scheme is wasteful at first and eventually >> not allocating/reserving enough space. Unless there's a way to reasonably >> well estimate the size ahead of time, I'd be opposed to such a model. As > > I have the same concerns in regards to that. > >> to a separate section - sure, why not? Relocations are in a separate section >> in xen.efi as well. > > I was thinking about separate section for EFI boot code itself, e.g. > .text.efi. > Then probably it will be much easier to identify and use/get relocs needed > only > for that code. How would you constrain which other code can be called from code in this section? While things like memcpy() won't need relocations, there would be no separation between code that can and be called here and code that must not be. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 11/13] memory: add get_paged_gfn() as a wrapper...
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 11 July 2018 12:24
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Julien
> Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ; Wei Liu
> Subject: Re: [PATCH v2 11/13] memory: add get_paged_gfn() as a wrapper...
>
> On 07/07/2018 12:05 PM, Paul Durrant wrote:
> > ...for some uses of get_page_from_gfn().
> >
> > There are many occurences of the following pattern in the code:
> >
> > q = ? P2M_ALLOC : P2M_UNSHARE;
> > page = get_page_from_gfn(d, gfn, , q);
> >
> > if ( p2m_is_paging(p2mt) )
> > {
> > if ( page )
> > put_page(page);
> >
> > p2m_mem_paging_populate(d, gfn);
> > return <-ENOENT or equivalent>;
> > }
> >
> > if ( (q & P2M_UNSHARE) && p2m_is_shared(p2mt) )
> > {
> > if ( page )
> > put_page(page);
> >
> > return <-ENOENT or equivalent>;
> > }
> >
> > if ( !page )
> > return <-EINVAL or equivalent>;
> >
> > if ( !p2m_is_ram(p2mt) ||
> > (! && p2m_is_readonly(p2mt)) )
> > {
> > put_page(page);
> > return <-EINVAL or equivalent>;
> > }
> >
> > There are some small differences between the exact way the occurrences
> are
> > coded but the desired semantic is the same.
> >
> > This patch introduces a new common implementation of this code in
> > get_paged_gfn() and then converts the various open-coded patterns into
> > calls to this new function.
> >
> > Signed-off-by: Paul Durrant
>
> This is a great idea.
>
> It looks like this adds the restriction that the given gfn be ram (e.g.,
> not MMIO) in all cases as well. It looks like that's what's wanted, but
> it would be good to point this out in the commit message (so people can
> verify that this change is warranted).
>
Yes, that's what I meant by 'desired semantic' :-) I'll call out the
restriction more explicitly.
> A few other comments...
>
> > diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> > index c6b99c4116..510f37f100 100644
> > --- a/xen/common/grant_table.c
> > +++ b/xen/common/grant_table.c
> > @@ -375,39 +375,23 @@ static int get_paged_frame(unsigned long gfn,
> mfn_t *mfn,
> > struct page_info **page, bool readonly,
> > struct domain *rd)
> > {
> > -int rc = GNTST_okay;
> > -p2m_type_t p2mt;
> > -
> > -*mfn = INVALID_MFN;
> > -*page = get_page_from_gfn(rd, gfn, ,
> > - readonly ? P2M_ALLOC : P2M_UNSHARE);
> > -if ( !*page )
> > -{
> > -#ifdef P2M_SHARED_TYPES
> > -if ( p2m_is_shared(p2mt) )
> > -return GNTST_eagain;
> > -#endif
> > -#ifdef P2M_PAGES_TYPES
> > -if ( p2m_is_paging(p2mt) )
> > -{
> > -p2m_mem_paging_populate(rd, gfn);
> > -return GNTST_eagain;
> > -}
> > -#endif
> > -return GNTST_bad_page;
> > -}
> > +int rc;
> >
> > -if ( p2m_is_foreign(p2mt) )
> [snip]
> > {
> [snip]
> > -put_page(*page);
> > -*page = NULL;
> > -
>
> Comparing before-and-after, this seems to remove this 'p2m_is_foreign()'
> check. Am I missing something?
>
I may be. I thought p2m_is_ram() ruled out foreign pages (p2m_is_any_ram()
being the way to include foreign maps if required). I'll check.
> > diff --git a/xen/common/memory.c b/xen/common/memory.c
> > index 35da9ca80e..419b76ac38 100644
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -1574,30 +1574,31 @@ void destroy_ring_for_helper(
> > }
> > }
> >
> > -int prepare_ring_for_helper(
> > -struct domain *d, unsigned long gmfn, struct page_info **_page,
> > -void **_va)
> > +int get_paged_gfn(struct domain *d, gfn_t gfn, bool readonly,
> > + p2m_type_t *p2mt_p, struct page_info **page_p)
>
> This wants a comment somewhere describing exactly what the function does
> and what it will return -- probably here above the function definition
> itself would be the best.
>
Ok.
> > {
> > -struct page_info *page;
> > +p2m_query_t q = readonly ? P2M_ALLOC : P2M_UNSHARE;
> > p2m_type_t p2mt;
> > -void *va;
> > +struct page_info *page;
> >
> > -page = get_page_from_gfn(d, gmfn, , P2M_UNSHARE);
> > +page = get_page_from_gfn(d, gfn_x(gfn), , q);
> >
> > #ifdef CONFIG_HAS_MEM_PAGING
> > if ( p2m_is_paging(p2mt) )
> > {
> > if ( page )
> > put_page(page);
> > -p2m_mem_paging_populate(d, gmfn);
> > +
> > +p2m_mem_paging_populate(d, gfn_x(gfn));
> > return -ENOENT;
>
> I realize you're copying the return values of prepare_ring_for_helper(),
> but wouldn't -EAGAIN be more natural here?
>
I may be able to swap for EAGAIN. I agree it seems more appropriate. Hopefully
it won't complicate the callers too much.
Re: [Xen-devel] [PATCH v2 3/8] xen/x86: manually build xen.mb.efi binary
>>> On 11.07.18 at 13:41, wrote: > On Tue, Jul 10, 2018 at 07:54:51AM -0600, Jan Beulich wrote: >> >>> On 10.07.18 at 12:48, wrote: >> > On Fri, Jul 06, 2018 at 09:08:29AM -0600, Jan Beulich wrote: >> >> >>> On 06.07.18 at 16:02, wrote: >> >> > On Thu, Jul 05, 2018 at 02:18:03AM -0600, Jan Beulich wrote: >> >> >> >>> On 04.07.18 at 18:35, wrote: >> >> >> > On Wed, Jul 04, 2018 at 09:27:43AM -0600, Jan Beulich wrote: >> >> >> >> >>> On 04.07.18 at 16:01, wrote: >> >> >> >> > On Mon, Jun 25, 2018 at 09:36:07AM -0600, Jan Beulich wrote: >> >> >> >> >> >>> On 19.06.18 at 16:35, wrote: >> >> >> >> >> > @@ -582,6 +587,12 @@ static void __init >> >> >> >> >> > efi_arch_memory_setup(void) >> >> >> >> >> > if ( !efi_enabled(EFI_LOADER) ) >> >> >> >> >> > return; >> >> >> >> >> > >> >> >> >> >> > +if ( efi_enabled(EFI_MB_LOADER) ) >> >> >> >> >> > +for ( pte = __page_tables_start; pte < >> >> >> >> >> > __page_tables_end; >> >> >> >> >> > + pte += ( pte != (intpte_t *)l2_identmap ) ? 1 : >> >> >> >> >> > 4 * L2_PAGETABLE_ENTRIES ) >> >> >> >> >> >> >> >> >> >> Please avoid explicit casts - _get_intpte(l2_identmap[0]) or >> >> >> >> >> something along those lines ought to work here. Same for >> >> >> >> >> 4 * L2_PAGETABLE_ENTRIES - you mean ARRAY_SIZE() there. >> >> >> >> > >> >> >> >> > OK. >> >> >> >> > >> >> >> >> >> Also this whole code block needs a comment, to explain what it >> >> >> >> >> does and also why l2_identmap needs skipping. >> >> >> >> >> >> >> >> >> >> Furthermore - isn't this off by one, and you process >> >> >> >> >> l2_identmap[0] >> >> >> >> >> this way, skipping the rest _plus_ the first following entry? I >> >> >> >> >> think >> >> >> >> > >> >> >> >> > The code mimics similar code in head.S. >> >> >> >> >> >> >> >> I can't see a similar off-by-1 in head.S. >> >> >> > >> >> >> > 662 /* >> >> >> > 663 * Update frame addresses in page tables excluding >> >> >> > l2_identmap >> >> >> > 664 * without its first entry which points to l1_identmap. >> >> >> > 665 */ >> >> >> > 666 mov >> >> >> > $((__page_tables_end-__page_tables_start)/8),%ecx >> >> >> > 667 mov $(((l2_identmap-__page_tables_start)/8)+1),%edx >> >> >> > 668 1: cmp >> >> >> > $((l2_identmap+l2_identmap_sizeof-__page_tables_start)/8),%ecx >> >> >> > 669 cmove %edx,%ecx >> >> >> > 670 testl >> >> >> > $_PAGE_PRESENT,sym_fs(__page_tables_start)-8(,%ecx,8) >> >> >> > 671 jz 2f >> >> >> > 672 add %esi,sym_fs(__page_tables_start)-8(,%ecx,8) >> >> >> > 673 2: loop1b >> >> >> >> >> >> Well - this is the code in question, but you fail to point out where >> >> >> the off-by-1 is. >> >> > >> >> > Line 667, 668 and 669. >> >> >> >> I don't think so, no. Note the -8 in lines 670 and 672. >> > >> > However, you are missing +1 in line 667. >> >> I don't think I am: The first entry of l2_identmap actually needs >> processing afaics (and as the comment says), as that's the only one >> with non-absolute contents. IOW - part of my original comment was >> wrong, but the other half (you skipping one entry) still seems >> applicable, as does the part concerning the missing comment. > > It seems correct to me. l2_identmap[0] gets updated and then > we move to l3_bootmap[0]. Am I missing something? Hmm, yes, I think you're right. But the way you've coded it it's less obvious than in the assembly variant, and typically it should be the other way around. I'd really like you to make this a closer match. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 09/13] vtd: add lookup_page method to iommu_ops
> -Original Message-
> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
> George Dunlap
> Sent: 11 July 2018 11:52
> To: Paul Durrant
> Cc: xen-devel ; Kevin Tian
> ; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v2 09/13] vtd: add lookup_page method to
> iommu_ops
>
> On Sat, Jul 7, 2018 at 12:05 PM, Paul Durrant
> wrote:
> > This patch adds a new method to the VT-d IOMMU implementation to find
> the
> > MFN currently mapped by the specified BFN along with a wrapper function
> in
> > generic IOMMU code to call the implementation if it exists.
> >
> > This functionality will be used by a subsequent patch.
> >
> > Signed-off-by: Paul Durrant
> > ---
> > Cc: Kevin Tian
> > Cc: Jan Beulich
> >
> > v2:
> > - Addressed some comments from Jan.
> > ---
> > xen/drivers/passthrough/iommu.c | 11 ++
> > xen/drivers/passthrough/vtd/iommu.c | 40
> +
> > xen/drivers/passthrough/vtd/iommu.h | 1 +
> > xen/include/xen/iommu.h | 4
> > 4 files changed, 56 insertions(+)
> >
> > diff --git a/xen/drivers/passthrough/iommu.c
> b/xen/drivers/passthrough/iommu.c
> > index 3fbd3ebaf6..f25aa3f1d6 100644
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -306,6 +306,17 @@ int iommu_unmap_page(struct domain *d, bfn_t
> bfn)
> > return rc;
> > }
> >
> > +int iommu_lookup_page(struct domain *d, bfn_t bfn, mfn_t *mfn,
> > + unsigned int *flags)
> > +{
> > +const struct domain_iommu *hd = dom_iommu(d);
> > +
> > +if ( !iommu_enabled || !hd->platform_ops )
> > +return -EOPNOTSUPP;
> > +
> > +return hd->platform_ops->lookup_page(d, bfn, mfn, flags);
> > +}
> > +
> > static void iommu_free_pagetables(unsigned long unused)
> > {
> > do {
> > diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> > index 7cd3813b9f..438bef670d 100644
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -1831,6 +1831,45 @@ static int __must_check
> intel_iommu_unmap_page(struct domain *d,
> > return dma_pte_clear_one(d, bfn_to_baddr(bfn));
> > }
> >
> > +static int intel_iommu_lookup_page(struct domain *d, bfn_t bfn, mfn_t
> *mfn,
> > + unsigned int *flags)
> > +{
> > +struct domain_iommu *hd = dom_iommu(d);
> > +struct dma_pte *page = NULL, *pte = NULL, val;
> > +u64 pg_maddr;
> > +
> > +spin_lock(>arch.mapping_lock);
> > +
> > +pg_maddr = addr_to_dma_page_maddr(d, bfn_to_baddr(bfn), 0);
> > +if ( pg_maddr == 0 )
> > +{
> > +spin_unlock(>arch.mapping_lock);
> > +return -ENOMEM;
> > +}
> > +
> > +page = map_vtd_domain_page(pg_maddr);
> > +pte = page + (bfn_x(bfn) & LEVEL_MASK);
> > +val = *pte;
> > +if ( !dma_pte_present(val) )
> > +{
> > +unmap_vtd_domain_page(page);
> > +spin_unlock(>arch.mapping_lock);
> > +return -ENOMEM;
>
> Should this be -EEXIST? Or maybe return MFN_INVALID?
>
Do you mean ENOENT? EEXIST implies it exists but it shouldn't, right?
> Also, could you do the unmap / unlock first and then do the check,
> rather than duplicating things?
>
Sure.
> > +}
> > +
> > +unmap_vtd_domain_page(page);
> > +spin_unlock(>arch.mapping_lock);
> > +
> > +*mfn = maddr_to_mfn(dma_pte_addr(val));
> > +*flags = 0;
> > +if ( dma_pte_prot(val) & DMA_PTE_READ )
> > +*flags |= IOMMUF_readable;
> > +if ( dma_pte_prot(val) & DMA_PTE_WRITE )
> > +*flags |= IOMMUF_writable;
>
> This is a bit strange, since all dma_pte_prot() does is return val &
> DMA_PTE_READ|DMA_PTE_WRITE. Would it make sense to implement
> dma_pte_read() / dma_pte_write() instead (like dma_pte_present())?
>
Yes, I can do that.
> Everything else looks good to me.
>
Thanks,
Paul
> -George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/8] x86/shim: fully ignore "nosmp" and "maxcpus="
On 11/07/18 13:11, Jan Beulich wrote: > In the shim case, the number of CPUs should be solely controlled by the > guest configuration file. Make sure the command line options are fully > (and not just partially) ignored. > > Signed-off-by: Jan Beulich Ideally with "This option is ignored in **pv-shim** mode" added to the docs in the relevant places, Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 08/13] x86: add iommu_op to query reserved ranges
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 11 July 2018 11:34
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org) ; Wei Liu
>
> Subject: Re: [PATCH v2 08/13] x86: add iommu_op to query reserved ranges
>
> On 07/07/2018 12:05 PM, Paul Durrant wrote:
> > @@ -35,17 +93,33 @@ static void iommu_op(xen_iommu_op_t *op)
> >
> > int do_one_iommu_op(xen_iommu_op_buf_t *buf)
> > {
> > -xen_iommu_op_t op;
> > +xen_iommu_op_t op = {};
> > +size_t offset;
> > +static const size_t op_size[] = {
> > +[XEN_IOMMUOP_query_reserved] = sizeof(struct
> xen_iommu_op_query_reserved),
> > +};
> > +
> > +offset = offsetof(struct xen_iommu_op, u);
> >
> > -if ( buf->size < sizeof(op) )
> > +if ( buf->size < offset )
> > return -EFAULT;
> >
> > -if ( copy_from_guest((void *), buf->h, sizeof(op)) )
> > +if ( copy_from_guest((void *), buf->h, offset) )
> > return -EFAULT;
> >
> > if ( op.pad )
> > return -EINVAL;
> >
> > +if ( op.op >= ARRAY_SIZE(op_size) )
> > +return -EOPNOTSUPP;
> > +
> > +if ( buf->size < offset + op_size[op.op] )
> > +return -EFAULT;
> > +
> > +if ( copy_from_guest_offset((void *), buf->h, offset,
> > +op_size[op.op]) )
> > +return -EFAULT;
>
> This looks like part of a potential SP1 gadget, so this needs to use
> array_index_nospec().
>
Ok. There is similar code in dm ops too so I'll have a look while I'm at it.
Paul
> -George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 8/8] cpumask: tidy {,z}alloc_cpumask_var()
On 11/07/18 13:12, Jan Beulich wrote: > Drop unnecessary casts and use bool in favor of bool_t. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 8/8] cpumask: tidy {,z}alloc_cpumask_var()
Drop unnecessary casts and use bool in favor of bool_t.
Signed-off-by: Jan Beulich
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -345,9 +345,9 @@ static inline int cpulist_scnprintf(char
typedef cpumask_t *cpumask_var_t;
-static inline bool_t alloc_cpumask_var(cpumask_var_t *mask)
+static inline bool alloc_cpumask_var(cpumask_var_t *mask)
{
- *(void **)mask = _xmalloc(nr_cpumask_bits / 8, sizeof(long));
+ *mask = _xmalloc(nr_cpumask_bits / 8, sizeof(long));
return *mask != NULL;
}
@@ -358,9 +358,9 @@ static inline bool cond_alloc_cpumask_va
return *mask != NULL;
}
-static inline bool_t zalloc_cpumask_var(cpumask_var_t *mask)
+static inline bool zalloc_cpumask_var(cpumask_var_t *mask)
{
- *(void **)mask = _xzalloc(nr_cpumask_bits / 8, sizeof(long));
+ *mask = _xzalloc(nr_cpumask_bits / 8, sizeof(long));
return *mask != NULL;
}
@@ -385,16 +385,16 @@ static inline void clear_cpumask_var(cpu
#else
typedef cpumask_t cpumask_var_t[1];
-static inline bool_t alloc_cpumask_var(cpumask_var_t *mask)
+static inline bool alloc_cpumask_var(cpumask_var_t *mask)
{
- return 1;
+ return true;
}
#define cond_alloc_cpumask_var alloc_cpumask_var
-static inline bool_t zalloc_cpumask_var(cpumask_var_t *mask)
+static inline bool zalloc_cpumask_var(cpumask_var_t *mask)
{
cpumask_clear(*mask);
- return 1;
+ return true;
}
#define cond_zalloc_cpumask_var zalloc_cpumask_var
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 6/8] x86: (command line option to) avoid use of secondary hyper-threads
Shared resources (L1 cache and TLB in particular) present a risk of
information leak via side channels. Don't use hyperthreads in such
cases, but allow independent control of their use at the same time.
Signed-off-by: Jan Beulich
---
An option to avoid the up/down cycle would be to avoid clearing the
sibling (and then perhaps also core) map of parked CPUs, allowing to
bail early from cpu_up_helper().
TBD: How to prevent the CPU from transiently becoming available for
scheduling when being onlined at runtime?
TBD: For now the patch assumes all HT-enabled CPUs are affected by side
channel attacks through shared resources. There are claims that AMD
ones aren't, but it hasn't really become clear to me why that would
be, as I don't see the fully associative L1 TLBs to be sufficient
reason for there to not be other possible avenues (L2 TLB, caches).
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1040,6 +1040,13 @@ identical to the boot CPU will be parked
### hpetbroadcast (x86)
> `= `
+### ht (x86)
+> `= `
+
+Default: `false`
+
+Control bring up of multiple hyper-threads per CPU core.
+
### hvm\_debug (x86)
> `= `
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -62,6 +62,9 @@ boolean_param("nosmp", opt_nosmp);
static unsigned int __initdata max_cpus;
integer_param("maxcpus", max_cpus);
+int8_t __read_mostly opt_ht = -1;
+boolean_param("ht", opt_ht);
+
/* opt_invpcid: If false, don't use INVPCID instruction even if available. */
static bool __initdata opt_invpcid = true;
boolean_param("invpcid", opt_invpcid);
@@ -1633,7 +1636,10 @@ void __init noreturn __start_xen(unsigne
int ret = cpu_up(i);
if ( ret != 0 )
printk("Failed to bring up CPU %u (error %d)\n", i, ret);
-else if ( num_online_cpus() > max_cpus )
+else if ( num_online_cpus() > max_cpus ||
+ (!opt_ht &&
+ cpu_data[i].compute_unit_id == INVALID_CUID &&
+ cpumask_weight(per_cpu(cpu_sibling_mask, i)) > 1) )
{
ret = cpu_down(i);
if ( !ret )
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -126,6 +127,9 @@ static int __init parse_spec_ctrl(const
opt_eager_fpu = 0;
+if ( opt_ht < 0 )
+opt_ht = 1;
+
disable_common:
opt_rsb_pv = false;
opt_rsb_hvm = false;
@@ -627,6 +631,9 @@ void __init init_speculation_mitigations
if ( default_xen_spec_ctrl )
setup_force_cpu_cap(X86_FEATURE_SC_MSR_IDLE);
+if ( opt_ht < 0 )
+opt_ht = 0;
+
xpti_init_default(false);
if ( opt_xpti == 0 )
setup_force_cpu_cap(X86_FEATURE_NO_XPTI);
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -48,14 +49,27 @@ static void l3_cache_get(void *arg)
long cpu_up_helper(void *data)
{
-int cpu = (unsigned long)data;
+unsigned int cpu = (unsigned long)data;
int ret = cpu_up(cpu);
+
if ( ret == -EBUSY )
{
/* On EBUSY, flush RCU work and have one more go. */
rcu_barrier();
ret = cpu_up(cpu);
}
+
+if ( !ret && !opt_ht &&
+ cpu_data[cpu].compute_unit_id == INVALID_CUID &&
+ cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) > 1 )
+{
+ret = cpu_down_helper(data);
+if ( ret )
+printk("Could not re-offline CPU%u (%d)\n", cpu, ret);
+else
+ret = -EPERM;
+}
+
return ret;
}
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -59,6 +59,8 @@ extern uint8_t kbd_shift_flags;
extern unsigned long highmem_start;
#endif
+extern int8_t opt_ht;
+
#ifdef CONFIG_SHADOW_PAGING
extern bool opt_dom0_shadow;
#else
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5/8] x86: bring up all CPUs even if not all are supposed to be used
Reportedly Intel CPUs which can't broadcast #MC to all targeted
cores/threads because some have CR4.MCE clear will shut down. Therefore
we want to keep CR4.MCE enabled when offlining a CPU, and we need to
bring up all CPUs in order to be able to set CR4.MCE in the first place.
The use of clear_in_cr4() in cpu_mcheck_disable() was ill advised
anyway, and to avoid future similar mistakes I'm removing clear_in_cr4()
altogether right here.
Signed-off-by: Jan Beulich
---
Instead of fully bringing up CPUs and then calling cpu_down(), another
option would be to suppress/cancel full bringup in smp_callin().
---
Note: The parked CPUs can be brought online (i.e. the meaning of
"maxcpus=" isn't as strict anymore as it was before), but won't
immediately be used for scheduling pre-existing Dom0 CPUs. That's
because dom0_setup_vcpu() artifically restricts the affinity. For
DomU-s whose affinity was not artifically restricted, no such
limitation exists, albeit the shown "soft" affinity appears to
suffer a similar issue. As that's not a goal of this patch, I've
put the issues on the side for now, perhaps for someone else to
take care of.
Note: On one of my test systems the parked CPUs get _PSD data reported
by Dom0 that is different from the non-parked ones (coord_type is
0xFC instead of 0xFE). Giving Dom0 enough vCPU-s eliminates this
problem, so there is apparently something amiss in the processor
driver. I've tried to figure out what, but I couldn't, despite the
AML suggesting that this might be some _OSC invocation (but if it
is, I can't find it - acpi_run_osc() clearly does not anywhere get
invoked in a per-CPU fashion).
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -13,6 +13,7 @@
#include /* for XEN_INVALID_{SOCKET,CORE}_ID */
#include "cpu.h"
+#include "mcheck/x86_mca.h"
bool_t opt_arat = 1;
boolean_param("arat", opt_arat);
@@ -343,6 +344,9 @@ static void __init early_cpu_detect(void
hap_paddr_bits = PADDR_BITS;
}
+ if (c->x86_vendor != X86_VENDOR_AMD)
+ park_offline_cpus = opt_mce;
+
initialize_cpu_data(0);
}
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -636,8 +636,6 @@ static void clear_cmci(void)
static void cpu_mcheck_disable(void)
{
-clear_in_cr4(X86_CR4_MCE);
-
if ( cmci_support && opt_mce )
clear_cmci();
}
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -68,18 +68,26 @@ physid_mask_t phys_cpu_present_map;
void __init set_nr_cpu_ids(unsigned int max_cpus)
{
+ unsigned int tot_cpus = num_processors + disabled_cpus;
+
if (!max_cpus)
- max_cpus = num_processors + disabled_cpus;
+ max_cpus = tot_cpus;
if (max_cpus > NR_CPUS)
max_cpus = NR_CPUS;
else if (!max_cpus)
max_cpus = 1;
printk(XENLOG_INFO "SMP: Allowing %u CPUs (%d hotplug CPUs)\n",
max_cpus, max_t(int, max_cpus - num_processors, 0));
- nr_cpu_ids = max_cpus;
+
+ if (!park_offline_cpus)
+ tot_cpus = max_cpus;
+ nr_cpu_ids = min(tot_cpus, NR_CPUS + 0u);
+ if (park_offline_cpus && nr_cpu_ids < num_processors)
+ printk(XENLOG_WARNING "SMP: Cannot bring up %u further CPUs\n",
+ num_processors - nr_cpu_ids);
#ifndef nr_cpumask_bits
- nr_cpumask_bits = (max_cpus + (BITS_PER_LONG - 1)) &
+ nr_cpumask_bits = (nr_cpu_ids + (BITS_PER_LONG - 1)) &
~(BITS_PER_LONG - 1);
printk(XENLOG_DEBUG "NR_CPUS:%u nr_cpumask_bits:%u\n",
NR_CPUS, nr_cpumask_bits);
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -665,7 +665,7 @@ void __init noreturn __start_xen(unsigne
{
char *memmap_type = NULL;
char *cmdline, *kextra, *loader;
-unsigned int initrdidx;
+unsigned int initrdidx, num_parked = 0;
multiboot_info_t *mbi;
module_t *mod;
unsigned long nr_pages, raw_max_page, modules_headroom, *module_map;
@@ -1503,7 +1503,8 @@ void __init noreturn __start_xen(unsigne
else
{
set_nr_cpu_ids(max_cpus);
-max_cpus = nr_cpu_ids;
+if ( !max_cpus )
+max_cpus = nr_cpu_ids;
}
if ( xen_guest )
@@ -1626,16 +1627,27 @@ void __init noreturn __start_xen(unsigne
/* Set up node_to_cpumask based on cpu_to_node[]. */
numa_add_cpu(i);
-if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
+if ( (park_offline_cpus || num_online_cpus() < max_cpus) &&
+ !cpu_online(i) )
{
int ret = cpu_up(i);
if ( ret != 0 )
printk("Failed to bring up CPU %u (error %d)\n", i, ret);
+else if ( num_online_cpus() > max_cpus )
+{
+
Re: [Xen-devel] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Wed, Jul 11, 2018 at 01:13:18PM +0200, Michal Hocko wrote: > On Wed 11-07-18 13:14:47, Leon Romanovsky wrote: > > On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote: > > > On Tue 10-07-18 19:20:20, Leon Romanovsky wrote: > > > > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote: > > > > > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote: > > > > > > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote: > > > > > > > On Wed 27-06-18 09:44:21, Michal Hocko wrote: > > > > > > > > This is the v2 of RFC based on the feedback I've received so > > > > > > > > far. The > > > > > > > > code even compiles as a bonus ;) I haven't runtime tested it > > > > > > > > yet, mostly > > > > > > > > because I have no idea how. > > > > > > > > > > > > > > > > Any further feedback is highly appreciated of course. > > > > > > > > > > > > > > Any other feedback before I post this as non-RFC? > > > > > > > > > > > > From mlx5 perspective, who is primary user of umem_odp.c your > > > > > > change looks ok. > > > > > > > > > > Can I assume your Acked-by? > > > > > > > > I didn't have a chance to test it because it applies on our rdma-next, > > > > but > > > > fails to compile. > > > > > > What is the compilation problem? Is it caused by the patch or some other > > > unrelated changed? > > > > Thanks for pushing me to take a look on it. > > Your patch needs the following hunk to properly compile at least on my > > system. > > I suspect you were trying the original version. I've posted an updated > patch here http://lkml.kernel.org/r/20180627074421.gf32...@dhcp22.suse.cz > and all these issues should be fixed there. Including many other fixes. > Ohh, you used --reply-to, IMHO it is best way to make sure that the patch will be lost :) > Could you have a look at that one please? I grabbed it, the results will be overnight only. Thanks > -- > Michal Hocko > SUSE Labs signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/8] x86/AMD: distinguish compute units from hyper-threads
Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
the difference is not very big. The most relevant change (requiring some
code restructuring) is that the topoext feature no longer means there is
a valid CU ID.
Take the opportunity and convert wrongly plain int variables in
set_cpu_sibling_map() to unsigned int.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -504,17 +504,23 @@ static void amd_get_topology(struct cpui
u32 eax, ebx, ecx, edx;
cpuid(0x801e, , , , );
-c->compute_unit_id = ebx & 0xFF;
c->x86_num_siblings = ((ebx >> 8) & 0x3) + 1;
+
+ if (c->x86 < 0x17)
+ c->compute_unit_id = ebx & 0xFF;
+ else {
+ c->cpu_core_id = ebx & 0xFF;
+ c->x86_max_cores /= c->x86_num_siblings;
+ }
}
if (opt_cpu_info)
printk("CPU %d(%d) -> Processor %d, %s %d\n",
cpu, c->x86_max_cores, c->phys_proc_id,
- cpu_has(c, X86_FEATURE_TOPOEXT) ? "Compute Unit" :
- "Core",
- cpu_has(c, X86_FEATURE_TOPOEXT) ? c->compute_unit_id :
- c->cpu_core_id);
+ c->compute_unit_id != INVALID_CUID ? "Compute Unit"
+ : "Core",
+ c->compute_unit_id != INVALID_CUID ? c->compute_unit_id
+ : c->cpu_core_id);
}
static void early_init_amd(struct cpuinfo_x86 *c)
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -236,33 +236,41 @@ static void link_thread_siblings(int cpu
cpumask_set_cpu(cpu2, per_cpu(cpu_core_mask, cpu1));
}
-static void set_cpu_sibling_map(int cpu)
+static void set_cpu_sibling_map(unsigned int cpu)
{
-int i;
+unsigned int i;
struct cpuinfo_x86 *c = cpu_data;
cpumask_set_cpu(cpu, _sibling_setup_map);
cpumask_set_cpu(cpu, socket_cpumask[cpu_to_socket(cpu)]);
+cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
+cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
if ( c[cpu].x86_num_siblings > 1 )
{
for_each_cpu ( i, _sibling_setup_map )
{
-if ( cpu_has(c, X86_FEATURE_TOPOEXT) ) {
-if ( (c[cpu].phys_proc_id == c[i].phys_proc_id) &&
- (c[cpu].compute_unit_id == c[i].compute_unit_id) )
+if ( cpu == i || c[cpu].phys_proc_id != c[i].phys_proc_id )
+continue;
+if ( c[cpu].compute_unit_id != INVALID_CUID &&
+ c[i].compute_unit_id != INVALID_CUID )
+{
+if ( c[cpu].compute_unit_id == c[i].compute_unit_id )
link_thread_siblings(cpu, i);
-} else if ( (c[cpu].phys_proc_id == c[i].phys_proc_id) &&
-(c[cpu].cpu_core_id == c[i].cpu_core_id) ) {
-link_thread_siblings(cpu, i);
}
+else if ( c[cpu].cpu_core_id != XEN_INVALID_CORE_ID &&
+ c[i].cpu_core_id != XEN_INVALID_CORE_ID )
+{
+if ( c[cpu].cpu_core_id == c[i].cpu_core_id )
+link_thread_siblings(cpu, i);
+}
+else
+printk(XENLOG_WARNING
+ "CPU%u: unclear relationship with CPU%u\n",
+ cpu, i);
}
}
-else
-{
-cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
-}
if ( c[cpu].x86_max_cores == 1 )
{
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/8] allow cpu_down() to be called earlier
The function's use of the stop-machine logic has so far prevented its
use ahead of the processing of the "ordinary" initcalls. Since at this
early time we're in a controlled environment anyway, there's no need for
such a heavy tool. Additionally this ought to have less of a performance
impact especially on large systems, compared to the alternative of
making stop-machine functionality available earlier.
Signed-off-by: Jan Beulich
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -67,12 +67,17 @@ void __init register_cpu_notifier(struct
spin_unlock(_add_remove_lock);
}
-static int take_cpu_down(void *unused)
+static void _take_cpu_down(void *unused)
{
void *hcpu = (void *)(long)smp_processor_id();
int notifier_rc = notifier_call_chain(_chain, CPU_DYING, hcpu, NULL);
BUG_ON(notifier_rc != NOTIFY_DONE);
__cpu_disable();
+}
+
+static int take_cpu_down(void *arg)
+{
+_take_cpu_down(arg);
return 0;
}
@@ -98,7 +103,9 @@ int cpu_down(unsigned int cpu)
goto fail;
}
-if ( (err = stop_machine_run(take_cpu_down, NULL, cpu)) < 0 )
+if ( unlikely(system_state < SYS_STATE_active) )
+on_selected_cpus(cpumask_of(cpu), _take_cpu_down, NULL, true);
+else if ( (err = stop_machine_run(take_cpu_down, NULL, cpu)) < 0 )
goto fail;
__cpu_die(cpu);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/8] x86: distinguish CPU offlining from CPU removal
In order to be able to service #MC on offlined CPUs, GDT, IDT, stack,
and per-CPU data (which includes the TSS) need to be kept allocated.
They should only be freed upon CPU removal (which we currently don't
support, so some code is becoming effectively dead for the moment).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -692,12 +692,15 @@ static void cpu_bank_free(unsigned int c
mcabanks_free(poll);
mcabanks_free(clr);
+
+per_cpu(poll_bankmask, cpu) = NULL;
+per_cpu(mce_clear_banks, cpu) = NULL;
}
static int cpu_bank_alloc(unsigned int cpu)
{
-struct mca_banks *poll = mcabanks_alloc();
-struct mca_banks *clr = mcabanks_alloc();
+struct mca_banks *poll = per_cpu(poll_bankmask, cpu) ?: mcabanks_alloc();
+struct mca_banks *clr = per_cpu(mce_clear_banks, cpu) ?: mcabanks_alloc();
if ( !poll || !clr )
{
@@ -725,7 +728,13 @@ static int cpu_callback(
case CPU_UP_CANCELED:
case CPU_DEAD:
-cpu_bank_free(cpu);
+if ( !park_offline_cpus )
+cpu_bank_free(cpu);
+break;
+
+case CPU_REMOVE:
+if ( park_offline_cpus )
+cpu_bank_free(cpu);
break;
}
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -107,10 +107,11 @@ static void play_dead(void)
local_irq_disable();
/*
- * NOTE: After cpu_exit_clear, per-cpu variables are no longer accessible,
- * as they may be freed at any time. In this case, heap corruption or
- * #PF can occur (when heap debugging is enabled). For example, even
- * printk() can involve tasklet scheduling, which touches per-cpu vars.
+ * NOTE: After cpu_exit_clear, per-cpu variables may no longer accessible,
+ * as they may be freed at any time if offline CPUs don't get parked. In
+ * this case, heap corruption or #PF can occur (when heap debugging is
+ * enabled). For example, even printk() can involve tasklet scheduling,
+ * which touches per-cpu vars.
*
* Consider very carefully when adding code to *dead_idle. Most hypervisor
* subsystems are unsafe to call.
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -201,18 +201,25 @@ static int update_clusterinfo(
if ( !cluster_cpus_spare )
cluster_cpus_spare = xzalloc(cpumask_t);
if ( !cluster_cpus_spare ||
- !alloc_cpumask_var(_cpu(scratch_mask, cpu)) )
+ !cond_alloc_cpumask_var(_cpu(scratch_mask, cpu)) )
err = -ENOMEM;
break;
case CPU_UP_CANCELED:
case CPU_DEAD:
+case CPU_REMOVE:
+if ( park_offline_cpus == (action != CPU_REMOVE) )
+break;
if ( per_cpu(cluster_cpus, cpu) )
{
cpumask_clear_cpu(cpu, per_cpu(cluster_cpus, cpu));
if ( cpumask_empty(per_cpu(cluster_cpus, cpu)) )
+{
xfree(per_cpu(cluster_cpus, cpu));
+per_cpu(cluster_cpus, cpu) = NULL;
+}
}
free_cpumask_var(per_cpu(scratch_mask, cpu));
+clear_cpumask_var(_cpu(scratch_mask, cpu));
break;
}
--- a/xen/arch/x86/percpu.c
+++ b/xen/arch/x86/percpu.c
@@ -28,7 +28,7 @@ static int init_percpu_area(unsigned int
char *p;
if ( __per_cpu_offset[cpu] != INVALID_PERCPU_AREA )
-return -EBUSY;
+return 0;
if ( (p = alloc_xenheap_pages(PERCPU_ORDER, 0)) == NULL )
return -ENOMEM;
@@ -76,9 +76,12 @@ static int cpu_percpu_callback(
break;
case CPU_UP_CANCELED:
case CPU_DEAD:
-free_percpu_area(cpu);
+if ( !park_offline_cpus )
+free_percpu_area(cpu);
break;
-default:
+case CPU_REMOVE:
+if ( park_offline_cpus )
+free_percpu_area(cpu);
break;
}
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -63,6 +63,8 @@ static cpumask_t scratch_cpu0mask;
cpumask_t cpu_online_map __read_mostly;
EXPORT_SYMBOL(cpu_online_map);
+bool __read_mostly park_offline_cpus;
+
unsigned int __read_mostly nr_sockets;
cpumask_t **__read_mostly socket_cpumask;
static cpumask_t *secondary_socket_cpumask;
@@ -887,7 +889,7 @@ static void cleanup_cpu_root_pgt(unsigne
}
}
-static void cpu_smpboot_free(unsigned int cpu)
+static void cpu_smpboot_free(unsigned int cpu, bool all)
{
unsigned int order, socket = cpu_to_socket(cpu);
struct cpuinfo_x86 *c = cpu_data;
@@ -898,15 +900,24 @@ static void cpu_smpboot_free(unsigned in
socket_cpumask[socket] = NULL;
}
-c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
-c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
-c[cpu].compute_unit_id = INVALID_CUID;
cpumask_clear_cpu(cpu, _sibling_setup_map);
-free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
-free_cpumask_var(per_cpu(cpu_core_mask, cpu));
-if ( per_cpu(scratch_cpumask, cpu) != _cpu0mask )
-
[Xen-devel] [PATCH 1/8] cpupools: fix state when downing a CPU failed
While I've run into the issue with further patches in place which no
longer guarantee the per-CPU area to start out as all zeros, the
CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
the per-CPU cpupool pointer, cpupool_cpu_add()'s (indirect) invocation
of schedule_cpu_switch() will trigger the "c != old_pool" assertion
there.
Clearing the field during CPU_DOWN_PREPARE is too early (afaict this
should not happen before cpu_disable_scheduler()). Clearing it in
CPU_DEAD and CPU_DOWN_FAILED would be an option, but would take the same
piece of code twice. Since the field's value shouldn't matter while the
CPU is offline, simply clear it in CPU_ONLINE and CPU_DOWN_FAILED, but
only for other than the suspend/resume case (which gets specially
handled in cpupool_cpu_remove()).
Signed-off-by: Jan Beulich
---
TBD: I think this would better call schedule_cpu_switch(cpu, NULL) from
cpupool_cpu_remove(), but besides that - as per above - likely
being too early, that function has further prereqs to be met. It
also doesn't look as if cpupool_unassign_cpu_helper() could be used
there.
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -778,6 +778,8 @@ static int cpu_callback(
{
case CPU_DOWN_FAILED:
case CPU_ONLINE:
+if ( system_state <= SYS_STATE_active )
+per_cpu(cpupool, cpu) = NULL;
rc = cpupool_cpu_add(cpu);
break;
case CPU_DOWN_PREPARE:
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/x86: fix linker script to work with lld
On Wed, Jul 11, 2018 at 01:46:56PM +0200, Roger Pau Monné wrote: > On Wed, Jul 11, 2018 at 12:42:48PM +0200, Daniel Kiper wrote: > > On Wed, Jul 11, 2018 at 12:25:21PM +0200, Roger Pau Monne wrote: > > > lld (the llvm linker) has some issues with Xen linker script. It > > > doesn't understand '||' in assert expressions: > > > > > > ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \ > > > /root/src/xen/xen/common/symbols-dummy.o -o > > > /root/src/xen/xen/.xen-syms.0 > > > ld: error: xen.lds:260: malformed number: | > > > >>> ASSERT(__image_base__ > (261 >> 8) * 0x) | > > > >>> (261 << 39))) + ((1 << 39) / 2)) + (64 << 30)) + (1 << 30)) + (1 << > > > >>> 30))) || > > > >>> > > > >>> > > > >>> ^ > > > > > > And doesn't work properly with the 'DEFINED(foo) ? foo : ...' > > > expression: > > > > > > ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \ > > > /root/src/xen/xen/common/symbols-dummy.o -o > > > /root/src/xen/xen/.xen-syms.0 > > > ld: error: xen.lds:233: symbol not found: efi > > > > > > Fix the first issue by using '|' instead of '||', and the second one > > > by declaring the efi symbol as a weak symbol. > > > > > > Signed-off-by: Roger Pau Monné > > > --- > > > Cc: Jan Beulich > > > Cc: Andrew Cooper > > > Cc: Daniel Kiper > > > --- > > > Changes since v1: > > > - Export efi as a weak symbol in order to remove the DEFINED > > >conditional in the linker script. > > > - Add a define for setting the weak attribute and replace existing > > >users. > > > > May I ask you to split this patch into two separate patches? > > One for __weak change and one for DEFINED() drop please. > > So to introduce and use __weak also for the efi variable and then drop > the DEFINED in a following patch? > > Or switch efi to use __weak in the same patch where DEFINED is > dropped? The latter please. Daniel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 8/8] efi: drop original xen.efi code and build mechanism
On Tue, Jul 10, 2018 at 08:05:56AM -0600, Jan Beulich wrote: > >>> On 10.07.18 at 13:35, wrote: > > On Fri, Jul 06, 2018 at 09:16:38AM -0600, Jan Beulich wrote: > >> >>> On 06.07.18 at 16:46, wrote: > >> > OK, xen.mb.efi does not need relocs because: > >> > - we generate PE file from xen-syms file like we do with ELF output; > >> > so, the code in the PE file is the same like in the ELF file; > >> > hence, if ELF works why PE should not, > >> > - all addressing is relative to %rip as it is in ELF file, > >> > >> What are the several hundred base relocs in xen.efi doing then? Sure > >> some of them wouldn't really be needed, but I doubt that's true for > >> all of them. The first and foremost case of non-RIP-relative addressing > >> is data with static initializers pointing elsewhere in the image. These > >> need relocations applied to work. > >> > >> Once again - a fundamental criteria is whether your binary can be used > >> in place of the current xen.efi. I can't convince myself that you've > >> actually tried that out. At the very least I'd expect the static array in > >> PrintErrMesg() to present problems here. > > > > Ugh... You are right. I forgot about that. Sadly the problem applies to > > the EFI boot code in the xen.gz too. So, both things have to be fixed. > > At first sight it seems to me that we can leave relocs in the xen-syms > > and then attach them to the xen.mb.efi/xen.gz somehow. It would be nice > > to do that just only for the EFI boot code. Should not we put it in > > separate section then? Another question is the size of the .reloc section. > > We do not know it in advance. So, probably we should build the code in > > two steps as we do now. Or prealloc a static place and fill it later. > > This way we would have just one phase build. > > Any static allocation/reservation scheme is wasteful at first and eventually > not allocating/reserving enough space. Unless there's a way to reasonably > well estimate the size ahead of time, I'd be opposed to such a model. As I have the same concerns in regards to that. > to a separate section - sure, why not? Relocations are in a separate section > in xen.efi as well. I was thinking about separate section for EFI boot code itself, e.g. .text.efi. Then probably it will be much easier to identify and use/get relocs needed only for that code. > > Or another option. Add Xen mappings in the early EFI boot code. However, > > it seems crazy and may not work on all EFI implementations. Hmmm... > > Have to check the UEFI spec... > > I'm afraid I don't understand anyway what you think of here. All non-rip-relative addresses are in Xen address space. So, I was thinking about adding required mappings to avoid .reloc section requirement. Though UEFI spec may not allow such play with page tables before ExitBootServices() call. > > By the way, I am not sure why mkreloc is executed twice. Could you > > explain that? > > Its needed as many times as we link a binary, minus the very first time, > where stub (dummy) objects are used. I don't see how you think we > could get away with just one invocation. Are you thinking we could get > away with fewer linking steps? That would be nice. At least I will try... > - Link step 0 produces a binary without kallsyms table, but with all > symbols. Hence a symbol table generated from it will have the correct > number of entries and hence the correct size. > - Link step 1 produces a binary with kallsyms table taken from the > step 0 binary. This results in all addresses in the resulting binary now > being correct (no more code/data is going to be added), but the > symbol table itself is wrong (as coming from step 0). > - Link step 2 produces a binary with a _correct_ kallsyms table. > If we omitted relocations from step 1, we'd risk other addresses > changing in step 2 (maybe this is just a theoretical risk, but anyway). OK, thanks for explanation. Daniel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/8] x86: (allow to) suppress use of hyper-threading
I've been considering to add a respective command line option for
quite a long time, but never got around to. Now that the TLBleed
information is public[1], we're at point where we not only want,
but need this, and where perhaps it needs to be the default on
affected systems. The first 5 patches are all prerequisites to the
6th one; the final two are simply addressing things I had noticed
while putting together the rest.
1: cpupools: fix state when downing a CPU failed
2: x86: distinguish CPU offlining from CPU removal
3: allow cpu_down() to be called earlier
4: x86/AMD: distinguish compute units from hyper-threads
5: x86: bring up all CPUs even if not all are supposed to be used
6: x86: command line option to avoid use of secondary hyper-threads
7: x86/shim: fully ignore "nosmp" and "maxcpus="
8: cpumask: tidy {,z}alloc_cpumask_var()
Jan
[1] https://www.vusec.net/projects/tlbleed/
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 125105: all pass - PUSHED
flight 125105 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/125105/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c6a14de3ef30291918f3b15436cf6a75db413eea baseline version: ovmf 99fd30431d565412707f7a1e1a23461d10d07e85 Last test of basis 125100 2018-07-11 07:40:38 Z0 days Testing same since 125105 2018-07-11 09:40:42 Z0 days1 attempts People who touched revisions under test: Zenith432 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 99fd30431d..c6a14de3ef c6a14de3ef30291918f3b15436cf6a75db413eea -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 74954: regressions - FAIL
This run is configured for baseline tests only. flight 74954 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74954/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-build fail REGR. vs. 74952 version targeted for testing: ovmf 99fd30431d565412707f7a1e1a23461d10d07e85 baseline version: ovmf e4e314b1b6b74c46da3c0493e7a807df28cb9aed Last test of basis74952 2018-07-11 05:19:50 Z0 days Testing same since74954 2018-07-11 09:49:41 Z0 days1 attempts People who touched revisions under test: Star Zeng jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt fail 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 99fd30431d565412707f7a1e1a23461d10d07e85 Author: Star Zeng Date: Tue Jul 10 18:12:56 2018 +0800 MdeModulePkg CapsuleApp: Fix NestedCapsuleHeader->Flags assigned wrong (FwType == ESRT_FW_TYPE_DEVICEFIRMWARE) ? system : device should be (FwType == ESRT_FW_TYPE_SYSTEMFIRMWARE) ? system : device Cc: Michael D Kinney Cc: Jiewen Yao Cc: Ming Shao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng Reviewed-by: Jiewen Yao commit 70bd2a85e944c3654e67e039ed58e35a8565fc13 Author: Star Zeng Date: Tue Jul 10 17:19:15 2018 +0800 SignedCapsulePkg RecoveryModuleLoadPei: Fix typo 'Press' to 'Process' Cc: Michael D Kinney Cc: Jiewen Yao Cc: Ming Shao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng Reviewed-by: Jiewen Yao commit a891bd733781f5430abe0a670e1bbe79e16baa28 Author: Star Zeng Date: Tue Jul 10 17:18:27 2018 +0800 MdeModulePkg DxeCapsuleLibFmp: Fix typo 'Press' to 'Process' Cc: Michael D Kinney Cc: Jiewen Yao Cc: Ming Shao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng Reviewed-by: Jiewen Yao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/13] x86: add iommu_ops to modify and flush IOMMU mappings
On 07/07/2018 12:05 PM, Paul Durrant wrote: > This patch adds iommu_ops to add (map) or remove (unmap) frames in the > domain's IOMMU mappings, and an iommu_op to synchronize (flush) those > manipulations with the hardware. > > Mappings added by the map operation are tracked and only those mappings > may be removed by a subsequent unmap operation. Frames are specified by the > owning domain and GFN. It is, of course, permissable for a domain to map > its own frames using DOMID_SELF. > > NOTE: The owning domain and GFN must also be specified in the unmap > operation, as well as the BFN, so that they can be cross-checked > with the existent mapping. > > Signed-off-by: Paul Durrant The code on the whole looks correct, but I don't see any reference counting. The call to get_paged_gfn() in iommuop_unmap() kind of underlines the issue -- what's to stop the following sequence of events? * iommuop_map() page A * share(A) * DMA write into A # -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/8] xen/x86: manually build xen.mb.efi binary
On Tue, Jul 10, 2018 at 07:54:51AM -0600, Jan Beulich wrote: > >>> On 10.07.18 at 12:48, wrote: > > On Fri, Jul 06, 2018 at 09:08:29AM -0600, Jan Beulich wrote: > >> >>> On 06.07.18 at 16:02, wrote: > >> > On Thu, Jul 05, 2018 at 02:18:03AM -0600, Jan Beulich wrote: > >> >> >>> On 04.07.18 at 18:35, wrote: > >> >> > On Wed, Jul 04, 2018 at 09:27:43AM -0600, Jan Beulich wrote: > >> >> >> >>> On 04.07.18 at 16:01, wrote: > >> >> >> > On Mon, Jun 25, 2018 at 09:36:07AM -0600, Jan Beulich wrote: > >> >> >> >> >>> On 19.06.18 at 16:35, wrote: > >> >> >> >> > @@ -582,6 +587,12 @@ static void __init > >> >> >> >> > efi_arch_memory_setup(void) > >> >> >> >> > if ( !efi_enabled(EFI_LOADER) ) > >> >> >> >> > return; > >> >> >> >> > > >> >> >> >> > +if ( efi_enabled(EFI_MB_LOADER) ) > >> >> >> >> > +for ( pte = __page_tables_start; pte < > >> >> >> >> > __page_tables_end; > >> >> >> >> > + pte += ( pte != (intpte_t *)l2_identmap ) ? 1 : > >> >> >> >> > 4 * L2_PAGETABLE_ENTRIES ) > >> >> >> >> > >> >> >> >> Please avoid explicit casts - _get_intpte(l2_identmap[0]) or > >> >> >> >> something along those lines ought to work here. Same for > >> >> >> >> 4 * L2_PAGETABLE_ENTRIES - you mean ARRAY_SIZE() there. > >> >> >> > > >> >> >> > OK. > >> >> >> > > >> >> >> >> Also this whole code block needs a comment, to explain what it > >> >> >> >> does and also why l2_identmap needs skipping. > >> >> >> >> > >> >> >> >> Furthermore - isn't this off by one, and you process > >> >> >> >> l2_identmap[0] > >> >> >> >> this way, skipping the rest _plus_ the first following entry? I > >> >> >> >> think > >> >> >> > > >> >> >> > The code mimics similar code in head.S. > >> >> >> > >> >> >> I can't see a similar off-by-1 in head.S. > >> >> > > >> >> > 662 /* > >> >> > 663 * Update frame addresses in page tables excluding > >> >> > l2_identmap > >> >> > 664 * without its first entry which points to l1_identmap. > >> >> > 665 */ > >> >> > 666 mov $((__page_tables_end-__page_tables_start)/8),%ecx > >> >> > 667 mov $(((l2_identmap-__page_tables_start)/8)+1),%edx > >> >> > 668 1: cmp > >> >> > $((l2_identmap+l2_identmap_sizeof-__page_tables_start)/8),%ecx > >> >> > 669 cmove %edx,%ecx > >> >> > 670 testl > >> >> > $_PAGE_PRESENT,sym_fs(__page_tables_start)-8(,%ecx,8) > >> >> > 671 jz 2f > >> >> > 672 add %esi,sym_fs(__page_tables_start)-8(,%ecx,8) > >> >> > 673 2: loop1b > >> >> > >> >> Well - this is the code in question, but you fail to point out where > >> >> the off-by-1 is. > >> > > >> > Line 667, 668 and 669. > >> > >> I don't think so, no. Note the -8 in lines 670 and 672. > > > > However, you are missing +1 in line 667. > > I don't think I am: The first entry of l2_identmap actually needs > processing afaics (and as the comment says), as that's the only one > with non-absolute contents. IOW - part of my original comment was > wrong, but the other half (you skipping one entry) still seems > applicable, as does the part concerning the missing comment. It seems correct to me. l2_identmap[0] gets updated and then we move to l3_bootmap[0]. Am I missing something? Daniel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 11/13] memory: add get_paged_gfn() as a wrapper...
On 07/07/2018 12:05 PM, Paul Durrant wrote:
> ...for some uses of get_page_from_gfn().
>
> There are many occurences of the following pattern in the code:
>
> q = ? P2M_ALLOC : P2M_UNSHARE;
> page = get_page_from_gfn(d, gfn, , q);
>
> if ( p2m_is_paging(p2mt) )
> {
> if ( page )
> put_page(page);
>
> p2m_mem_paging_populate(d, gfn);
> return <-ENOENT or equivalent>;
> }
>
> if ( (q & P2M_UNSHARE) && p2m_is_shared(p2mt) )
> {
> if ( page )
> put_page(page);
>
> return <-ENOENT or equivalent>;
> }
>
> if ( !page )
> return <-EINVAL or equivalent>;
>
> if ( !p2m_is_ram(p2mt) ||
> (! && p2m_is_readonly(p2mt)) )
> {
> put_page(page);
> return <-EINVAL or equivalent>;
> }
>
> There are some small differences between the exact way the occurrences are
> coded but the desired semantic is the same.
>
> This patch introduces a new common implementation of this code in
> get_paged_gfn() and then converts the various open-coded patterns into
> calls to this new function.
>
> Signed-off-by: Paul Durrant
This is a great idea.
It looks like this adds the restriction that the given gfn be ram (e.g.,
not MMIO) in all cases as well. It looks like that's what's wanted, but
it would be good to point this out in the commit message (so people can
verify that this change is warranted).
A few other comments...
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index c6b99c4116..510f37f100 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -375,39 +375,23 @@ static int get_paged_frame(unsigned long gfn, mfn_t
> *mfn,
> struct page_info **page, bool readonly,
> struct domain *rd)
> {
> -int rc = GNTST_okay;
> -p2m_type_t p2mt;
> -
> -*mfn = INVALID_MFN;
> -*page = get_page_from_gfn(rd, gfn, ,
> - readonly ? P2M_ALLOC : P2M_UNSHARE);
> -if ( !*page )
> -{
> -#ifdef P2M_SHARED_TYPES
> -if ( p2m_is_shared(p2mt) )
> -return GNTST_eagain;
> -#endif
> -#ifdef P2M_PAGES_TYPES
> -if ( p2m_is_paging(p2mt) )
> -{
> -p2m_mem_paging_populate(rd, gfn);
> -return GNTST_eagain;
> -}
> -#endif
> -return GNTST_bad_page;
> -}
> +int rc;
>
> -if ( p2m_is_foreign(p2mt) )
[snip]
> {
[snip]
> -put_page(*page);
> -*page = NULL;
> -
Comparing before-and-after, this seems to remove this 'p2m_is_foreign()'
check. Am I missing something?
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 35da9ca80e..419b76ac38 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1574,30 +1574,31 @@ void destroy_ring_for_helper(
> }
> }
>
> -int prepare_ring_for_helper(
> -struct domain *d, unsigned long gmfn, struct page_info **_page,
> -void **_va)
> +int get_paged_gfn(struct domain *d, gfn_t gfn, bool readonly,
> + p2m_type_t *p2mt_p, struct page_info **page_p)
This wants a comment somewhere describing exactly what the function does
and what it will return -- probably here above the function definition
itself would be the best.
> {
> -struct page_info *page;
> +p2m_query_t q = readonly ? P2M_ALLOC : P2M_UNSHARE;
> p2m_type_t p2mt;
> -void *va;
> +struct page_info *page;
>
> -page = get_page_from_gfn(d, gmfn, , P2M_UNSHARE);
> +page = get_page_from_gfn(d, gfn_x(gfn), , q);
>
> #ifdef CONFIG_HAS_MEM_PAGING
> if ( p2m_is_paging(p2mt) )
> {
> if ( page )
> put_page(page);
> -p2m_mem_paging_populate(d, gmfn);
> +
> +p2m_mem_paging_populate(d, gfn_x(gfn));
> return -ENOENT;
I realize you're copying the return values of prepare_ring_for_helper(),
but wouldn't -EAGAIN be more natural here?
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Wed 11-07-18 13:14:47, Leon Romanovsky wrote: > On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote: > > On Tue 10-07-18 19:20:20, Leon Romanovsky wrote: > > > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote: > > > > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote: > > > > > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote: > > > > > > On Wed 27-06-18 09:44:21, Michal Hocko wrote: > > > > > > > This is the v2 of RFC based on the feedback I've received so far. > > > > > > > The > > > > > > > code even compiles as a bonus ;) I haven't runtime tested it yet, > > > > > > > mostly > > > > > > > because I have no idea how. > > > > > > > > > > > > > > Any further feedback is highly appreciated of course. > > > > > > > > > > > > Any other feedback before I post this as non-RFC? > > > > > > > > > > From mlx5 perspective, who is primary user of umem_odp.c your change > > > > > looks ok. > > > > > > > > Can I assume your Acked-by? > > > > > > I didn't have a chance to test it because it applies on our rdma-next, but > > > fails to compile. > > > > What is the compilation problem? Is it caused by the patch or some other > > unrelated changed? > > Thanks for pushing me to take a look on it. > Your patch needs the following hunk to properly compile at least on my system. I suspect you were trying the original version. I've posted an updated patch here http://lkml.kernel.org/r/20180627074421.gf32...@dhcp22.suse.cz and all these issues should be fixed there. Including many other fixes. Could you have a look at that one please? -- Michal Hocko SUSE Labs ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.7-testing test] 125057: tolerable FAIL - PUSHED
flight 125057 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125057/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 124880 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 124930 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 124985 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 124985 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 124985 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 124985 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124985 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124985 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 124985 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 124985 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 124985 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124985 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 124985 test-amd64-amd64-xl-rtds 10 debian-install fail like 124985 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 124985 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl 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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 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-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 280a5568939c4a5832be787c8e0c23a19f30935a baseline version: xen e7956461f76f4b6e9d7d1d99daabdeef9ea09f62 Last test of basis 124985 2018-07-04 23:52:41 Z6 days Testing same since 125057 2018-07-09 08:36:04 Z2 days1 attempts People who touched revisions under test: Jan Beulich jobs: build-amd64-xsm
Re: [Xen-devel] [PATCH v2 09/13] vtd: add lookup_page method to iommu_ops
On Sat, Jul 7, 2018 at 12:05 PM, Paul Durrant wrote:
> This patch adds a new method to the VT-d IOMMU implementation to find the
> MFN currently mapped by the specified BFN along with a wrapper function in
> generic IOMMU code to call the implementation if it exists.
>
> This functionality will be used by a subsequent patch.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Kevin Tian
> Cc: Jan Beulich
>
> v2:
> - Addressed some comments from Jan.
> ---
> xen/drivers/passthrough/iommu.c | 11 ++
> xen/drivers/passthrough/vtd/iommu.c | 40
> +
> xen/drivers/passthrough/vtd/iommu.h | 1 +
> xen/include/xen/iommu.h | 4
> 4 files changed, 56 insertions(+)
>
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index 3fbd3ebaf6..f25aa3f1d6 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -306,6 +306,17 @@ int iommu_unmap_page(struct domain *d, bfn_t bfn)
> return rc;
> }
>
> +int iommu_lookup_page(struct domain *d, bfn_t bfn, mfn_t *mfn,
> + unsigned int *flags)
> +{
> +const struct domain_iommu *hd = dom_iommu(d);
> +
> +if ( !iommu_enabled || !hd->platform_ops )
> +return -EOPNOTSUPP;
> +
> +return hd->platform_ops->lookup_page(d, bfn, mfn, flags);
> +}
> +
> static void iommu_free_pagetables(unsigned long unused)
> {
> do {
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index 7cd3813b9f..438bef670d 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1831,6 +1831,45 @@ static int __must_check intel_iommu_unmap_page(struct
> domain *d,
> return dma_pte_clear_one(d, bfn_to_baddr(bfn));
> }
>
> +static int intel_iommu_lookup_page(struct domain *d, bfn_t bfn, mfn_t *mfn,
> + unsigned int *flags)
> +{
> +struct domain_iommu *hd = dom_iommu(d);
> +struct dma_pte *page = NULL, *pte = NULL, val;
> +u64 pg_maddr;
> +
> +spin_lock(>arch.mapping_lock);
> +
> +pg_maddr = addr_to_dma_page_maddr(d, bfn_to_baddr(bfn), 0);
> +if ( pg_maddr == 0 )
> +{
> +spin_unlock(>arch.mapping_lock);
> +return -ENOMEM;
> +}
> +
> +page = map_vtd_domain_page(pg_maddr);
> +pte = page + (bfn_x(bfn) & LEVEL_MASK);
> +val = *pte;
> +if ( !dma_pte_present(val) )
> +{
> +unmap_vtd_domain_page(page);
> +spin_unlock(>arch.mapping_lock);
> +return -ENOMEM;
Should this be -EEXIST? Or maybe return MFN_INVALID?
Also, could you do the unmap / unlock first and then do the check,
rather than duplicating things?
> +}
> +
> +unmap_vtd_domain_page(page);
> +spin_unlock(>arch.mapping_lock);
> +
> +*mfn = maddr_to_mfn(dma_pte_addr(val));
> +*flags = 0;
> +if ( dma_pte_prot(val) & DMA_PTE_READ )
> +*flags |= IOMMUF_readable;
> +if ( dma_pte_prot(val) & DMA_PTE_WRITE )
> +*flags |= IOMMUF_writable;
This is a bit strange, since all dma_pte_prot() does is return val &
DMA_PTE_READ|DMA_PTE_WRITE. Would it make sense to implement
dma_pte_read() / dma_pte_write() instead (like dma_pte_present())?
Everything else looks good to me.
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/x86: fix linker script to work with lld
On Wed, Jul 11, 2018 at 12:25:21PM +0200, Roger Pau Monne wrote: > lld (the llvm linker) has some issues with Xen linker script. It > doesn't understand '||' in assert expressions: > > ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \ > /root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0 > ld: error: xen.lds:260: malformed number: | > >>> ASSERT(__image_base__ > (261 >> 8) * 0x) | (261 > >>> << 39))) + ((1 << 39) / 2)) + (64 << 30)) + (1 << 30)) + (1 << 30))) || > >>> > >>> ^ > > And doesn't work properly with the 'DEFINED(foo) ? foo : ...' > expression: > > ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \ > /root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0 > ld: error: xen.lds:233: symbol not found: efi > > Fix the first issue by using '|' instead of '||', and the second one > by declaring the efi symbol as a weak symbol. > > Signed-off-by: Roger Pau Monné > --- > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: Daniel Kiper > --- > Changes since v1: > - Export efi as a weak symbol in order to remove the DEFINED >conditional in the linker script. > - Add a define for setting the weak attribute and replace existing >users. May I ask you to split this patch into two separate patches? One for __weak change and one for DEFINED() drop please. Daniel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-coverity test] 125103: all pass - PUSHED
flight 125103 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/125103/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen f5d10dc2909c84e4ffc7240e542c513ed480aa04 baseline version: xen 2ddfae51d8b1d7b8cd33a4f6ad4d16d27cb869ae Last test of basis 125047 2018-07-08 09:18:22 Z3 days Testing same since 125103 2018-07-11 09:18:25 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Doug Goldstein George Dunlap Ian Jackson Jan Beulich Juergen Gross Julien Grall Lars Kurth Oleksandr Grytsov Roger Pau Monne Roger Pau Monné Wei Liu jobs: coverity-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 2ddfae51d8..f5d10dc290 f5d10dc2909c84e4ffc7240e542c513ed480aa04 -> coverity-tested/smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 08/13] x86: add iommu_op to query reserved ranges
On 07/07/2018 12:05 PM, Paul Durrant wrote:
> @@ -35,17 +93,33 @@ static void iommu_op(xen_iommu_op_t *op)
>
> int do_one_iommu_op(xen_iommu_op_buf_t *buf)
> {
> -xen_iommu_op_t op;
> +xen_iommu_op_t op = {};
> +size_t offset;
> +static const size_t op_size[] = {
> +[XEN_IOMMUOP_query_reserved] = sizeof(struct
> xen_iommu_op_query_reserved),
> +};
> +
> +offset = offsetof(struct xen_iommu_op, u);
>
> -if ( buf->size < sizeof(op) )
> +if ( buf->size < offset )
> return -EFAULT;
>
> -if ( copy_from_guest((void *), buf->h, sizeof(op)) )
> +if ( copy_from_guest((void *), buf->h, offset) )
> return -EFAULT;
>
> if ( op.pad )
> return -EINVAL;
>
> +if ( op.op >= ARRAY_SIZE(op_size) )
> +return -EOPNOTSUPP;
> +
> +if ( buf->size < offset + op_size[op.op] )
> +return -EFAULT;
> +
> +if ( copy_from_guest_offset((void *), buf->h, offset,
> +op_size[op.op]) )
> +return -EFAULT;
This looks like part of a potential SP1 gadget, so this needs to use
array_index_nospec().
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125101: tolerable all pass - PUSHED
flight 125101 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125101/ 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 f3d275cb5eae88295b14fce6b022290e939f6a28 baseline version: xen f5d10dc2909c84e4ffc7240e542c513ed480aa04 Last test of basis 125080 2018-07-10 18:00:30 Z0 days Testing same since 125101 2018-07-11 08:00:29 Z0 days1 attempts People who touched revisions under test: Doug Goldstein Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f5d10dc290..f3d275cb5e f3d275cb5eae88295b14fce6b022290e939f6a28 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] xen/x86: fix linker script to work with lld
lld (the llvm linker) has some issues with Xen linker script. It
doesn't understand '||' in assert expressions:
ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \
/root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
ld: error: xen.lds:260: malformed number: |
>>> ASSERT(__image_base__ > (261 >> 8) * 0x) | (261 <<
>>> 39))) + ((1 << 39) / 2)) + (64 << 30)) + (1 << 30)) + (1 << 30))) ||
>>>
>>> ^
And doesn't work properly with the 'DEFINED(foo) ? foo : ...'
expression:
ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \
/root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
ld: error: xen.lds:233: symbol not found: efi
Fix the first issue by using '|' instead of '||', and the second one
by declaring the efi symbol as a weak symbol.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Daniel Kiper
---
Changes since v1:
- Export efi as a weak symbol in order to remove the DEFINED
conditional in the linker script.
- Add a define for setting the weak attribute and replace existing
users.
---
xen/arch/x86/xen.lds.S | 4 +---
xen/include/xen/compiler.h | 2 ++
xen/include/xen/efi.h | 2 +-
xen/include/xen/livepatch_payload.h | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 70afedd31d..9fa40a6d48 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -304,8 +304,6 @@ SECTIONS
} :text
#endif
- efi = DEFINED(efi) ? efi : .;
-
/* Sections to be discarded */
/DISCARD/ : {
*(.exit.text)
@@ -331,7 +329,7 @@ SECTIONS
.comment 0 : { *(.comment) }
}
-ASSERT(__image_base__ > XEN_VIRT_START ||
+ASSERT(__image_base__ > XEN_VIRT_START |
__2M_rwdata_end <= XEN_VIRT_END - NR_CPUS * PAGE_SIZE,
"Xen image overlaps stubs area")
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index a7e05681c9..001f589655 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -18,6 +18,8 @@
#define __packed __attribute__((__packed__))
+#define __weak__attribute__((weak))
+
#if (!defined(__clang__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 5))
#define unreachable() do {} while (1)
#else
diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h
index 44b7d3ec3a..5678df72f9 100644
--- a/xen/include/xen/efi.h
+++ b/xen/include/xen/efi.h
@@ -21,7 +21,7 @@ struct efi {
unsigned long smbios3; /* SMBIOS v3 table */
};
-extern struct efi efi;
+extern struct efi __weak efi;
#ifndef __ASSEMBLY__
diff --git a/xen/include/xen/livepatch_payload.h
b/xen/include/xen/livepatch_payload.h
index 8f38cc2c60..4a1a96d054 100644
--- a/xen/include/xen/livepatch_payload.h
+++ b/xen/include/xen/livepatch_payload.h
@@ -24,7 +24,7 @@ typedef void livepatch_unloadcall_t(void);
* executed in series by the livepatch infrastructure at patch load time.
*/
#define LIVEPATCH_LOAD_HOOK(_fn) \
-livepatch_loadcall_t *__attribute__((weak)) \
+livepatch_loadcall_t *__weak \
const livepatch_load_data_##_fn __section(".livepatch.hooks.load") =
_fn;
/*
@@ -33,7 +33,7 @@ typedef void livepatch_unloadcall_t(void);
* Same as LOAD hook with s/load/unload/
*/
#define LIVEPATCH_UNLOAD_HOOK(_fn) \
- livepatch_unloadcall_t *__attribute__((weak)) \
+ livepatch_unloadcall_t *__weak \
const livepatch_unload_data_##_fn __section(".livepatch.hooks.unload")
= _fn;
#endif /* __XEN_LIVEPATCH_PAYLOAD_H__ */
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote:
> On Tue 10-07-18 19:20:20, Leon Romanovsky wrote:
> > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote:
> > > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote:
> > > > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote:
> > > > > On Wed 27-06-18 09:44:21, Michal Hocko wrote:
> > > > > > This is the v2 of RFC based on the feedback I've received so far.
> > > > > > The
> > > > > > code even compiles as a bonus ;) I haven't runtime tested it yet,
> > > > > > mostly
> > > > > > because I have no idea how.
> > > > > >
> > > > > > Any further feedback is highly appreciated of course.
> > > > >
> > > > > Any other feedback before I post this as non-RFC?
> > > >
> > > > From mlx5 perspective, who is primary user of umem_odp.c your change
> > > > looks ok.
> > >
> > > Can I assume your Acked-by?
> >
> > I didn't have a chance to test it because it applies on our rdma-next, but
> > fails to compile.
>
> What is the compilation problem? Is it caused by the patch or some other
> unrelated changed?
Thanks for pushing me to take a look on it.
Your patch needs the following hunk to properly compile at least on my system.
I'll take it to our regression.
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 369867501bed..1f364a157097 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -155,9 +155,9 @@ struct mmu_notifier_ops {
* cannot block, mmu_notifier_ops.flags should have
* MMU_INVALIDATE_DOES_NOT_BLOCK set.
*/
- void (*invalidate_range_start)(struct mmu_notifier *mn,
+ int (*invalidate_range_start)(struct mmu_notifier *mn,
struct mm_struct *mm,
- unsigned long start, unsigned long end);
+ unsigned long start, unsigned long end,
bool blockable);
void (*invalidate_range_end)(struct mmu_notifier *mn,
struct mm_struct *mm,
unsigned long start, unsigned long end);
@@ -229,7 +229,7 @@ extern int __mmu_notifier_test_young(struct mm_struct *mm,
unsigned long address);
extern void __mmu_notifier_change_pte(struct mm_struct *mm,
unsigned long address, pte_t pte);
-extern void __mmu_notifier_invalidate_range_start(struct mm_struct *mm,
+extern int __mmu_notifier_invalidate_range_start(struct mm_struct *mm,
unsigned long start, unsigned long end,
bool blockable);
extern void __mmu_notifier_invalidate_range_end(struct mm_struct *mm,
diff --git a/include/linux/oom.h b/include/linux/oom.h
index 6adac113e96d..92f70e4c6252 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -95,7 +95,7 @@ static inline int check_stable_address_space(struct mm_struct
*mm)
return 0;
}
-void __oom_reap_task_mm(struct mm_struct *mm);
+bool __oom_reap_task_mm(struct mm_struct *mm);
extern unsigned long oom_badness(struct task_struct *p,
struct mem_cgroup *memcg, const nodemask_t *nodemask,
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 7e0c6e78ae5c..7c7bd6f3298e 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -1,6 +1,6 @@
/*
* linux/mm/oom_kill.c
- *
+ *
* Copyright (C) 1998,2000 Rik van Riel
* Thanks go out to Claus Fischer for some serious inspiration and
* for goading me into coding this file...
@@ -569,7 +569,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
if (!__oom_reap_task_mm(mm)) {
up_read(>mmap_sem);
ret = false;
- goto out_unlock;
+ goto unlock_oom;
}
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
Thanks
> --
> Michal Hocko
> SUSE Labs
signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] 答复: 答复: 答复: 答复: 答复: Help: a xen crash of 4.8.2 version/////答复: Is there a faster way to restore Virtual machine status in Xen?
Dear xen expert： From the blocked information, we found that the CPU 14 and CPU 19 is blocked, and the call trace is mainly about: [68915.792526] [] on_each_cpu+0x28/0x60 [68915.792540] [] decrease_reservation+0x261/0x2f0 [68915.792555] [] alloc_xenballooned_pages+0xe6/0x180 [68915.792571] [] gnttab_alloc_pages+0x11/0x40 [68915.792586] [] gntdev_ioctl+0x23c/0x750 [xen_gntdev] [68915.792608] [] do_vfs_ioctl+0x2e3/0x4c0 [68915.792631] [] SyS_ioctl+0x74/0x80 [68915.792644] [] entry_SYSCALL_64_fastpath+0x1e/0xca [69175.786405] Call Trace: [69175.786418] [] pagecache_get_page+0x168/0x1d0 [69175.786471] [] prepare_pages+0xa9/0x1b0 [btrfs] [69175.786508] [] __btrfs_buffered_write+0x212/0x680 [btrfs] [69175.786543] [] btrfs_file_write_iter+0x183/0x5c0 [btrfs] [69175.786560] [] __vfs_write+0xb6/0x100 [69175.786574] [] vfs_write+0x9d/0x190 [69175.786587] [] SyS_write+0x42/0xa0 [69175.786599] [] entry_SYSCALL_64_fastpath+0x1e/0xca [69175.793881] DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x1e/0xca What the reason maybe to cause this problem? Is there some way to Prevent the kernel from doing similar processing and avoiding this problems? Looking forward to your reply,thank you! Best Regards -邮件原件- 发件人: Chenjia (C) 发送时间: 2018年7月9日 10:12 收件人: 'Juergen Gross' 抄送: zhaobingjian ; Shentao (Terry) ; Yaoshaomin ; Zhuxiaolin (A) ; wangxu (R) ; xen-devel ; yuanjinfeng ; Hutao (C) ; Jugang (David, Enterprise Network) ; Jan Beulich 主题: 答复: 答复: 答复: 答复: [Xen-devel] 答复: Help: a xen crash of 4.8.2 version/答复: Is there a faster way to restore Virtual machine status in Xen? Dear Juergen: We have disable DPDK and add conring_size=1M on the server(xen 4.8.3 with dom0 linux kernel 4.4.121-92.85-default), and we still got the blocked information, please see the attach file to help us. Thank you! Best Regards -邮件原件- 发件人: Juergen Gross [mailto:jgr...@suse.com] 发送时间: 2018年7月6日 15:50 收件人: Chenjia (C) ; Jan Beulich 抄送: zhaobingjian ; Shentao (Terry) ; Yaoshaomin ; Zhuxiaolin (A) ; wangxu (R) ; xen-devel ; yuanjinfeng ; Hutao (C) 主题: Re: 答复: 答复: 答复: [Xen-devel] 答复: Help: a xen crash of 4.8.2 version/答复: Is there a faster way to restore Virtual machine status in Xen? On 06/07/18 08:27, Chenjia (C) wrote: > Dear Juergen: >We will follow your suggestion: unload DPDK, then test a again. > > Our server have 24 vcpu, and if we press '0' it only show 10 vcpu's > dump message, is there a way to show more dump message? Looking more at this I guess the console ring buffer is too small. Please add conring_size=1M to your hypervisor boot parameters. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/3] xen: set cpu capabilities from xen_start_kernel()
On Wed, 2018-07-11 at 11:46 +0200, Juergen Gross wrote:
> On 11/07/18 11:15, Woodhouse, David wrote:
> >
> > On Wed, 2018-05-30 at 13:09 +0200, Juergen Gross wrote:
> > >
> > > There is no need to set the same capabilities for each cpu
> > > individually. This can easily be done for all cpus when starting the
> > > kernel.
> > >
> > > Upstream commit: 0808e80cb760de2733c0527d2090ed2205a1eef8 ("xen: set
> > > cpu capabilities from xen_start_kernel()")
> > >
> > > Signed-off-by: Juergen Gross
> > > Reviewed-by: Boris Ostrovsky
> > That breaks PV guests because they get KAISER enabled — when
> > kaiser_check_boottime_disable() runs, X86_FEATURE_XENPV isn't set.
>
> Which kernel version are you talking about?
>
> With upstream commit 60d3450167433f2d099ce2869dc52dd9e7dc9b29 which will
> be part of next stable-4.9 everything is fine.
Right. That's what Simon had also backported. We hadn't spotted it was
already lined up.
smime.p7s
Description: S/MIME cryptographic signature
Amazon Development Centre (London) Ltd. Registered in England and Wales with
registration number 04543232 with its registered office at 1 Principal Place,
Worship Street, London EC2A 2FA, United Kingdom.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
