Re: [Xen-devel] [PATCH -tip v4 0/4] x86: kprobes: Prohibit kprobes on Xen/KVM emulate prefixes
Hi Peter, On Wed, 9 Oct 2019 14:31:06 +0200 Peter Zijlstra wrote: > On Tue, Sep 17, 2019 at 03:14:03PM +0900, Masami Hiramatsu wrote: > > Hi Peter, > > > > Could you review this version? > > These look good to me; shall I merge them or what was the plan? Thanks for the review, yes, could you merge this series to support emulated prefixes correctly? Thank you, -- Masami Hiramatsu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] How PV frontend and backend initializes?
Anthony and Roger, thanks for your informative responses. It helped a lot. > I'm however unsure by what you mean with instance, so you might have > to clarify exactly what you mean in order to get a more concise > reply. Let's say there are two DomU's, and their respective network interfaces are xenbr0 and xenbr1. Therefore, there supposed to be two PV netback drivers running in Dom0 (or driver domain): one for xenbr0 and another for xenbr1. By the term instance, I am refering to these drivers. If later there comes another interface xenbr3, there will be the third instance of the backend driver. I was wondering how these multiple instances are created and when. Now, as you pointed to the xen toolstack, I explored xl/libxl a little bit. I realized for two separate devices, libxl creates two different paths both for the frontend and backend. The OSes keeps watching xenstore paths. If an OS finds a device of the type it is interested in, it creates the instance of the corresponding driver (frontend or backend) if the device is not initialized already. The path is the parameter which make one instance different from the others. Please let me know if I understood it wrong. Thanks! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 142783: regressions - trouble: fail/pass/starved
flight 142783 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/142783/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 140282 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 140282 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 140282 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 140282 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140282 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140282 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-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-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail
Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure
> On Oct 15, 2019, at 08:27, Lars Kurth wrote: > Hi Rich, > On 15 Oct 2019, at 02:58, Rich Persaud wrote: > On Oct 11, 2019, at 07:11, Lars Kurth wrote: >>> On 11/10/2019, 02:24, "Stefano Stabellini" wrote: On Thu, 10 Oct 2019, Lars Kurth wrote: @Stefano: as you and I believe Brian will be spending time on improving the ABI docs, I think we need to build some agreement here on what/how to do it. I was assuming that generally the consensus was to have docs close to the code in source, but this does not seem to be the case. But if we do have stuff separately, ideally we would have a tool that helps point people editing headers to also look at the relevant docs. Otherwise it will be hard to keep them in sync. >>> In general, it is a good idea to keep the docs close to the code to make >>> it easier to keep them up to date. But there is no one-size-fits-all >>> here. For public ABI descriptions, I agree with Andrew that ideally they >>> should not be defined as C header files. >>> But it is not an issue: any work that we do here won't be wasted. For >>> instance, we could start by adding more comments to the current header >>> files. Then, as a second step, take all the comments and turn them into >>> a proper ABI description document without any C function declarations. >>> It is easy to move English text around, as long as the license allows it >>> -- that is the only potential blocker I can see. >>> This is likely to be problematic. First of all, we are talking about >>> BSD-3-Clause >>> or BSD-2-Clause code (the latter is more dominant in headers I believe) in >>> all known cases. >>> The main properties of the BSD are >>> 1: Can be pretty much used anywhere for any purpose >>> 2: Can be modified for any purpose >>> 3: But the original license header must be retained in derivates >> >> This is equivalent to attribution of the copyright owner of the originally >> created file. >> >>> Does *not* have requirements around attribution as CC-BY-4: however, >>> as we store everything in git attribution is handled by us by default >> >> See above, the license header attributes copyright, since BSD was created >> for "software" and people who work on "software" would typically be looking >> at source code, hence the primary attribution takes place there, with >> secondary attribution in EULAs, "About" panels, etc. >> >>> CC-BY-4 also has properties 1-3 >>> In addition: it does require that >>> 4: Derived works are giving appropriate credit to authors >>> We could clarify in a COPYING how we prefer to do this >>> 4.1: We could say that "referring to the Xen Project community" >>> is sufficient to comply with the attribution clause >> >> One motivation for CC-BY (with attribution) is to create an incentive >> (credit) for the creation of documentation, which is not commonly a favorite >> pastime of developers. Credit typically goes at least to the original >> author of a section of documentation, with varying ways of crediting >> subsequent contributors. The documentation can be structured to make >> crediting easier. The mechanism for crediting can be designed to encourage >> specific outcomes, along our projected doc lifecycle for safety >> certification, contributors, evaluators and commercial investors. > > My point really was is that due to storing the files in git, we essentially > do NOT today do this. > So we would need to take extra action: e.g. manually or through tooling > >>> 4.2: We could require individual authors to be credited: in that >>> case we probably ought to lead by example and list the authors >>> in a credit/license section and extract the information from >>> git logs when we generate it (at some point in the future) >>> 5: You give an indication whether you made changes ... in practice >>> this means you have to state significant changes made to the works >> >> This is also helpful for provenance of changes, which is relevant in >> safety-oriented documentation. It can be used to clearly delineate >> CC-licensed content (which may be reused by many companies) from "All Rights >> Reserved" commercial content that may be added for a specific commercial >> audience or purpose. > > I agree > > I think the outcome of this analysis is really that the only significant > difference between BSD and CC-BY in this context is the "All Rights > Reserved" portion Also - BSD is a "software" license while CC-BY is a "content" license, so they are not strictly comparable, even if they use similar terminology. >> There is a difference between "software" which "runs on machines" and >> "documentation" which "runs on humans". Combined software (e.g. BSD code >> from two origins) is executed identically, despite origin. Humans make >> value judgements based on the author/origin of content, hence the focus on >> attribution. Yes, there is
Re: [Xen-devel] [PATCH for-4.13] xen/arm: setup: Calculate correctly the size of Xen
On Wed, 16 Oct 2019, Julien Grall wrote: > The current size of Xen is computed using _end - _start + 1. However, > _end is pointing one past the end of Xen, so the size of Xen is > off-by-one. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > --- > xen/arch/arm/setup.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 705a917abf..51d32106b7 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -819,7 +819,7 @@ void __init start_xen(unsigned long boot_phys_offset, > /* Register Xen's load address as a boot module. */ > xen_bootmodule = add_boot_module(BOOTMOD_XEN, > (paddr_t)(uintptr_t)(_start + boot_phys_offset), > - (paddr_t)(uintptr_t)(_end - _start + 1), false); > + (paddr_t)(uintptr_t)(_end - _start), false); > BUG_ON(!xen_bootmodule); > > fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr); > -- > 2.11.0 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13 v2] xen/arm: Don't use _end in is_xen_fixed_mfn()
On Wed, 16 Oct 2019, Julien Grall wrote: > virt_to_maddr() is using the hardware page-table walk instructions to > translate a virtual address to physical address. The function should > only be called on virtual address mapped. > > _end points past the end of Xen binary and may not be mapped when the > binary size is page-aligned. This means virt_to_maddr() will not be able > to do the translation and therefore crash Xen. > > Note there is also an off-by-one issue in this code, but the panic will > trump that. > > Both issues can be fixed by using _end - 1 in the check. > > Signed-off-by: Julien Grall > Release-acked-by: Juergen Gross Reviewed-by: Stefano Stabellini > --- > > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Julien Grall > Cc: Konrad Rzeszutek Wilk > Cc: Stefano Stabellini > Cc: Tim Deegan > Cc: Wei Liu > > x86 seems to be affected by the off-by-one issue. Jan, Andrew? > > This could be reached by a domain via XEN_SYSCTL_page_offline_op. > However, the operation is not security supported (see XSA-77). So we are > fine here. > > Changes in v2: > - Cast _end to vaddr_t to prevent UB. > - Add Juergen's released-acked-by > --- > xen/include/asm-arm/mm.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h > index 262d92f18d..333efd3a60 100644 > --- a/xen/include/asm-arm/mm.h > +++ b/xen/include/asm-arm/mm.h > @@ -153,7 +153,7 @@ extern unsigned long xenheap_base_pdx; > > #define is_xen_fixed_mfn(mfn) \ > ((mfn_to_maddr(mfn) >= virt_to_maddr(&_start)) && \ > - (mfn_to_maddr(mfn) <= virt_to_maddr(&_end))) > + (mfn_to_maddr(mfn) <= virt_to_maddr((vaddr_t)_end - 1))) > > #define page_get_owner(_p)(_p)->v.inuse.domain > #define page_set_owner(_p,_d) ((_p)->v.inuse.domain = (_d)) > -- > 2.11.0 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
On Wed, 16 Oct 2019, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH for-4.13] xen/arm: Don't use _end in
> is_xen_fixed_mfn()"):
> > My suggestion is going to work: "the compiler sees through casts"
> > referred to comparisons between pointers, where we temporarily casted
> > both pointers to integers and back to pointers via a MACRO. That case
> > was iffy because the MACRO was clearly a workaround the spec.
> >
> > Here the situation is different. For one, we are doing arithmetic. Also
> > virt_to_maddr already takes a vaddr_t as argument. So instead of doing
> > pointers arithmetic, then converting to vaddr_t, we are converting to
> > vaddr_t first, then doing arithmetics, which is fine both from a C99
> > point of view and even a MISRA C point of view. I can't see a problem
> > with that. I am sure as I reasonable can be :-)
>
> FTAOD I think you are suggesting this:
> - + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1)))
> + + (mfn_to_maddr(mfn) <= virt_to_maddr(((vaddr_t)_end - 1)))
>
> virt_to_maddr(va) is a macro which expands to
>__virt_to_maddr((vaddr_t)(va))
>
> So what is happening here is that the cast to an integer type is being
> done before the subtraction.
>
> Without the cast, you are calculating the pointer value _end-1 from
> the value _end, which is UB. With the cast you are calculating an
> integer value. vaddr_t is unsigned, so all arithmetic operations are
> defined. Nothing casts the result back to the "forbidden" (with this
> provenance) pointer value, so all is well.
>
> (With the macro expansion the cast happens twice. This is probably
> better than using __virt_to_maddr here.)
>
> Ie, in this case I agree with Stefano. The cast is both necessary and
> sufficient.
Thanks Ian for the second pair of eyes!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v1] libxl: Add DTB compatible list to config file
Hi,
On 16/10/2019 15:34, Oleksandr Grytsov wrote:
On Wed, Oct 16, 2019 at 5:12 PM Julien Grall wrote:
Hi Oleksandr,
On 16/10/2019 15:04, Oleksandr Grytsov wrote:
On Fri, Oct 11, 2019 at 8:21 PM Stefano Stabellini
wrote:
On Fri, 11 Oct 2019, Julien Grall wrote:
Hi,
On 11/10/2019 16:23, Ian Jackson wrote:
Oleksandr Grytsov writes ("[PATCH v1] libxl: Add DTB compatible list to
config file"):
From: Oleksandr Grytsov
Some platforms need more compatible property values in device
tree root node in addition to "xen,xenvm-%d.%d" and "xen,xenvm"
values that are given by Xen by default.
I am pretty sure I have seen this patch a few years ago, but I can't find it
in my inbox. What is the exact problem here?
Specify in domain configuration file which values should be added
by providing "dtb_compatible" list of strings separated by comas.
Hi, thanks.
I don't have an opinion about the principle of this and would like to
hear from ARM folks about that.
Also, Stefano, Julien: should we be asking for a freeze exception for
this for 4.13 ?
I don't have enough context to understand the exact issue he is trying to
solve.
Same here. Is this patch needed because on some platform the OS checks
for the platform "model" (also known as "machine name") on device tree
before continuing or to trigger a difference behavior?
Yes, exactly.
I will redo the patch with Ian's comments if it is ok in general.
By specifying a different compatible (let say "renesas,r8a774a1"), then you
claim that your virtual machine is exactly the same as that board.
This means, the OS is free to assume that the memory layout and all the devices
are exactly the same. This is definitely not true as the virtual machine we
expose is specific to Xen.
So I don't think this is the correct approach here. Can you provide a real-life
example on why you need this?
Cheers,
--
Julien Grall
This is required for HW domains. Some drivers or initialization routines check
compatible.
So this suggest you will need to expose the compatible to multiple domains at
the same time.
How is this even going to be safe? As I pointed out in my previous e-mail, if
you set the compatible, then your OS is free to assume all the devices for that
SoC are present and the memory layout is fixed.
Very likely, you are only going to expose a subset of the devices to each
domains. So you either going to have a crash (if nothing were mapped at the
address access) or write to the wrong device.
Below is example from linux kernel sources:
linux/sound/ppc/awacs.c:741:if (of_machine_is_compatible("PowerBook3,1")
linux/sound/ppc/awacs.c:742:||
of_machine_is_compatible("PowerBook3,2")) {
linux/sound/ppc/awacs.c:770:#define IS_PM7500
(of_machine_is_compatible("AAPL,7500") \
linux/sound/ppc/awacs.c:771:|| of_machine_is_compatible("AAPL,8500") \
linux/sound/ppc/awacs.c:772:|| of_machine_is_compatible("AAPL,9500"))
...
linux/arch/arm/mach-omap2/pdata-quirks.c:703:if
(of_machine_is_compatible(quirks->compatible)) {
linux/arch/arm/mach-omap2/pdata-quirks.c:717:if
(of_machine_is_compatible("ti,omap2420") ||
linux/arch/arm/mach-omap2/pdata-quirks.c:718:
of_machine_is_compatible("ti,omap3"))
linux/arch/arm/mach-omap2/pdata-quirks.c:721:if
(of_machine_is_compatible("ti,omap3"))
...
Also see [1]
[1]
https://source.codeaurora.org/external/imx/imx-xen/commit/?h=imx_4.14.98_2.0.0_ga=6e58d478203639e71da3da69ffeae3fa5dc0197b
So this is a grep from Linux, I have already done that. What I am looking at is
an exact description of your problem. Can you tell me what you are trying to
passthrough? Can you also provide a pointer to the Linux code checking the
compatible for your problem?
But speaking with various Linux folks, a device should really not rely on the
SoC compatible to decide whether it needs to be initialized/requires quirk. The
correct solution here is to fix your bindings/driver so they don't rely on it.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 142803: regressions - trouble: blocked/fail
flight 142803 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/142803/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501 Tests which did not succeed, but are not blocking: build-amd64-xen-freebsd 1 build-check(1) blocked n/a build-amd64-freebsd-again 1 build-check(1) blocked n/a version targeted for testing: freebsd 12434b0a3620332fe3cdfb21db2a348e6f689b5f baseline version: freebsd 14aef6dfca96006e52b8fb920bde7c612ba58b79 Last test of basis 141501 2019-09-20 09:19:51 Z 26 days Failing since141701 2019-09-23 09:19:41 Z 23 days 10 attempts Testing same since 142803 2019-10-16 09:19:52 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> ae alc Alek Pinchuk allanjude ambrisko andrew asomers avg bapt bdragon br brooks cem cognet cperciva cy dab daichi dchagin dim dougm emaste erj eugen gallatin gjb glebius gonzo grembo hrs hselasky ian imp jeff jhb jhibbits jilles jkim jlh jmg jtl kaktus kan karels kevans kib kp lstewart luporl lwhsu manu markj mav mckusick mhorne mjg mm mmacy np olivier oshogbo philip Piotr Pietruszewski ray rmacklem royger rrs rstone samm schweikh scottl sef sjg tijl Tom Caputi trasz tsoome tuexen vangyzen vmaffione yuripv Zach Vargas jobs: build-amd64-freebsd-againblocked build-amd64-freebsd fail build-amd64-xen-freebsd 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. (No revision log; it would be 9809 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v1] libxl: Add DTB compatible list to config file
On Wed, Oct 16, 2019 at 5:12 PM Julien Grall wrote:
>
> Hi Oleksandr,
>
> On 16/10/2019 15:04, Oleksandr Grytsov wrote:
> > On Fri, Oct 11, 2019 at 8:21 PM Stefano Stabellini
> > wrote:
> >>
> >> On Fri, 11 Oct 2019, Julien Grall wrote:
> >>> Hi,
> >>>
> >>> On 11/10/2019 16:23, Ian Jackson wrote:
> Oleksandr Grytsov writes ("[PATCH v1] libxl: Add DTB compatible list to
> config file"):
> > From: Oleksandr Grytsov
> >
> > Some platforms need more compatible property values in device
> > tree root node in addition to "xen,xenvm-%d.%d" and "xen,xenvm"
> > values that are given by Xen by default.
> >>>
> >>> I am pretty sure I have seen this patch a few years ago, but I can't find
> >>> it
> >>> in my inbox. What is the exact problem here?
> >>>
> > Specify in domain configuration file which values should be added
> > by providing "dtb_compatible" list of strings separated by comas.
>
> Hi, thanks.
>
> I don't have an opinion about the principle of this and would like to
> hear from ARM folks about that.
>
> Also, Stefano, Julien: should we be asking for a freeze exception for
> this for 4.13 ?
> >>>
> >>> I don't have enough context to understand the exact issue he is trying to
> >>> solve.
> >>
> >> Same here. Is this patch needed because on some platform the OS checks
> >> for the platform "model" (also known as "machine name") on device tree
> >> before continuing or to trigger a difference behavior?
> >
> > Yes, exactly.
> >
> > I will redo the patch with Ian's comments if it is ok in general.
>
> By specifying a different compatible (let say "renesas,r8a774a1"), then you
> claim that your virtual machine is exactly the same as that board.
>
> This means, the OS is free to assume that the memory layout and all the
> devices
> are exactly the same. This is definitely not true as the virtual machine we
> expose is specific to Xen.
>
> So I don't think this is the correct approach here. Can you provide a
> real-life
> example on why you need this?
>
> Cheers,
>
> --
> Julien Grall
This is required for HW domains. Some drivers or initialization routines check
compatible. Below is example from linux kernel sources:
linux/sound/ppc/awacs.c:741:if (of_machine_is_compatible("PowerBook3,1")
linux/sound/ppc/awacs.c:742:||
of_machine_is_compatible("PowerBook3,2")) {
linux/sound/ppc/awacs.c:770:#define IS_PM7500
(of_machine_is_compatible("AAPL,7500") \
linux/sound/ppc/awacs.c:771:|| of_machine_is_compatible("AAPL,8500") \
linux/sound/ppc/awacs.c:772:|| of_machine_is_compatible("AAPL,9500"))
...
linux/arch/arm/mach-omap2/pdata-quirks.c:703:if
(of_machine_is_compatible(quirks->compatible)) {
linux/arch/arm/mach-omap2/pdata-quirks.c:717:if
(of_machine_is_compatible("ti,omap2420") ||
linux/arch/arm/mach-omap2/pdata-quirks.c:718:
of_machine_is_compatible("ti,omap3"))
linux/arch/arm/mach-omap2/pdata-quirks.c:721:if
(of_machine_is_compatible("ti,omap3"))
...
Also see [1]
[1]
https://source.codeaurora.org/external/imx/imx-xen/commit/?h=imx_4.14.98_2.0.0_ga=6e58d478203639e71da3da69ffeae3fa5dc0197b
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 142777: regressions - FAIL
flight 142777 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/142777/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 142750 test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 142750 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 142750 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 142750 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142750 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142750 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142750 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 142750 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142750 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 142750 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142750 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142750 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142750 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail 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-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-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-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 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-qemuu-win10-i386 10 windows-installfail 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-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass version targeted for testing: xen
Re: [Xen-devel] [XEN PATCH v1] libxl: Add DTB compatible list to config file
Hi Oleksandr,
On 16/10/2019 15:04, Oleksandr Grytsov wrote:
On Fri, Oct 11, 2019 at 8:21 PM Stefano Stabellini
wrote:
On Fri, 11 Oct 2019, Julien Grall wrote:
Hi,
On 11/10/2019 16:23, Ian Jackson wrote:
Oleksandr Grytsov writes ("[PATCH v1] libxl: Add DTB compatible list to
config file"):
From: Oleksandr Grytsov
Some platforms need more compatible property values in device
tree root node in addition to "xen,xenvm-%d.%d" and "xen,xenvm"
values that are given by Xen by default.
I am pretty sure I have seen this patch a few years ago, but I can't find it
in my inbox. What is the exact problem here?
Specify in domain configuration file which values should be added
by providing "dtb_compatible" list of strings separated by comas.
Hi, thanks.
I don't have an opinion about the principle of this and would like to
hear from ARM folks about that.
Also, Stefano, Julien: should we be asking for a freeze exception for
this for 4.13 ?
I don't have enough context to understand the exact issue he is trying to
solve.
Same here. Is this patch needed because on some platform the OS checks
for the platform "model" (also known as "machine name") on device tree
before continuing or to trigger a difference behavior?
Yes, exactly.
I will redo the patch with Ian's comments if it is ok in general.
By specifying a different compatible (let say "renesas,r8a774a1"), then you
claim that your virtual machine is exactly the same as that board.
This means, the OS is free to assume that the memory layout and all the devices
are exactly the same. This is definitely not true as the virtual machine we
expose is specific to Xen.
So I don't think this is the correct approach here. Can you provide a real-life
example on why you need this?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v1] libxl: Add DTB compatible list to config file
On Fri, Oct 11, 2019 at 8:21 PM Stefano Stabellini
wrote:
>
> On Fri, 11 Oct 2019, Julien Grall wrote:
> > Hi,
> >
> > On 11/10/2019 16:23, Ian Jackson wrote:
> > > Oleksandr Grytsov writes ("[PATCH v1] libxl: Add DTB compatible list to
> > > config file"):
> > > > From: Oleksandr Grytsov
> > > >
> > > > Some platforms need more compatible property values in device
> > > > tree root node in addition to "xen,xenvm-%d.%d" and "xen,xenvm"
> > > > values that are given by Xen by default.
> >
> > I am pretty sure I have seen this patch a few years ago, but I can't find it
> > in my inbox. What is the exact problem here?
> >
> > > > Specify in domain configuration file which values should be added
> > > > by providing "dtb_compatible" list of strings separated by comas.
> > >
> > > Hi, thanks.
> > >
> > > I don't have an opinion about the principle of this and would like to
> > > hear from ARM folks about that.
> > >
> > > Also, Stefano, Julien: should we be asking for a freeze exception for
> > > this for 4.13 ?
> >
> > I don't have enough context to understand the exact issue he is trying to
> > solve.
>
> Same here. Is this patch needed because on some platform the OS checks
> for the platform "model" (also known as "machine name") on device tree
> before continuing or to trigger a difference behavior?
Yes, exactly.
I will redo the patch with Ian's comments if it is ok in general.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Please Welcome Julien Grall as new Security Team Member
Dear Community members, I am pleased to announce that Julien Grallh has been nominated and voted to become a new member of the Xen Project security team. Julien has made significant contributions to the Xen Project over the years and has been a maintainer and project leadership team member for a long time. Best Regards Lars Kurth Xen Project Community Manager Chairman of Xen Project Advisory Board ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 1/2] libxl: introduce new backend type VINPUT
On Fri, Oct 11, 2019 at 8:04 PM Ian Jackson wrote:
>
> Oleksandr Grytsov writes ("Re: [PATCH v1 1/2] libxl: introduce new backend
> type VINPUT"):
> > On Fri, Oct 11, 2019 at 5:58 PM Ian Jackson wrote:
> > > I think it was a48e00f14a2d "libxl: add backend type and id to vkb"
> > > which introduced what you are calling "user space" backends. It
> > > appears that the vkb backend type enum was introduced there
> > > specifically to distinguish between these two situations. For reasons
> > >
> > > Am I wrong ? If not, why is this not working or not suitable ?
> >
> > You are right. It is not working in some cases due to QEMU_BACKEND macro.
> > QEMU_BACKEND treats both backends as QEMU. As result xl performs device
> > hotplug on add/remove device. Which is not expected in case "user
> > space" backend.
>
> Then perhaps this macro needs to be adjusted or called only
> conditionally or something ?
I had an idea to move this macro to libxl__device_type and let device
itself decides
if it is qemu backend. But in case of VKBD it will read XS to determine backend
type. I guess it is ok.
>
> > In this patch I propose solution similar to VUSB device. Where VUSB
> > used for frontend and depends on backend (kernel or QEMU) either
> > VUSB or QUSB used for backend device type e.g. use different backend
> > device type for different backends.
>
> I confess I don't quite follow all the VUSB stuff but I don't think it
> is necessarily a good model.
If you don't mind to move QEMU_BACKEND macrto to libxl__device_type then
no need to add new device type at all.
>
> > Introducing new backend device type for VKBD also allows to have
> > both backends (QEMU and non QEMU) run in same domain. Not sure if it
> > is useful scenario but with this proposal it is possible from
> > technical point of view.
>
> I don't understand why this is not possible simply by having a
> different backend type.
>
> > > I also don't understand why the "user space" kbd backend seems to be
> > > "linux" in the enum.
> >
> > I agree this is not so good name. But I don't know how to call
> > backends which are not running
> > inside QEMU in general.
>
> I think this would be useable on freebsd ? "linux" definitely seems
> wrong. I see it hasn't been in a release so it is not too late to
> rename it, subject to discussion with Juergen as RM.
>
> > > Where is the implementation of this user space
> > > backend ?
> >
> > We have extended kbd interface (kbdif.h) to support multi-touch events
> > as well. And we have
> > implemented own kbd backend https://github.com/xen-troops/displ_be/
> > It is integrated with display backend as both use wayland API.
>
> Great.
>
> > > Is it be controlled entirely through xenstore ?
> >
> > Yes it is controlled entirely through xenstore: lib xl creates
> > frontend/backend entries with
> > initial states and configuration.
>
> And your display backend in "troops" (is that the name of your
> project) checks whether the backend type is set to "linux", so that it
> knows to ignore ones that say "qemu" ?
>
> Maybe "linux" should be "troops"...
>
It doesn't look as generic solution. If some user implements own backend
it should add new entry into backend type enum.
What about to have just string value instead of enum? In case QEMU
we don't have such entry at all but in case custom backend the user
can't put any string value here to be recognized by his backend.
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early
Hi Julien, Sure. You should be able to find it on directnonmap-v2.3 branch at https://xenbits.xen.org/git-http/people/hx242/xen.git. Commit: a4fef31b99388524d3f7748967c5d04a924cb7e3 x86: add Persistent Map (PMAP) infrastructure One thing to note is that the PMAP structure is really low-performance because we do not want to burn too many fixmap entries. It should no longer be in use the moment we bootstrapped other mapping infrastructures. The only intention of it is to be able to map pages very early on. Hongyan On Wed, 2019-10-16 at 13:46 +0100, Julien Grall wrote: > Hi Hongyan, > > On 11/10/2019 10:53, Xia, Hongyan wrote: > > Not commenting on the patch, but I had exactly the same problem > > when > > removing the direct map in x86. map_domain_page has to be usable > > without the direct map and even before alloc_boot_pages can be used > > (so > > that I can map the bootmem_regions_list, although I have made it > > statically allocated now). > > > > The direct map teardown series in the end introduces a persistent > > mapping infrastructure to map page tables which occupies a few > > fixmap > > entries, and avoid set_fixmap but instead modify the entries > > directly > > to avoid invocation loops. The result is that map_xen_pagetable and > > map_domain_page is usable from the very beginning of start_xen. > > Would you mind to point to the patch adding the implementation on > x86? > > On arm32, we are not using a direct map. So we are using a per-cpu > mapping (see > map_domain_page() implementation in arch/arm/mm.c). > > On arm64, we are using the direct map so far. But we could use any of > the two > solutions if needed. > > Cheers, > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v1] Reset iomem's gfn to LIBXL_INVALID_GFN on reboot
On Mon, Oct 14, 2019 at 12:28 PM Julien Grall wrote:
>
> Hi Ian,
>
> On 11/10/2019 16:14, Ian Jackson wrote:
> > Oleksandr Grytsov writes ("[PATCH v1] Reset iomem's gfn to
> > LIBXL_INVALID_GFN on reboot"):
> >> During domain reboot its configuration is partially reused
> >> to re-create a new domain, but iomem's GFN field for the
> >> iomem is only restored for those memory ranges, which are
> >> configured in form of [IOMEM_START,NUM_PAGES[@GFN], but not for
> >> those in form of [IOMEM_START,NUM_PAGES], e.g. without GFN.
> >> For the latter GFN is reset to 0, but while mapping ranges
> >> to a domain during reboot there is a check that GFN treated
> >> as valid if it is not equal to LIBXL_INVALID_GFN, thus making
> >> Xen to map IOMEM_START to address 0 in the guest's address space.
> >>
> >> Workaround it by resseting GFN to LIBXL_INVALID_GFN, so xl
> >> can set proper values for mapping on reboot.
> >
> > Thanks for this patch.
> >
> > I confess that I am not sure what is going on here. Where is this
> > troublesome 0 coming from ? I see that the default value for gfn in
> > the struct is 0 and looking for assignments before this patch, gfn is
> > defaulted from b_info->iomem[i].start, which is presumably non-0.
> >
> > I suspect that your patch may be fixing this the wrong way. I have
> > addressed this mail to various people who have touched this area of
> > code and hope they will be able to clarify.
>
> I found a thread from December 2017 related to the problem described here [1].
>
> Looking at the thread, there were no conclusion on the root causes and some
> questions were left unanswered by the contributor (see [2]).
>
> Oleksandr, could you look at the thread and see if you can provide more
> details
> what's going on? Answering back here would be fine.
>
> >
> > BTW, please do ping this (and your other patches) by email, if the
> > conversation seems to stall.
> >
> > Thanks,
> > Ian.
> >
> >> Signed-off-by: Oleksandr Andrushchenko
> >> ---
> >> tools/libxl/libxl_domain.c | 9 +
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
> >> index 9d0eb5aed1..0ae16a5b12 100644
> >> --- a/tools/libxl/libxl_domain.c
> >> +++ b/tools/libxl/libxl_domain.c
> >> @@ -2120,6 +2120,15 @@ static void
> >> retrieve_domain_configuration_end(libxl__egc *egc,
> >> }
> >> }
> >>
> >> +/* reset IOMEM's GFN to initial value */
> >> +{
> >> +int i;
> >> +
> >> +for (i = 0; i < d_config->b_info.num_iomem; i++)
> >> +if (d_config->b_info.iomem[i].gfn == 0)
> >> +d_config->b_info.iomem[i].gfn = LIBXL_INVALID_GFN;
> >> +}
> >> +
> >> /* Devices: disk, nic, vtpm, pcidev etc. */
> >>
> >> /* The MERGE macro implements following logic:
> >> --
> >> 2.17.1
> >>
>
> Cheers,
>
> [1]
> [2] <20180213122432.h4fh22ej4dfe7...@citrix.com>
>
> --
> Julien Grall
Julien,
Thanks to point me out for this old thread. I completely forgot about it
(I haven't worked with xen since long time). I've performed additional
investigation
and found the root cause of the issue. It doesn't relate to iomem GFN directly.
The problem is in type from json parsing at place where libxl creates array of
struct.
For example, libxl_domain_config_from_json calls libxl_domain_config_init
which initializes all child structures and arrays. But then when libxl parses
json and creates the array of structure, it doesn't initialize array elements
properly (see libxl__domain_build_info_parse_json iomem parsing):
p->num_iomem = x->u.array->count;
p->iomem = libxl__calloc(NOGC, p->num_iomem, sizeof(*p->iomem));
if (!p->iomem && p->num_iomem != 0) {
rc = -1;
goto out;
}
for (i=0; (t=libxl__json_array_get(x,i)); i++) {
rc = libxl__iomem_range_parse_json(gc, t, >iomem[i]);
if (rc)
goto out;
}
libxl creates array element with calloc function, so all element
fields are initialized
with zero values. Even some of them have default value different from zero.
For these purpose dedicated init function should be called for each element.
Above example should be:
for (i=0; (t=libxl__json_array_get(x,i)); i++) {
libxl_iomem_range_init(>iomem[i]);
rc = libxl__iomem_range_parse_json(gc, t, >iomem[i]);
if (rc)
goto out;
}
I've changes gentypes.py as following:
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index 88e5c5f30e..92e28be469 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -454,6 +454,8 @@ def libxl_C_type_parse_json(ty, w, v, indent = "
", parent = None, discrimina
s += "goto out;\n"
s += "}\n"
s += "for (i=0; (t=libxl__json_array_get(x,i)); i++) {\n"
+if ty.elem_type.init_fn is not None and
ty.elem_type.autogenerate_init_fn:
+s += indent + ""+"%s_init(&%s[i]);\n" %
(ty.elem_type.typename, v)
s += libxl_C_type_parse_json(ty.elem_type, "t", v+"[i]",
Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early
Hi Hongyan, On 11/10/2019 10:53, Xia, Hongyan wrote: Not commenting on the patch, but I had exactly the same problem when removing the direct map in x86. map_domain_page has to be usable without the direct map and even before alloc_boot_pages can be used (so that I can map the bootmem_regions_list, although I have made it statically allocated now). The direct map teardown series in the end introduces a persistent mapping infrastructure to map page tables which occupies a few fixmap entries, and avoid set_fixmap but instead modify the entries directly to avoid invocation loops. The result is that map_xen_pagetable and map_domain_page is usable from the very beginning of start_xen. Would you mind to point to the patch adding the implementation on x86? On arm32, we are not using a direct map. So we are using a per-cpu mapping (see map_domain_page() implementation in arch/arm/mm.c). On arm64, we are using the direct map so far. But we could use any of the two solutions if needed. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-coverity test] 142802: all pass - PUSHED
flight 142802 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/142802/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 55ab292c42db41b05cfdba012680bf1e0ea02f7a baseline version: xen fef8d99fbce1a5e7ddfd22b0f33940b8d6193ec8 Last test of basis 142698 2019-10-13 09:18:44 Z3 days Testing same since 142802 2019-10-16 09:18:55 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Ian Jackson Jan Beulich Olaf Hering 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 fef8d99fbc..55ab292c42 55ab292c42db41b05cfdba012680bf1e0ea02f7a -> coverity-tested/smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 27/32] hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers
On Tue, 15 Oct 2019 at 17:34, Philippe Mathieu-Daudé wrote:
>
> The IRQ Route Control registers definitions belong to the PIIX
> chipset. We were only defining the 'A' register. Define the other
> B, C and D registers, and use them.
>
> Signed-off-by: Philippe Mathieu-Daudé
Xen change...
Acked-by: Paul Durrant
> ---
> hw/i386/xen/xen-hvm.c | 5 +++--
> hw/mips/gt64xxx_pci.c | 4 ++--
> hw/pci-host/piix.c| 9 -
> include/hw/southbridge/piix.h | 6 ++
> 4 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index 6b5e5bb7f5..4ce2fb9c89 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -14,6 +14,7 @@
> #include "hw/pci/pci.h"
> #include "hw/pci/pci_host.h"
> #include "hw/i386/pc.h"
> +#include "hw/southbridge/piix.h"
> #include "hw/irq.h"
> #include "hw/hw.h"
> #include "hw/i386/apic-msidef.h"
> @@ -156,8 +157,8 @@ void xen_piix_pci_write_config_client(uint32_t address,
> uint32_t val, int len)
> v = 0;
> }
> v &= 0xf;
> -if (((address + i) >= 0x60) && ((address + i) <= 0x63)) {
> -xen_set_pci_link_route(xen_domid, address + i - 0x60, v);
> +if (((address + i) >= PIIX_PIRQCA) && ((address + i) <=
> PIIX_PIRQCD)) {
> +xen_set_pci_link_route(xen_domid, address + i - PIIX_PIRQCA, v);
> }
> }
> }
> diff --git a/hw/mips/gt64xxx_pci.c b/hw/mips/gt64xxx_pci.c
> index c277398c0d..5cab9c1ee1 100644
> --- a/hw/mips/gt64xxx_pci.c
> +++ b/hw/mips/gt64xxx_pci.c
> @@ -1013,12 +1013,12 @@ static void gt64120_pci_set_irq(void *opaque, int
> irq_num, int level)
>
> /* now we change the pic irq level according to the piix irq mappings */
> /* XXX: optimize */
> -pic_irq = piix4_dev->config[0x60 + irq_num];
> +pic_irq = piix4_dev->config[PIIX_PIRQCA + irq_num];
> if (pic_irq < 16) {
> /* The pic level is the logical OR of all the PCI irqs mapped to it.
> */
> pic_level = 0;
> for (i = 0; i < 4; i++) {
> -if (pic_irq == piix4_dev->config[0x60 + i]) {
> +if (pic_irq == piix4_dev->config[PIIX_PIRQCA + i]) {
> pic_level |= pci_irq_levels[i];
> }
> }
> diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> index 3770575c1a..a450fc726e 100644
> --- a/hw/pci-host/piix.c
> +++ b/hw/pci-host/piix.c
> @@ -61,7 +61,6 @@ typedef struct I440FXState {
> #define PIIX_NUM_PIC_IRQS 16 /* i8259 * 2 */
> #define PIIX_NUM_PIRQS 4ULL/* PIRQ[A-D] */
> #define XEN_PIIX_NUM_PIRQS 128ULL
> -#define PIIX_PIRQC 0x60
>
> typedef struct PIIX3State {
> PCIDevice dev;
> @@ -468,7 +467,7 @@ static void piix3_set_irq_level_internal(PIIX3State
> *piix3, int pirq, int level)
> int pic_irq;
> uint64_t mask;
>
> -pic_irq = piix3->dev.config[PIIX_PIRQC + pirq];
> +pic_irq = piix3->dev.config[PIIX_PIRQCA + pirq];
> if (pic_irq >= PIIX_NUM_PIC_IRQS) {
> return;
> }
> @@ -482,7 +481,7 @@ static void piix3_set_irq_level(PIIX3State *piix3, int
> pirq, int level)
> {
> int pic_irq;
>
> -pic_irq = piix3->dev.config[PIIX_PIRQC + pirq];
> +pic_irq = piix3->dev.config[PIIX_PIRQCA + pirq];
> if (pic_irq >= PIIX_NUM_PIC_IRQS) {
> return;
> }
> @@ -501,7 +500,7 @@ static void piix3_set_irq(void *opaque, int pirq, int
> level)
> static PCIINTxRoute piix3_route_intx_pin_to_irq(void *opaque, int pin)
> {
> PIIX3State *piix3 = opaque;
> -int irq = piix3->dev.config[PIIX_PIRQC + pin];
> +int irq = piix3->dev.config[PIIX_PIRQCA + pin];
> PCIINTxRoute route;
>
> if (irq < PIIX_NUM_PIC_IRQS) {
> @@ -530,7 +529,7 @@ static void piix3_write_config(PCIDevice *dev,
> uint32_t address, uint32_t val, int len)
> {
> pci_default_write_config(dev, address, val, len);
> -if (ranges_overlap(address, len, PIIX_PIRQC, 4)) {
> +if (ranges_overlap(address, len, PIIX_PIRQCA, 4)) {
> PIIX3State *piix3 = PIIX3_PCI_DEVICE(dev);
> int pic_irq;
>
> diff --git a/include/hw/southbridge/piix.h b/include/hw/southbridge/piix.h
> index 79ebe0089b..9c92c37a4d 100644
> --- a/include/hw/southbridge/piix.h
> +++ b/include/hw/southbridge/piix.h
> @@ -18,6 +18,12 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t
> smb_io_base,
>qemu_irq sci_irq, qemu_irq smi_irq,
>int smm_enabled, DeviceState **piix4_pm);
>
> +/* PIRQRC[A:D]: PIRQx Route Control Registers */
> +#define PIIX_PIRQCA 0x60
> +#define PIIX_PIRQCB 0x61
> +#define PIIX_PIRQCC 0x62
> +#define PIIX_PIRQCD 0x63
> +
> /*
> * Reset Control Register: PCI-accessible ISA-Compatible Register at address
> * 0xcf9, provided by the PCI/ISA bridge (PIIX3 PCI function 0, 8086:7000).
> --
> 2.21.0
>
___
Xen-devel mailing list
Re: [Xen-devel] [RESEND][PATCH for-4.13] xen/arm: mm: Clear boot pagetables before bringing-up each secondary CPU
On 16.10.19 13:19, Julien Grall wrote: Hi, Argh forgot again. Maybe the 3rd will be better? Yes! You made it! ;-) Sorry for the noise. Cheers, On 15/10/2019 17:36, Julien Grall wrote: Hi, I actually forgot to CC Juergen. No wonder why I had no answer :(. Cheers, On 10/10/19 3:51 PM, Julien Grall wrote: +Juergen On 03/10/2019 02:22, Stefano Stabellini wrote: On Sat, 21 Sep 2019, Julien Grall wrote: At the moment, boot pagetables are only cleared once at boot. This means when booting CPU2 (and onwards) then boot pagetables will not be cleared. To keep the interface exactly the same for all secondary CPU, the boot pagetables are now cleared before bringing-up each secondary CPU. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RESEND][PATCH for-4.13] xen/arm: mm: Clear boot pagetables before bringing-up each secondary CPU
Hi,
Argh forgot again. Maybe the 3rd will be better?
Sorry for the noise.
Cheers,
On 15/10/2019 17:36, Julien Grall wrote:
Hi,
I actually forgot to CC Juergen. No wonder why I had no answer :(.
Cheers,
On 10/10/19 3:51 PM, Julien Grall wrote:
+Juergen
On 03/10/2019 02:22, Stefano Stabellini wrote:
On Sat, 21 Sep 2019, Julien Grall wrote:
At the moment, boot pagetables are only cleared once at boot. This means
when booting CPU2 (and onwards) then boot pagetables will not be
cleared.
To keep the interface exactly the same for all secondary CPU, the boot
pagetables are now cleared before bringing-up each secondary CPU.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
xen/arch/arm/mm.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 1129dc28c8..e14ee76ff8 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -704,8 +704,20 @@ void __init setup_pagetables(unsigned long
boot_phys_offset)
switch_ttbr(ttbr);
- /* Clear the copy of the boot pagetables. Each secondary CPU
- * rebuilds these itself (see head.S) */
+ xen_pt_enforce_wnx();
+
+#ifdef CONFIG_ARM_32
+ per_cpu(xen_pgtable, 0) = cpu0_pgtable;
+ per_cpu(xen_dommap, 0) = cpu0_dommap;
+#endif
+}
+
+static void clear_boot_pagetables(void)
+{
+ /*
+ * Clear the copy of the boot pagetables. Each secondary CPU
+ * rebuilds these itself (see head.S)
+ */
clear_table(boot_pgtable);
#ifdef CONFIG_ARM_64
clear_table(boot_first);
@@ -713,18 +725,13 @@ void __init setup_pagetables(unsigned long
boot_phys_offset)
#endif
clear_table(boot_second);
clear_table(boot_third);
-
- xen_pt_enforce_wnx();
-
-#ifdef CONFIG_ARM_32
- per_cpu(xen_pgtable, 0) = cpu0_pgtable;
- per_cpu(xen_dommap, 0) = cpu0_dommap;
-#endif
}
#ifdef CONFIG_ARM_64
int init_secondary_pagetables(int cpu)
{
+ clear_boot_pagetables();
+
/* Set init_ttbr for this CPU coming up. All CPus share a single setof
* pagetables, but rewrite it each time for consistency with 32 bit. */
init_ttbr = (uintptr_t) xen_pgtable + phys_offset;
@@ -767,6 +774,8 @@ int init_secondary_pagetables(int cpu)
per_cpu(xen_pgtable, cpu) = first;
per_cpu(xen_dommap, cpu) = domheap;
+ clear_boot_pagetables();
+
/* Set init_ttbr for this CPU coming up */
init_ttbr = __pa(first);
clean_dcache(init_ttbr);
--
2.11.0
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: setup: Calculate correctly the size of Xen
On 16.10.19 13:12, Julien Grall wrote: The current size of Xen is computed using _end - _start + 1. However, _end is pointing one past the end of Xen, so the size of Xen is off-by-one. Signed-off-by: Julien Grall Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.13] xen/arm: setup: Calculate correctly the size of Xen
The current size of Xen is computed using _end - _start + 1. However, _end is pointing one past the end of Xen, so the size of Xen is off-by-one. Signed-off-by: Julien Grall --- xen/arch/arm/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 705a917abf..51d32106b7 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -819,7 +819,7 @@ void __init start_xen(unsigned long boot_phys_offset, /* Register Xen's load address as a boot module. */ xen_bootmodule = add_boot_module(BOOTMOD_XEN, (paddr_t)(uintptr_t)(_start + boot_phys_offset), - (paddr_t)(uintptr_t)(_end - _start + 1), false); + (paddr_t)(uintptr_t)(_end - _start), false); BUG_ON(!xen_bootmodule); fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr); -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 0/3] x86/boot: Introduce the kernel_info et consortes
On Wed, Oct 09, 2019 at 12:53:55PM +0200, Daniel Kiper wrote: > Hi, > > Due to very limited space in the setup_header this patch series introduces new > kernel_info struct which will be used to convey information from the kernel to > the bootloader. This way the boot protocol can be extended regardless of the > setup_header limitations. Additionally, the patch series introduces some > convenience features like the setup_indirect struct and the > kernel_info.setup_type_max field. > > Daniel > > Documentation/x86/boot.rst | 168 > ++ > arch/x86/boot/Makefile | 2 +- > arch/x86/boot/compressed/Makefile | 4 +- > arch/x86/boot/compressed/kaslr.c | 12 ++ > arch/x86/boot/compressed/kernel_info.S | 22 +++ > arch/x86/boot/header.S | 3 +- > arch/x86/boot/tools/build.c| 5 +++ > arch/x86/include/uapi/asm/bootparam.h | 16 +++- > arch/x86/kernel/e820.c | 11 ++ > arch/x86/kernel/kdebugfs.c | 20 -- > arch/x86/kernel/ksysfs.c | 30 ++ > arch/x86/kernel/setup.c| 4 ++ > arch/x86/mm/ioremap.c | 11 ++ > 13 files changed, 292 insertions(+), 16 deletions(-) > > Daniel Kiper (3): > x86/boot: Introduce the kernel_info > x86/boot: Introduce the kernel_info.setup_type_max > x86/boot: Introduce the setup_indirect hpa, ping? Daniel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.13 v2] xen/arm: Don't use _end in is_xen_fixed_mfn()
virt_to_maddr() is using the hardware page-table walk instructions to translate a virtual address to physical address. The function should only be called on virtual address mapped. _end points past the end of Xen binary and may not be mapped when the binary size is page-aligned. This means virt_to_maddr() will not be able to do the translation and therefore crash Xen. Note there is also an off-by-one issue in this code, but the panic will trump that. Both issues can be fixed by using _end - 1 in the check. Signed-off-by: Julien Grall Release-acked-by: Juergen Gross --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu x86 seems to be affected by the off-by-one issue. Jan, Andrew? This could be reached by a domain via XEN_SYSCTL_page_offline_op. However, the operation is not security supported (see XSA-77). So we are fine here. Changes in v2: - Cast _end to vaddr_t to prevent UB. - Add Juergen's released-acked-by --- xen/include/asm-arm/mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h index 262d92f18d..333efd3a60 100644 --- a/xen/include/asm-arm/mm.h +++ b/xen/include/asm-arm/mm.h @@ -153,7 +153,7 @@ extern unsigned long xenheap_base_pdx; #define is_xen_fixed_mfn(mfn) \ ((mfn_to_maddr(mfn) >= virt_to_maddr(&_start)) && \ - (mfn_to_maddr(mfn) <= virt_to_maddr(&_end))) + (mfn_to_maddr(mfn) <= virt_to_maddr((vaddr_t)_end - 1))) #define page_get_owner(_p)(_p)->v.inuse.domain #define page_set_owner(_p,_d) ((_p)->v.inuse.domain = (_d)) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
Hi,
On 16/10/2019 11:18, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [PATCH for-4.13] xen/arm: Don't use _end in
is_xen_fixed_mfn()"):
My suggestion is going to work: "the compiler sees through casts"
referred to comparisons between pointers, where we temporarily casted
both pointers to integers and back to pointers via a MACRO. That case
was iffy because the MACRO was clearly a workaround the spec.
Here the situation is different. For one, we are doing arithmetic. Also
virt_to_maddr already takes a vaddr_t as argument. So instead of doing
pointers arithmetic, then converting to vaddr_t, we are converting to
vaddr_t first, then doing arithmetics, which is fine both from a C99
point of view and even a MISRA C point of view. I can't see a problem
with that. I am sure as I reasonable can be :-)
FTAOD I think you are suggesting this:
- + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1)))
+ + (mfn_to_maddr(mfn) <= virt_to_maddr(((vaddr_t)_end - 1)))
virt_to_maddr(va) is a macro which expands to
__virt_to_maddr((vaddr_t)(va))
So what is happening here is that the cast to an integer type is being
done before the subtraction.
Without the cast, you are calculating the pointer value _end-1 from
the value _end, which is UB. With the cast you are calculating an
integer value. vaddr_t is unsigned, so all arithmetic operations are
defined. Nothing casts the result back to the "forbidden" (with this
provenance) pointer value, so all is well.
(With the macro expansion the cast happens twice. This is probably
better than using __virt_to_maddr here.)
Ie, in this case I agree with Stefano. The cast is both necessary and
sufficient.
Thank you both for the explanation. I will update the patch and resend it.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
On 10/16/19 11:41 AM, Jürgen Groß wrote:
> On 16.10.19 12:38, George Dunlap wrote:
>> On 10/16/19 11:31 AM, Julien Grall wrote:
>>> Hi George,
>>>
>>> On 16/10/2019 11:22, George Dunlap wrote:
On 10/16/19 11:18 AM, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH for-4.13] xen/arm: Don't use
> _end in is_xen_fixed_mfn()"):
>> My suggestion is going to work: "the compiler sees through casts"
>> referred to comparisons between pointers, where we temporarily casted
>> both pointers to integers and back to pointers via a MACRO. That case
>> was iffy because the MACRO was clearly a workaround the spec.
>>
>> Here the situation is different. For one, we are doing arithmetic.
>> Also
>> virt_to_maddr already takes a vaddr_t as argument. So instead of
>> doing
>> pointers arithmetic, then converting to vaddr_t, we are converting to
>> vaddr_t first, then doing arithmetics, which is fine both from a C99
>> point of view and even a MISRA C point of view. I can't see a problem
>> with that. I am sure as I reasonable can be :-)
>
> FTAOD I think you are suggesting this:
> - + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1)))
> + + (mfn_to_maddr(mfn) <= virt_to_maddr(((vaddr_t)_end - 1)))
>
> virt_to_maddr(va) is a macro which expands to
> __virt_to_maddr((vaddr_t)(va))
>
> So what is happening here is that the cast to an integer type is being
> done before the subtraction.
>
> Without the cast, you are calculating the pointer value _end-1 from
> the value _end, which is UB. With the cast you are calculating an
> integer value. vaddr_t is unsigned, so all arithmetic operations are
> defined. Nothing casts the result back to the "forbidden" (with this
> provenance) pointer value, so all is well.
>
> (With the macro expansion the cast happens twice. This is probably
> better than using __virt_to_maddr here.)
>
> Ie, in this case I agree with Stefano. The cast is both necessary and
> sufficient.
Maybe I missed something, but why are we using `<=` at all? Why not
use
`<`?
Or is this some weird C pointer comparison UB thing?
>>>
>>> _end may not be mapped in the virtual address space. This is the case
>>> when the size of Xen is page-aligned. So _end will point to the next
>>> page.
>>>
>>> virt_to_maddr() cannot fail so it should only be called on valid virtual
>>> address. The behavior is undefined in all the other cases.
>>>
>>> On x86, you might be able to get away because you translate the virtual
>>> address to physical address in software.
>>>
>>> On Arm, we are using the hardware instruction to do the translation. As
>>> _end is not always mapped, then the translation may fail. In other word,
>>> Xen will crash.
>>
>> None of this explains my question.
>>
>> Is it not the case that if `mfn_to_maddr(mfn) <= virt_to_maddr(_end-1)`
>> is true, then `mfn_to_maddr(mfn) < virt_to_maddr(_end)` will be true,
>> and that if `mfn_to_maddr(mfn) <= virt_to_maddr(_end-1)` is false, then
>> `mfn_to_maddr(mfn) < virt_to_maddr(_end)` will also be false?
>>
>> Under what conditions would they be different?
>
> In case virt_to_maddr(_end) is undefined due to no translation being
> available?
Ah, gotcha. Sorry for the noise.
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
Hi George,
On 16/10/2019 11:38, George Dunlap wrote:
On 10/16/19 11:31 AM, Julien Grall wrote:
On 16/10/2019 11:22, George Dunlap wrote:
On 10/16/19 11:18 AM, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [PATCH for-4.13] xen/arm: Don't use
_end in is_xen_fixed_mfn()"):
My suggestion is going to work: "the compiler sees through casts"
referred to comparisons between pointers, where we temporarily casted
both pointers to integers and back to pointers via a MACRO. That case
was iffy because the MACRO was clearly a workaround the spec.
Here the situation is different. For one, we are doing arithmetic. Also
virt_to_maddr already takes a vaddr_t as argument. So instead of doing
pointers arithmetic, then converting to vaddr_t, we are converting to
vaddr_t first, then doing arithmetics, which is fine both from a C99
point of view and even a MISRA C point of view. I can't see a problem
with that. I am sure as I reasonable can be :-)
FTAOD I think you are suggesting this:
- + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1)))
+ + (mfn_to_maddr(mfn) <= virt_to_maddr(((vaddr_t)_end - 1)))
virt_to_maddr(va) is a macro which expands to
__virt_to_maddr((vaddr_t)(va))
So what is happening here is that the cast to an integer type is being
done before the subtraction.
Without the cast, you are calculating the pointer value _end-1 from
the value _end, which is UB. With the cast you are calculating an
integer value. vaddr_t is unsigned, so all arithmetic operations are
defined. Nothing casts the result back to the "forbidden" (with this
provenance) pointer value, so all is well.
(With the macro expansion the cast happens twice. This is probably
better than using __virt_to_maddr here.)
Ie, in this case I agree with Stefano. The cast is both necessary and
sufficient.
Maybe I missed something, but why are we using `<=` at all? Why not use
`<`?
Or is this some weird C pointer comparison UB thing?
_end may not be mapped in the virtual address space. This is the case
when the size of Xen is page-aligned. So _end will point to the next page.
virt_to_maddr() cannot fail so it should only be called on valid virtual
address. The behavior is undefined in all the other cases.
On x86, you might be able to get away because you translate the virtual
address to physical address in software.
On Arm, we are using the hardware instruction to do the translation. As
_end is not always mapped, then the translation may fail. In other word,
Xen will crash.
None of this explains my question.
Is it not the case that if `mfn_to_maddr(mfn) <= virt_to_maddr(_end-1)`
is true, then `mfn_to_maddr(mfn) < virt_to_maddr(_end)` will be true,
and that if `mfn_to_maddr(mfn) <= virt_to_maddr(_end-1)` is false, then
`mfn_to_maddr(mfn) < virt_to_maddr(_end)` will also be false?
Under what conditions would they be different?
And if they're the same, then you can just use `<` instead of `<=`, and
not have to worry about casting before subtracting.
_end is not part of the binary but points one past it. So there is no guarantee
this address will be mapped in the virtual address space.
As I pointed out in my previous e-mail the result of virt_to_maddr() will be
undefined in this case. On Arm, this will actually crash Xen.
So you can't use '<' here.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
On 16.10.19 12:38, George Dunlap wrote:
On 10/16/19 11:31 AM, Julien Grall wrote:
Hi George,
On 16/10/2019 11:22, George Dunlap wrote:
On 10/16/19 11:18 AM, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [PATCH for-4.13] xen/arm: Don't use
_end in is_xen_fixed_mfn()"):
My suggestion is going to work: "the compiler sees through casts"
referred to comparisons between pointers, where we temporarily casted
both pointers to integers and back to pointers via a MACRO. That case
was iffy because the MACRO was clearly a workaround the spec.
Here the situation is different. For one, we are doing arithmetic. Also
virt_to_maddr already takes a vaddr_t as argument. So instead of doing
pointers arithmetic, then converting to vaddr_t, we are converting to
vaddr_t first, then doing arithmetics, which is fine both from a C99
point of view and even a MISRA C point of view. I can't see a problem
with that. I am sure as I reasonable can be :-)
FTAOD I think you are suggesting this:
- + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1)))
+ + (mfn_to_maddr(mfn) <= virt_to_maddr(((vaddr_t)_end - 1)))
virt_to_maddr(va) is a macro which expands to
__virt_to_maddr((vaddr_t)(va))
So what is happening here is that the cast to an integer type is being
done before the subtraction.
Without the cast, you are calculating the pointer value _end-1 from
the value _end, which is UB. With the cast you are calculating an
integer value. vaddr_t is unsigned, so all arithmetic operations are
defined. Nothing casts the result back to the "forbidden" (with this
provenance) pointer value, so all is well.
(With the macro expansion the cast happens twice. This is probably
better than using __virt_to_maddr here.)
Ie, in this case I agree with Stefano. The cast is both necessary and
sufficient.
Maybe I missed something, but why are we using `<=` at all? Why not use
`<`?
Or is this some weird C pointer comparison UB thing?
_end may not be mapped in the virtual address space. This is the case
when the size of Xen is page-aligned. So _end will point to the next page.
virt_to_maddr() cannot fail so it should only be called on valid virtual
address. The behavior is undefined in all the other cases.
On x86, you might be able to get away because you translate the virtual
address to physical address in software.
On Arm, we are using the hardware instruction to do the translation. As
_end is not always mapped, then the translation may fail. In other word,
Xen will crash.
None of this explains my question.
Is it not the case that if `mfn_to_maddr(mfn) <= virt_to_maddr(_end-1)`
is true, then `mfn_to_maddr(mfn) < virt_to_maddr(_end)` will be true,
and that if `mfn_to_maddr(mfn) <= virt_to_maddr(_end-1)` is false, then
`mfn_to_maddr(mfn) < virt_to_maddr(_end)` will also be false?
Under what conditions would they be different?
In case virt_to_maddr(_end) is undefined due to no translation being
available?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 2/2] libxl: add removing XS backend path for PV devices on domain destroy
On Tue, Oct 15, 2019 at 6:39 PM Roger Pau Monné wrote:
>
> On Fri, Oct 11, 2019 at 04:55:32PM +0100, Ian Jackson wrote:
> > Roger Pau Monne writes ("Re: [PATCH v1 2/2] libxl: add removing XS backend
> > path for PV devices on domain destroy"):
> > > When this code was added (devd) those where the only backends handled
> > > by libxl. VDISPL, VSND, VINPUT didn't exist at that point, so I think
> > > the issue is that when support for those was added, it wasn't properly
> > > wired into devd.
> > >
> > > > I think:
> > > >
> > > > > switch(ddev->dev->backend_kind) {
> > > > > +case LIBXL__DEVICE_KIND_VDISPL:
> > > > > +case LIBXL__DEVICE_KIND_VSND:
> > > > > +case LIBXL__DEVICE_KIND_VINPUT:
> > > > > case LIBXL__DEVICE_KIND_VBD:
> > > > > case LIBXL__DEVICE_KIND_VIF:
> > > >
> > > > If we do want this to handle *all* kinds of device, maybe it should
> > > > have a fallback that aborts, or something ? (I don't think it is
> > > > easy to make it a compile error to forget to add an entry here but if
> > > > we could do that it would probably be best.)
> > >
> > > Maybe we could have some generic handling for everything != qdisk?
> >
> > So make that the "default:" ? That would be fine by me.
>
> If possible yes, that would be my preference, and would prevent having
> to add new device types to this switch unless special handling is
> required.
>
> >
> > > IIRC qdisk needs special handling so that devd can launch and destroy
> > > a QEMU instance when required, but other backends that run in the
> > > kernel don't need such handling and could maybe share the same generic
> > > code path.
> >
> > Right.
> >
> > > > All of that assuming that the basic idea is right, which I would like
> > > > Roger's opinion about.
> > >
> > > Looking at the patch itself, you also seem to be doing some changes
> > > related to num_vbds and num_vifs, but those are not mentioned in the
> > > commit message, is that a stray change?
> >
> > No, I don't think so. Those variables just tell us when the thing is
> > torn down but Oleksandr's code is able to use the devices slist itself
> > for that. Please do check to see if you agree.
>
> Yes, that's fine. I don't think those changes are wrong, I just think
> that at least they should be mentioned in the commit message. Ie:
> "while there remove the num_vifs and num_vbds since they are not
> needed and the same can be achieved by checking that the device list
> is empty." or some such.
>
> Thanks, Roger.
Ian, Roger,
Thanks for reviewing and comments. I will update the patch with your
comments above.
--
Best Regards,
Oleksandr Grytsov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
On 10/16/19 11:31 AM, Julien Grall wrote:
> Hi George,
>
> On 16/10/2019 11:22, George Dunlap wrote:
>> On 10/16/19 11:18 AM, Ian Jackson wrote:
>>> Stefano Stabellini writes ("Re: [PATCH for-4.13] xen/arm: Don't use
>>> _end in is_xen_fixed_mfn()"):
My suggestion is going to work: "the compiler sees through casts"
referred to comparisons between pointers, where we temporarily casted
both pointers to integers and back to pointers via a MACRO. That case
was iffy because the MACRO was clearly a workaround the spec.
Here the situation is different. For one, we are doing arithmetic. Also
virt_to_maddr already takes a vaddr_t as argument. So instead of doing
pointers arithmetic, then converting to vaddr_t, we are converting to
vaddr_t first, then doing arithmetics, which is fine both from a C99
point of view and even a MISRA C point of view. I can't see a problem
with that. I am sure as I reasonable can be :-)
>>>
>>> FTAOD I think you are suggesting this:
>>> - + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1)))
>>> + + (mfn_to_maddr(mfn) <= virt_to_maddr(((vaddr_t)_end - 1)))
>>>
>>> virt_to_maddr(va) is a macro which expands to
>>> __virt_to_maddr((vaddr_t)(va))
>>>
>>> So what is happening here is that the cast to an integer type is being
>>> done before the subtraction.
>>>
>>> Without the cast, you are calculating the pointer value _end-1 from
>>> the value _end, which is UB. With the cast you are calculating an
>>> integer value. vaddr_t is unsigned, so all arithmetic operations are
>>> defined. Nothing casts the result back to the "forbidden" (with this
>>> provenance) pointer value, so all is well.
>>>
>>> (With the macro expansion the cast happens twice. This is probably
>>> better than using __virt_to_maddr here.)
>>>
>>> Ie, in this case I agree with Stefano. The cast is both necessary and
>>> sufficient.
>>
>> Maybe I missed something, but why are we using `<=` at all? Why not use
>> `<`?
>>
>> Or is this some weird C pointer comparison UB thing?
>
> _end may not be mapped in the virtual address space. This is the case
> when the size of Xen is page-aligned. So _end will point to the next page.
>
> virt_to_maddr() cannot fail so it should only be called on valid virtual
> address. The behavior is undefined in all the other cases.
>
> On x86, you might be able to get away because you translate the virtual
> address to physical address in software.
>
> On Arm, we are using the hardware instruction to do the translation. As
> _end is not always mapped, then the translation may fail. In other word,
> Xen will crash.
None of this explains my question.
Is it not the case that if `mfn_to_maddr(mfn) <= virt_to_maddr(_end-1)`
is true, then `mfn_to_maddr(mfn) < virt_to_maddr(_end)` will be true,
and that if `mfn_to_maddr(mfn) <= virt_to_maddr(_end-1)` is false, then
`mfn_to_maddr(mfn) < virt_to_maddr(_end)` will also be false?
Under what conditions would they be different?
And if they're the same, then you can just use `<` instead of `<=`, and
not have to worry about casting before subtracting.
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
Hi George,
On 16/10/2019 11:22, George Dunlap wrote:
On 10/16/19 11:18 AM, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [PATCH for-4.13] xen/arm: Don't use _end in
is_xen_fixed_mfn()"):
My suggestion is going to work: "the compiler sees through casts"
referred to comparisons between pointers, where we temporarily casted
both pointers to integers and back to pointers via a MACRO. That case
was iffy because the MACRO was clearly a workaround the spec.
Here the situation is different. For one, we are doing arithmetic. Also
virt_to_maddr already takes a vaddr_t as argument. So instead of doing
pointers arithmetic, then converting to vaddr_t, we are converting to
vaddr_t first, then doing arithmetics, which is fine both from a C99
point of view and even a MISRA C point of view. I can't see a problem
with that. I am sure as I reasonable can be :-)
FTAOD I think you are suggesting this:
- + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1)))
+ + (mfn_to_maddr(mfn) <= virt_to_maddr(((vaddr_t)_end - 1)))
virt_to_maddr(va) is a macro which expands to
__virt_to_maddr((vaddr_t)(va))
So what is happening here is that the cast to an integer type is being
done before the subtraction.
Without the cast, you are calculating the pointer value _end-1 from
the value _end, which is UB. With the cast you are calculating an
integer value. vaddr_t is unsigned, so all arithmetic operations are
defined. Nothing casts the result back to the "forbidden" (with this
provenance) pointer value, so all is well.
(With the macro expansion the cast happens twice. This is probably
better than using __virt_to_maddr here.)
Ie, in this case I agree with Stefano. The cast is both necessary and
sufficient.
Maybe I missed something, but why are we using `<=` at all? Why not use
`<`?
Or is this some weird C pointer comparison UB thing?
_end may not be mapped in the virtual address space. This is the case when the
size of Xen is page-aligned. So _end will point to the next page.
virt_to_maddr() cannot fail so it should only be called on valid virtual
address. The behavior is undefined in all the other cases.
On x86, you might be able to get away because you translate the virtual address
to physical address in software.
On Arm, we are using the hardware instruction to do the translation. As _end is
not always mapped, then the translation may fail. In other word, Xen will crash.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
On 10/16/19 11:18 AM, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH for-4.13] xen/arm: Don't use _end in
> is_xen_fixed_mfn()"):
>> My suggestion is going to work: "the compiler sees through casts"
>> referred to comparisons between pointers, where we temporarily casted
>> both pointers to integers and back to pointers via a MACRO. That case
>> was iffy because the MACRO was clearly a workaround the spec.
>>
>> Here the situation is different. For one, we are doing arithmetic. Also
>> virt_to_maddr already takes a vaddr_t as argument. So instead of doing
>> pointers arithmetic, then converting to vaddr_t, we are converting to
>> vaddr_t first, then doing arithmetics, which is fine both from a C99
>> point of view and even a MISRA C point of view. I can't see a problem
>> with that. I am sure as I reasonable can be :-)
>
> FTAOD I think you are suggesting this:
> - + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1)))
> + + (mfn_to_maddr(mfn) <= virt_to_maddr(((vaddr_t)_end - 1)))
>
> virt_to_maddr(va) is a macro which expands to
>__virt_to_maddr((vaddr_t)(va))
>
> So what is happening here is that the cast to an integer type is being
> done before the subtraction.
>
> Without the cast, you are calculating the pointer value _end-1 from
> the value _end, which is UB. With the cast you are calculating an
> integer value. vaddr_t is unsigned, so all arithmetic operations are
> defined. Nothing casts the result back to the "forbidden" (with this
> provenance) pointer value, so all is well.
>
> (With the macro expansion the cast happens twice. This is probably
> better than using __virt_to_maddr here.)
>
> Ie, in this case I agree with Stefano. The cast is both necessary and
> sufficient.
Maybe I missed something, but why are we using `<=` at all? Why not use
`<`?
Or is this some weird C pointer comparison UB thing?
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen-unstable 4.13.0-rc0 problem starting guest while trying to passthrough multiple pci devices
CC libxl maintainers On Tue, Oct 15, 2019 at 06:02:33PM +0200, Sander Eikelenboom wrote: > Hi Anthony, > > While testing xen-unstable 4.13.0-rc0 I ran in to the following issue: > > When passing through all 8 functions of a pci(e) device I can't start the > guest anymore, note that the trouble only starts at 0:9:0.3, not at 0:9:0.0: > libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain 3:Failed to > connect to QMP socket /var/run/xen/qmp-libxl-3: Resource temporarily > unavailable > libxl: error: libxl_pci.c:1702:device_pci_add_done: Domain > 3:libxl__device_pci_add failed for PCI device 0:9:0.3 (rc -3) > libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain 3:Failed to > connect to QMP socket /var/run/xen/qmp-libxl-3: Resource temporarily > unavailable > libxl: error: libxl_pci.c:1702:device_pci_add_done: Domain > 3:libxl__device_pci_add failed for PCI device 0:9:0.4 (rc -3) > libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain 3:Failed to > connect to QMP socket /var/run/xen/qmp-libxl-3: Resource temporarily > unavailable > libxl: error: libxl_pci.c:1702:device_pci_add_done: Domain > 3:libxl__device_pci_add failed for PCI device 0:9:0.5 (rc -3) > libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain 3:Failed to > connect to QMP socket /var/run/xen/qmp-libxl-3: Resource temporarily > unavailable > libxl: error: libxl_pci.c:1702:device_pci_add_done: Domain > 3:libxl__device_pci_add failed for PCI device 0:9:0.6 (rc -3) > libxl: error: libxl_qmp.c:1270:qmp_ev_connect: Domain 3:Failed to > connect to QMP socket /var/run/xen/qmp-libxl-3: Resource temporarily > unavailable > libxl: error: libxl_pci.c:1702:device_pci_add_done: Domain > 3:libxl__device_pci_add failed for PCI device 0:9:0.7 (rc -3) > libxl: error: libxl_create.c:1609:domcreate_attach_devices: Domain > 3:unable to add pci devices > libxl: error: libxl_domain.c:1177:libxl__destroy_domid: Domain > 3:Non-existant domain > libxl: error: libxl_domain.c:1131:domain_destroy_callback: Domain > 3:Unable to destroy guest > libxl: error: libxl_domain.c:1058:domain_destroy_cb: Domain > 3:Destruction of domain failed > > When only passing through the first functions 0:9:0.0 to 0:9:0.2, the guest > starts. Thanks for testing. I guess starting multiple connections at once, and hope QEMU is going to serialize it, isn't going to work. I'll rework that path in the code so that each pci device/functions will be done one at a time, like before. Cheers, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] xen/arm: Don't use _end in is_xen_fixed_mfn()
Stefano Stabellini writes ("Re: [PATCH for-4.13] xen/arm: Don't use _end in
is_xen_fixed_mfn()"):
> My suggestion is going to work: "the compiler sees through casts"
> referred to comparisons between pointers, where we temporarily casted
> both pointers to integers and back to pointers via a MACRO. That case
> was iffy because the MACRO was clearly a workaround the spec.
>
> Here the situation is different. For one, we are doing arithmetic. Also
> virt_to_maddr already takes a vaddr_t as argument. So instead of doing
> pointers arithmetic, then converting to vaddr_t, we are converting to
> vaddr_t first, then doing arithmetics, which is fine both from a C99
> point of view and even a MISRA C point of view. I can't see a problem
> with that. I am sure as I reasonable can be :-)
FTAOD I think you are suggesting this:
- + (mfn_to_maddr(mfn) <= virt_to_maddr(_end - 1)))
+ + (mfn_to_maddr(mfn) <= virt_to_maddr(((vaddr_t)_end - 1)))
virt_to_maddr(va) is a macro which expands to
__virt_to_maddr((vaddr_t)(va))
So what is happening here is that the cast to an integer type is being
done before the subtraction.
Without the cast, you are calculating the pointer value _end-1 from
the value _end, which is UB. With the cast you are calculating an
integer value. vaddr_t is unsigned, so all arithmetic operations are
defined. Nothing casts the result back to the "forbidden" (with this
provenance) pointer value, so all is well.
(With the macro expansion the cast happens twice. This is probably
better than using __virt_to_maddr here.)
Ie, in this case I agree with Stefano. The cast is both necessary and
sufficient.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.13 v3] xen/arm: domain_build: Don't expose IOMMU specific properties to hwdom
From: Oleksandr Tyshchenko
We always skip the IOMMU device when creating DT for hwdom if there is
an appropriate driver for it in Xen (device_get_class(iommu_node)
returns DEVICE_IOMMU). So, even if it is not used by Xen it will be skipped.
We should also skip the IOMMU specific properties of the master device
behind that IOMMU in order to avoid exposing an half complete IOMMU
bindings to hwdom.
According to the Linux's docs:
1. Documentation/devicetree/bindings/iommu/iommu.txt
2. Documentation/devicetree/bindings/pci/pci-iommu.txt
Signed-off-by: Oleksandr Tyshchenko
---
Changes V2 [2] -> V3:
- Gather two conditions in one "if"
- Clarify patch subject/comment in code
Changes V1 [1] -> V2:
- Only skip IOMMU specific properties of the master device if we
skip the corresponding IOMMU device
- Use "hwdom" over "Dom0"
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg00104.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg00673.html
---
xen/arch/arm/domain_build.c | 28
1 file changed, 28 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1d5eac9..6e85ef4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -480,10 +480,25 @@ static int __init write_properties(struct domain *d,
struct kernel_info *kinfo,
const struct dt_property *prop, *status = NULL;
int res = 0;
int had_dom0_bootargs = 0;
+struct dt_device_node *iommu_node;
if ( kinfo->cmdline && kinfo->cmdline[0] )
bootargs = >cmdline[0];
+/*
+ * We always skip the IOMMU device when creating DT for hwdom if there is
+ * an appropriate driver for it in Xen (device_get_class(iommu_node)
+ * returns DEVICE_IOMMU).
+ * We should also skip the IOMMU specific properties of the master device
+ * behind that IOMMU in order to avoid exposing an half complete IOMMU
+ * bindings to hwdom.
+ * Use "iommu_node" as an indicator of the master device which properties
+ * should be skipped.
+ */
+iommu_node = dt_parse_phandle(node, "iommus", 0);
+if ( iommu_node && device_get_class(iommu_node) != DEVICE_IOMMU )
+iommu_node = NULL;
+
dt_for_each_property_node (node, prop)
{
const void *prop_data = prop->value;
@@ -540,6 +555,19 @@ static int __init write_properties(struct domain *d,
struct kernel_info *kinfo,
continue;
}
+if ( iommu_node )
+{
+/* Don't expose IOMMU specific properties to hwdom */
+if ( dt_property_name_is_equal(prop, "iommus") )
+continue;
+
+if ( dt_property_name_is_equal(prop, "iommu-map") )
+continue;
+
+if ( dt_property_name_is_equal(prop, "iommu-map-mask") )
+continue;
+}
+
res = fdt_property(kinfo->fdt, prop->name, prop_data, prop_len);
if ( res )
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.4 test] 142762: regressions - trouble: fail/pass/starved
flight 142762 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/142762/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 142736 REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 142648 pass in 142762 test-armhf-armhf-libvirt 7 xen-boot fail in 142736 pass in 142762 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 142648 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail pass in 142736 test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail pass in 142736 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail pass in 142736 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail pass in 142736 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 142736 never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail in 142736 never pass 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-arm64-arm64-examine 8 reboot fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-arm64-arm64-libvirt-xsm 7 xen-boot fail never pass test-arm64-arm64-xl-credit2 7 xen-boot fail never pass test-arm64-arm64-xl-credit1 7 xen-boot fail never pass test-arm64-arm64-xl-xsm 7 xen-boot fail never pass test-arm64-arm64-xl-seattle 7 xen-boot fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-arm64-arm64-xl-thunderx 7 xen-boot fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 7 xen-boot fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop 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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop
Re: [Xen-devel] [PATCH v9 24/28] x86_64/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*
Hi, On Fri, Oct 11, 2019 at 01:51:04PM +0200, Jiri Slaby wrote: > These are all functions which are invoked from elsewhere, so annotate > them as global using the new SYM_FUNC_START. And their ENDPROC's by > SYM_FUNC_END. > > And make sure ENTRY/ENDPROC is not defined on X86_64, given these were > the last users. > > Signed-off-by: Jiri Slaby > Reviewed-by: Rafael J. Wysocki [hibernate] > Reviewed-by: Boris Ostrovsky [xen bits] > Cc: "H. Peter Anvin" > Cc: Borislav Petkov > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: x...@kernel.org > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: "Rafael J. Wysocki" > Cc: Len Brown > Cc: Pavel Machek > Cc: Matt Fleming > Cc: Ard Biesheuvel > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: linux-cry...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: xen-devel@lists.xenproject.org > --- > arch/x86/boot/compressed/efi_thunk_64.S | 4 +- > arch/x86/boot/compressed/head_64.S | 16 +++--- > arch/x86/boot/compressed/mem_encrypt.S | 8 +-- > arch/x86/crypto/aegis128-aesni-asm.S | 28 - > arch/x86/crypto/aes_ctrby8_avx-x86_64.S | 12 ++-- > arch/x86/crypto/aesni-intel_asm.S| 60 ++-- > arch/x86/crypto/aesni-intel_avx-x86_64.S | 32 +-- > arch/x86/crypto/blowfish-x86_64-asm_64.S | 16 +++--- > arch/x86/crypto/camellia-aesni-avx-asm_64.S | 24 > arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 24 > arch/x86/crypto/camellia-x86_64-asm_64.S | 16 +++--- > arch/x86/crypto/cast5-avx-x86_64-asm_64.S| 16 +++--- > arch/x86/crypto/cast6-avx-x86_64-asm_64.S| 24 > arch/x86/crypto/chacha-avx2-x86_64.S | 12 ++-- > arch/x86/crypto/chacha-avx512vl-x86_64.S | 12 ++-- > arch/x86/crypto/chacha-ssse3-x86_64.S| 12 ++-- > arch/x86/crypto/crc32-pclmul_asm.S | 4 +- > arch/x86/crypto/crc32c-pcl-intel-asm_64.S| 4 +- > arch/x86/crypto/crct10dif-pcl-asm_64.S | 4 +- > arch/x86/crypto/des3_ede-asm_64.S| 8 +-- > arch/x86/crypto/ghash-clmulni-intel_asm.S| 8 +-- > arch/x86/crypto/nh-avx2-x86_64.S | 4 +- > arch/x86/crypto/nh-sse2-x86_64.S | 4 +- > arch/x86/crypto/poly1305-avx2-x86_64.S | 4 +- > arch/x86/crypto/poly1305-sse2-x86_64.S | 8 +-- > arch/x86/crypto/serpent-avx-x86_64-asm_64.S | 24 > arch/x86/crypto/serpent-avx2-asm_64.S| 24 > arch/x86/crypto/serpent-sse2-x86_64-asm_64.S | 8 +-- > arch/x86/crypto/sha1_avx2_x86_64_asm.S | 4 +- > arch/x86/crypto/sha1_ni_asm.S| 4 +- > arch/x86/crypto/sha1_ssse3_asm.S | 4 +- > arch/x86/crypto/sha256-avx-asm.S | 4 +- > arch/x86/crypto/sha256-avx2-asm.S| 4 +- > arch/x86/crypto/sha256-ssse3-asm.S | 4 +- > arch/x86/crypto/sha256_ni_asm.S | 4 +- > arch/x86/crypto/sha512-avx-asm.S | 4 +- > arch/x86/crypto/sha512-avx2-asm.S| 4 +- > arch/x86/crypto/sha512-ssse3-asm.S | 4 +- > arch/x86/crypto/twofish-avx-x86_64-asm_64.S | 24 > arch/x86/crypto/twofish-x86_64-asm_64-3way.S | 8 +-- > arch/x86/crypto/twofish-x86_64-asm_64.S | 8 +-- I could use an ACK for the crypto bits... Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH hmm 08/15] xen/gntdev: Use select for DMA_SHARED_BUFFER
On 10/16/19 8:11 AM, Jürgen Groß wrote:
> On 15.10.19 20:12, Jason Gunthorpe wrote:
>> From: Jason Gunthorpe
>>
>> DMA_SHARED_BUFFER can not be enabled by the user (it represents a
>> library
>> set in the kernel). The kconfig convention is to use select for such
>> symbols so they are turned on implicitly when the user enables a kconfig
>> that needs them.
>>
>> Otherwise the XEN_GNTDEV_DMABUF kconfig is overly difficult to enable.
>>
>> Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI")
>> Cc: Oleksandr Andrushchenko
>> Cc: Boris Ostrovsky
>> Cc: xen-devel@lists.xenproject.org
>> Cc: Juergen Gross
>> Cc: Stefano Stabellini
>> Signed-off-by: Jason Gunthorpe
>
> Reviewed-by: Juergen Gross
>
Reviewed-by: Oleksandr Andrushchenko
>
> Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
