[Xen-devel] [linux-4.14 test] 128141: tolerable FAIL - PUSHED
flight 128141 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/128141/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 128097 pass in 128141 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-install fail pass in 128097 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linux2cc4d365363b1fb681b8231adcf4a8f80082506c baseline version: linux1244bbb3e92135d247e2dddfa6fe5e3e171a9635 Last test of basis 127877 2018-09-21 09:23:06 Z7 days Testing same since 128097 2018-09-26 07:11:31 Z2 days2 attempts People who touched revisions under test: Aaron Brown Aaron Knister Alan Stern Alexander Duyck Alexander Usyskin Alexandre Belloni Andrea Parri Andreas Gruenbacher Andreas Kemnade Andrew Jones Andy Gross Andy Shevchenko Anna Schumaker Anton Vasilyev Ard Biesheuvel Arnaldo Carvalho de Melo Bartlomiej Zolnierkiewicz Ben Hutchings Ben Skeggs Benjamin Poirier Bhushan
[Xen-devel] [qemu-mainline test] 128134: trouble: broken/fail/pass
flight 128134 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/128134/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt broken test-armhf-armhf-libvirt 4 host-install(4)broken REGR. vs. 128094 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128094 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128094 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128094 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128094 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-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-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuu866ba8385466a1a74ea4729e2a247c4c75584166 baseline version: qemuuc5e4e49258e9b89cb34c085a419dd9f862935c48 Last test of basis 128094 2018-09-26 06:27:55 Z2 days Testing same since 128134 2018-09-27 09:06:59 Z1 days1 attempts People who touched revisions under test: Dima Stepanov Li Qiang Peter Maydell Stefan Weil Thomas Huth jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvops
[Xen-devel] [ovmf baseline-only test] 75312: trouble: blocked/broken
This run is configured for baseline tests only. flight 75312 ovmf real [real] http://osstest.xensource.com/osstest/logs/75312/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-i386 broken build-amd64-pvopsbroken build-i386-xsm broken build-amd64 broken build-i386-pvops broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64 4 host-install(4) broken baseline untested build-amd64-xsm 4 host-install(4) broken baseline untested build-i386-pvops 4 host-install(4) broken baseline untested build-i3864 host-install(4) broken baseline untested build-amd64-pvops 4 host-install(4) broken baseline untested build-i386-xsm4 host-install(4) broken baseline untested version targeted for testing: ovmf b9cee524e6c1941b77b6780e19bd57052e53249c baseline version: ovmf 6532fdec11d7940a584a73797b5cc067d64f84a5 Last test of basis75310 2018-09-28 08:20:06 Z0 days Testing same since75312 2018-09-28 19:21:59 Z0 days1 attempts People who touched revisions under test: Chasel Chiu Chasel, Chiu Dongao Guo Guo, Dongao Jian J Wang Jiaxin Wu shenglei Star Zeng Wu Jiaxin jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-amd64-pvops broken broken-job build-i386-xsm broken broken-job build-amd64 broken broken-job build-i386-pvops broken broken-step build-amd64 host-install(4) broken-step build-amd64-xsm host-install(4) broken-step build-i386-pvops host-install(4) broken-step build-i386 host-install(4) broken-step build-amd64-pvops host-install(4) broken-step build-i386-xsm host-install(4) Push not applicable. (No revision log; it would be 418 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] [not-for-unstable] xen/arm: vgic-v3: Delay the initialization of the domain information
On 29/09/18 00:45, Stefano Stabellini wrote:
> On Sat, 29 Sep 2018, Andrew Cooper wrote:
>> On 28/09/18 21:35, Julien Grall wrote:
>>>
>>> On 09/28/2018 12:11 AM, Stefano Stabellini wrote:
On Wed, 26 Sep 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 09/25/2018 09:45 PM, Stefano Stabellini wrote:
>> On Tue, 4 Sep 2018, Andrew Cooper wrote:
>>> On 04/09/18 20:35, Julien Grall wrote:
Hi,
On 09/04/2018 08:21 PM, Julien Grall wrote:
> A follow-up patch will require to know the number of vCPUs when
> initializating the vGICv3 domain structure. However this
> information
> is
> not available at domain creation. This is only known once
> XEN_DOMCTL_max_vpus is called for that domain.
>
> In order to get the max vCPUs around, delay the domain part of the
> vGIC
> v3 initialization until the first vCPU of the domain is
> initialized.
>
> Signed-off-by: Julien Grall
>
> ---
>
> Cc: Andrew Cooper
>
> This is nasty but I can't find a better way for Xen 4.11 and older.
> This
> is not necessary for unstable as the number of vCPUs is known at
> domain
> creation.
>
> Andrew, I have CCed you to know whether you have a better idea
> where
> to
> place this call on Xen 4.11 and older.
I just noticed that d->max_vcpus is initialized after
arch_domain_create. So without this patch on Xen 4.12, it will
not work.
This is getting nastier because arch_domain_init is the one
initialize
the value returned by dom0_max_vcpus. So I am not entirely sure what
to do here.
>>> The positioning after arch_domain_create() is unfortunate, but I
>>> couldn’t manage better with ARM's current behaviour and Jan's
>>> insistence
>>> that the allocation of d->vcpu was common. I'd prefer if the
>>> dependency
>>> could be broken and the allocation moved earlier.
>>>
>>> One option might be to have an arch_check_domainconfig() (or
>>> similar?)
>>> which is called very early on and can sanity check the values,
>>> including
>>> cross-checking the vgic and max_vcpus settings? It could even be
>>> responsible for mutating XEN_DOMCTL_CONFIG_GIC_NATIVE into the
>>> correct
>>> real value.
>>>
>>> As for your patch here, its a gross hack, but its probably the best
>>> which can be done.
>> *Sighs*
>> If that is what we have to do, it is as ugly as hell, but that is what
>> we'll do.
> This is the best we can do with the current code base. I think it
> would be
> worth reworking the code to make it nicer. I will add it in my TODO
> list.
>
>> My only suggestion to marginally improve it would be instead of:
>>
>>> + if ( v->vcpu_id == 0 )
>>> + {
>>> + rc = vgic_v3_real_domain_init(d);
>>> + if ( rc )
>>> + return rc;
>>> + }
>> to check on d->arch.vgic.rdist_regions instead:
>>
>> if ( d->arch.vgic.rdist_regions == NULL )
>> {
>> // initialize domain
> I would prefer to keep v->vcpu_id == 0 just in case we end up to
> re-order the
> allocation in the future.
I was suggesting to check on (rdist_regions == NULL) exactly for
potential re-ordering, in case in the future we end up calling
vcpu_vgic_init differently and somehow vcpu_init(vcpu1) is done before
before vcpu_init(vcpu0). Ideally we would like a way to check that
vgic_v3_real_domain_init has been called before and I thought
rdist_regions == NULL could do just that...
>>> What I meant by re-ordering is we manage to allocate the
>>> re-distributors before the vCPUs are created but still need
>>> vgic_v3_real_domain_init for other purpose.
>>>
>>> But vCPU initialization is potentially other issue.
>>>
>>> Anyway. both way have drawbacks. Yet I still prefer checking on the
>>> vCPU. It less likely vCPU0 will not be the first one initialized.
>> With the exception of the idle domain, all vcpus are strictly allocated
>> in packed ascending order. Loads of other stuff will break if that
>> changed, so I wouldn't worry about it.
>>
>> Furthermore, there is no obvious reason for this behaviour to ever change.
> OK, let's go with Julien's patch. We need a new tag for this, something
> like:
>
> Acked-but-disliked-by: Stefano Stabellini
Do bear in mind that this patch is only for 4.11 and earlier. I've
already fixed staging (i.e. 4.12) when it comes to knowing d->max_vcpus :)
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/3] xen/arm: vgic-v3: Don't create empty re-distributor regions
On Fri, 28 Sep 2018, Julien Grall wrote: > On 09/28/2018 12:34 AM, Stefano Stabellini wrote: > > On Wed, 26 Sep 2018, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 09/25/2018 09:38 PM, Stefano Stabellini wrote: > > > > On Tue, 4 Sep 2018, Julien Grall wrote: > > > > > At the moment, Xen is assuming the hardware domain will have the same > > > > > number of re-distributor regions as the host. However, as the > > > > > number of CPUs or the stride (e.g on GICv4) may be different we end up > > > > > exposing regions which does not contain any re-distributors. > > > > > > > > > > When booting, Linux will go through all the re-distributor region to > > > > > check whether a property (e.g vPLIs) is available accross all the > > > > > re-distributors. This will result to a data abort on empty regions > > > > > because there are no underlying re-distributor. > > > > > > > > > > So we need to limit the number of regions exposed to the hardware > > > > > domain. The code reworked to only expose the minimun number of regions > > > > > required by the hardware domain. It is assumed the regions will be > > > > > populated starting from the first one. > > > > > > > > I have a question: given that it is possible for a rdist_region to cover > > > > more than 1 cpu, could we get into troubles if the last rdist_region of > > > > the hardware_domain covers 2 cpus, but actually dom0 only has 1 vcpu? > > > > get_vcpu_from_rdist would return NULL and vgic_v3_rdistr_mmio_read/write > > > > would return 0. > > > > This case seems to be handled correctly but I wanted to > > > > double check. > > > > > > 0 means a data abort will be injected into the guest. However, the guest > > > should never touch that because the last valid re-distributor of the > > > regions > > > will have GICR_TYPER.Last set. > > > > > > So the guest OS will stop looking for more re-distributors in that region. > > > > OK > > > > > > > > > > > > > I think we also need to fix vgic_v3_rdist_count? Today it just returns > > > > vgic_v3_hw.nr_rdist_regions for dom0. It would be bad if we left it > > > > unfixed? If we do that, we might be able to get rid of the modifications > > > > to vgic_v3_real_domain_init. > > > > > > We don't want to fix vgic_v3_rdist_count. The helper returns the maximum > > > re-distributors regions. > > > > We don't want to or we can't? Because it looks like we would want to fix > > vgic_v3_rdist_count if we could, right? It is called from domain > > specific initialization functions, so theoretically it should return > > domain specific vgic information, not physical information. > > We don't want to fix in the current design. > > > > > > > > This is used to compute the number of IO handlers and > > > allocating the array storing the regions. > > > > > > I am pretty sure you will say we will waste memory. However, at the > > > moment, > > > we need to know the number of IO handlers much before we know the number > > > of > > > vCPUs. For the array, we would need to go through the regions twice > > > (regions > > > may not be the same size so we can't infer easily the number needed). > > > Overall, > > > the amount of memory used is the same as today (so not really a waste > > > per-se). > > > > > > It might be possible to limit that once we reworked the common code to > > > know > > > the number of vCPUs earlier on (see discussion on patch #1). > > > > Yeah, this is nasty, but it is clear that until we rework the code to > > set d->max_vcpus earlier it won't get fixed. Nothing we can do here. > > > > So, I think ideally we would want to fix vgic_v3_rdist_count, but today > > we can't. Maybe we could rename vgic_v3_rdist_count to > > vgic_v3_hw_rdist_count, and add a short TODO comment somewhere in the > > file? > > > > Which would be wrong as the function don't always return the number of rdist > for the HW. > > A better name would be vgic_v3_max_rdist_count(struct domain *d). I am OK with that ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] [not-for-unstable] xen/arm: vgic-v3: Delay the initialization of the domain information
On Sat, 29 Sep 2018, Andrew Cooper wrote:
> On 28/09/18 21:35, Julien Grall wrote:
> >
> >
> > On 09/28/2018 12:11 AM, Stefano Stabellini wrote:
> >> On Wed, 26 Sep 2018, Julien Grall wrote:
> >>> Hi Stefano,
> >>>
> >>> On 09/25/2018 09:45 PM, Stefano Stabellini wrote:
> On Tue, 4 Sep 2018, Andrew Cooper wrote:
> > On 04/09/18 20:35, Julien Grall wrote:
> >> Hi,
> >>
> >> On 09/04/2018 08:21 PM, Julien Grall wrote:
> >>> A follow-up patch will require to know the number of vCPUs when
> >>> initializating the vGICv3 domain structure. However this
> >>> information
> >>> is
> >>> not available at domain creation. This is only known once
> >>> XEN_DOMCTL_max_vpus is called for that domain.
> >>>
> >>> In order to get the max vCPUs around, delay the domain part of the
> >>> vGIC
> >>> v3 initialization until the first vCPU of the domain is
> >>> initialized.
> >>>
> >>> Signed-off-by: Julien Grall
> >>>
> >>> ---
> >>>
> >>> Cc: Andrew Cooper
> >>>
> >>> This is nasty but I can't find a better way for Xen 4.11 and older.
> >>> This
> >>> is not necessary for unstable as the number of vCPUs is known at
> >>> domain
> >>> creation.
> >>>
> >>> Andrew, I have CCed you to know whether you have a better idea
> >>> where
> >>> to
> >>> place this call on Xen 4.11 and older.
> >>
> >> I just noticed that d->max_vcpus is initialized after
> >> arch_domain_create. So without this patch on Xen 4.12, it will
> >> not work.
> >>
> >> This is getting nastier because arch_domain_init is the one
> >> initialize
> >> the value returned by dom0_max_vcpus. So I am not entirely sure what
> >> to do here.
> >
> > The positioning after arch_domain_create() is unfortunate, but I
> > couldn’t manage better with ARM's current behaviour and Jan's
> > insistence
> > that the allocation of d->vcpu was common. I'd prefer if the
> > dependency
> > could be broken and the allocation moved earlier.
> >
> > One option might be to have an arch_check_domainconfig() (or
> > similar?)
> > which is called very early on and can sanity check the values,
> > including
> > cross-checking the vgic and max_vcpus settings? It could even be
> > responsible for mutating XEN_DOMCTL_CONFIG_GIC_NATIVE into the
> > correct
> > real value.
> >
> > As for your patch here, its a gross hack, but its probably the best
> > which can be done.
>
> *Sighs*
> If that is what we have to do, it is as ugly as hell, but that is what
> we'll do.
> >>>
> >>> This is the best we can do with the current code base. I think it
> >>> would be
> >>> worth reworking the code to make it nicer. I will add it in my TODO
> >>> list.
> >>>
>
> My only suggestion to marginally improve it would be instead of:
>
> > + if ( v->vcpu_id == 0 )
> > + {
> > + rc = vgic_v3_real_domain_init(d);
> > + if ( rc )
> > + return rc;
> > + }
>
> to check on d->arch.vgic.rdist_regions instead:
>
> if ( d->arch.vgic.rdist_regions == NULL )
> {
> // initialize domain
> >>>
> >>> I would prefer to keep v->vcpu_id == 0 just in case we end up to
> >>> re-order the
> >>> allocation in the future.
> >>
> >> I was suggesting to check on (rdist_regions == NULL) exactly for
> >> potential re-ordering, in case in the future we end up calling
> >> vcpu_vgic_init differently and somehow vcpu_init(vcpu1) is done before
> >> before vcpu_init(vcpu0). Ideally we would like a way to check that
> >> vgic_v3_real_domain_init has been called before and I thought
> >> rdist_regions == NULL could do just that...
> >
> > What I meant by re-ordering is we manage to allocate the
> > re-distributors before the vCPUs are created but still need
> > vgic_v3_real_domain_init for other purpose.
> >
> > But vCPU initialization is potentially other issue.
> >
> > Anyway. both way have drawbacks. Yet I still prefer checking on the
> > vCPU. It less likely vCPU0 will not be the first one initialized.
>
> With the exception of the idle domain, all vcpus are strictly allocated
> in packed ascending order. Loads of other stuff will break if that
> changed, so I wouldn't worry about it.
>
> Furthermore, there is no obvious reason for this behaviour to ever change.
OK, let's go with Julien's patch. We need a new tag for this, something
like:
Acked-but-disliked-by: Stefano Stabellini
:-)___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128209: tolerable all pass - PUSHED
flight 128209 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128209/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen edb4724e36256c495a6aa3cf1a12722efe271f9d baseline version: xen b6417fc19fba57c8d23180d2efda568d8eb78d80 Last test of basis 128191 2018-09-28 17:08:03 Z0 days Testing same since 128209 2018-09-28 21:06:31 Z0 days1 attempts People who touched revisions under test: Jan Beulich Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git b6417fc19f..edb4724e36 edb4724e36256c495a6aa3cf1a12722efe271f9d -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] [not-for-unstable] xen/arm: vgic-v3: Delay the initialization of the domain information
On 28/09/18 21:35, Julien Grall wrote:
>
>
> On 09/28/2018 12:11 AM, Stefano Stabellini wrote:
>> On Wed, 26 Sep 2018, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> On 09/25/2018 09:45 PM, Stefano Stabellini wrote:
On Tue, 4 Sep 2018, Andrew Cooper wrote:
> On 04/09/18 20:35, Julien Grall wrote:
>> Hi,
>>
>> On 09/04/2018 08:21 PM, Julien Grall wrote:
>>> A follow-up patch will require to know the number of vCPUs when
>>> initializating the vGICv3 domain structure. However this
>>> information
>>> is
>>> not available at domain creation. This is only known once
>>> XEN_DOMCTL_max_vpus is called for that domain.
>>>
>>> In order to get the max vCPUs around, delay the domain part of the
>>> vGIC
>>> v3 initialization until the first vCPU of the domain is
>>> initialized.
>>>
>>> Signed-off-by: Julien Grall
>>>
>>> ---
>>>
>>> Cc: Andrew Cooper
>>>
>>> This is nasty but I can't find a better way for Xen 4.11 and older.
>>> This
>>> is not necessary for unstable as the number of vCPUs is known at
>>> domain
>>> creation.
>>>
>>> Andrew, I have CCed you to know whether you have a better idea
>>> where
>>> to
>>> place this call on Xen 4.11 and older.
>>
>> I just noticed that d->max_vcpus is initialized after
>> arch_domain_create. So without this patch on Xen 4.12, it will
>> not work.
>>
>> This is getting nastier because arch_domain_init is the one
>> initialize
>> the value returned by dom0_max_vcpus. So I am not entirely sure what
>> to do here.
>
> The positioning after arch_domain_create() is unfortunate, but I
> couldn’t manage better with ARM's current behaviour and Jan's
> insistence
> that the allocation of d->vcpu was common. I'd prefer if the
> dependency
> could be broken and the allocation moved earlier.
>
> One option might be to have an arch_check_domainconfig() (or
> similar?)
> which is called very early on and can sanity check the values,
> including
> cross-checking the vgic and max_vcpus settings? It could even be
> responsible for mutating XEN_DOMCTL_CONFIG_GIC_NATIVE into the
> correct
> real value.
>
> As for your patch here, its a gross hack, but its probably the best
> which can be done.
*Sighs*
If that is what we have to do, it is as ugly as hell, but that is what
we'll do.
>>>
>>> This is the best we can do with the current code base. I think it
>>> would be
>>> worth reworking the code to make it nicer. I will add it in my TODO
>>> list.
>>>
My only suggestion to marginally improve it would be instead of:
> + if ( v->vcpu_id == 0 )
> + {
> + rc = vgic_v3_real_domain_init(d);
> + if ( rc )
> + return rc;
> + }
to check on d->arch.vgic.rdist_regions instead:
if ( d->arch.vgic.rdist_regions == NULL )
{
// initialize domain
>>>
>>> I would prefer to keep v->vcpu_id == 0 just in case we end up to
>>> re-order the
>>> allocation in the future.
>>
>> I was suggesting to check on (rdist_regions == NULL) exactly for
>> potential re-ordering, in case in the future we end up calling
>> vcpu_vgic_init differently and somehow vcpu_init(vcpu1) is done before
>> before vcpu_init(vcpu0). Ideally we would like a way to check that
>> vgic_v3_real_domain_init has been called before and I thought
>> rdist_regions == NULL could do just that...
>
> What I meant by re-ordering is we manage to allocate the
> re-distributors before the vCPUs are created but still need
> vgic_v3_real_domain_init for other purpose.
>
> But vCPU initialization is potentially other issue.
>
> Anyway. both way have drawbacks. Yet I still prefer checking on the
> vCPU. It less likely vCPU0 will not be the first one initialized.
With the exception of the idle domain, all vcpus are strictly allocated
in packed ascending order. Loads of other stuff will break if that
changed, so I wouldn't worry about it.
Furthermore, there is no obvious reason for this behaviour to ever change.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-examine
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-examine testid reboot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: c307aaf3eb47969105887e4e8991ec00960a7ce8 Bug not present: 30b06abfb92bfd5f9b63ea6a2ffb0bd905d1a6da Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/128210/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-examine.reboot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-examine.reboot --summary-out=tmp/128210.bisection-summary --basis-template=125898 --blessings=real,real-bisect linux-linus test-amd64-i386-examine reboot Searching for failure / basis pass: 128114 fail [host=chardonnay0] / 127221 [host=albana0] 127193 [host=huxelrebe1] 127148 [host=italia0] 127108 [host=debina0] 127038 [host=baroque0] 126888 [host=elbling1] 126682 [host=fiano0] 126550 [host=rimava1] 125898 [host=debina0] 125702 [host=fiano0] 125676 [host=albana0] 125657 [host=debina1] 125648 [host=baroque1] 125639 [host=huxelrebe1] 125585 [host=rimava1] 125551 [host=debina0] 125520 [host=fiano1] 125501 [host=albana1] 125401 [host=pinot1] 125285 ok. Failure / basis pass flights: 128114 / 125285 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest c307aaf3eb47969105887e4e8991ec00960a7ce8 c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 de5b678ca4dcdfa83e322491d478d66df56c1986 940185b2f6f343251c2b83bd96e599398cea51ec Basis pass 30b06abfb92bfd5f9b63ea6a2ffb0bd905d1a6da c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a e3f667bc5f51d0aa44357a64ca134cd952679c81 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#30b06abfb92bfd5f9b63ea6a2ffb0bd905d1a6da-c307aaf3eb47969105887e4e8991ec00960a7ce8 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 git://xenbits.xen.org/qemu-xen.git#43139135a8938de44f66333831d3a8655d07663a-de5b678ca4dcdfa83e322491d478d66df56c1986 git://xenbits.xen.org/xen.git#e3f667bc5f51d0aa44357a64ca134cd952679c81-940185b2f6f343251c2b83bd96e599398cea51ec adhoc-revtuple-generator: tree discontiguous: linux-2.6 adhoc-revtuple-generator: tree discontiguous: qemu-xen Loaded 2006 nodes in revision graph Searching for test results: 125167 fail irrelevant 125242 fail irrelevant 125285 pass 30b06abfb92bfd5f9b63ea6a2ffb0bd905d1a6da c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a e3f667bc5f51d0aa44357a64ca134cd952679c81 125401 [host=pinot1] 125501 [host=albana1] 125551 [host=debina0] 125520 [host=fiano1] 125585 [host=rimava1] 125648 [host=baroque1] 125639 [host=huxelrebe1] 125657 [host=debina1] 125676 [host=albana0] 125702 [host=fiano0] 125898 [host=debina0] 125921 [host=rimava1] 126069 [host=rimava1] 126202 [host=rimava1] 126310 [host=rimava1] 126412 [host=rimava1] 126550 [host=rimava1] 126682 [host=fiano0] 126888 [host=elbling1] 126978 [] 127038 [host=baroque0] 127108 [host=debina0] 127148 [host=italia0] 127193 [host=huxelrebe1] 127221 [host=albana0] 127256 fail irrelevant 127284 fail irrelevant 127315 fail irrelevant 127344 fail irrelevant 127364 fail irrelevant 127389 fail irrelevant 127403 fail irrelevant 127415 fail irrelevant 127443 fail irrelevant 127479 fail irrelevant 127458 fail irrelevant 127516 fail irrelevant 127497 fail irrelevant 127535 fail irrelevant 127551 fail irrelevant 127569 fail irrelevant 127617 fail irrelevant 127732 fail irrelevant 127793 fail irrelevant 127907 fail irrelevant 127976 fail irrelevant 127962 fail irrelevant 127991 fail irrelevant 128002 fail irrelevant 128022 fail irrelevant 128059 fail irrelevant 128114 fail
Re: [Xen-devel] [PATCH 2/3] xen/arm: vgic-v3: Don't create empty re-distributor regions
On 09/28/2018 12:34 AM, Stefano Stabellini wrote: On Wed, 26 Sep 2018, Julien Grall wrote: Hi Stefano, On 09/25/2018 09:38 PM, Stefano Stabellini wrote: On Tue, 4 Sep 2018, Julien Grall wrote: At the moment, Xen is assuming the hardware domain will have the same number of re-distributor regions as the host. However, as the number of CPUs or the stride (e.g on GICv4) may be different we end up exposing regions which does not contain any re-distributors. When booting, Linux will go through all the re-distributor region to check whether a property (e.g vPLIs) is available accross all the re-distributors. This will result to a data abort on empty regions because there are no underlying re-distributor. So we need to limit the number of regions exposed to the hardware domain. The code reworked to only expose the minimun number of regions required by the hardware domain. It is assumed the regions will be populated starting from the first one. I have a question: given that it is possible for a rdist_region to cover more than 1 cpu, could we get into troubles if the last rdist_region of the hardware_domain covers 2 cpus, but actually dom0 only has 1 vcpu? get_vcpu_from_rdist would return NULL and vgic_v3_rdistr_mmio_read/write would return 0. This case seems to be handled correctly but I wanted to double check. 0 means a data abort will be injected into the guest. However, the guest should never touch that because the last valid re-distributor of the regions will have GICR_TYPER.Last set. So the guest OS will stop looking for more re-distributors in that region. OK > I think we also need to fix vgic_v3_rdist_count? Today it just returns vgic_v3_hw.nr_rdist_regions for dom0. It would be bad if we left it unfixed? If we do that, we might be able to get rid of the modifications to vgic_v3_real_domain_init. We don't want to fix vgic_v3_rdist_count. The helper returns the maximum re-distributors regions. We don't want to or we can't? Because it looks like we would want to fix vgic_v3_rdist_count if we could, right? It is called from domain specific initialization functions, so theoretically it should return domain specific vgic information, not physical information. We don't want to fix in the current design. This is used to compute the number of IO handlers and allocating the array storing the regions. I am pretty sure you will say we will waste memory. However, at the moment, we need to know the number of IO handlers much before we know the number of vCPUs. For the array, we would need to go through the regions twice (regions may not be the same size so we can't infer easily the number needed). Overall, the amount of memory used is the same as today (so not really a waste per-se). It might be possible to limit that once we reworked the common code to know the number of vCPUs earlier on (see discussion on patch #1). Yeah, this is nasty, but it is clear that until we rework the code to set d->max_vcpus earlier it won't get fixed. Nothing we can do here. So, I think ideally we would want to fix vgic_v3_rdist_count, but today we can't. Maybe we could rename vgic_v3_rdist_count to vgic_v3_hw_rdist_count, and add a short TODO comment somewhere in the file? Which would be wrong as the function don't always return the number of rdist for the HW. A better name would be vgic_v3_max_rdist_count(struct domain *d). Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] [not-for-unstable] xen/arm: vgic-v3: Delay the initialization of the domain information
On 09/28/2018 12:11 AM, Stefano Stabellini wrote:
On Wed, 26 Sep 2018, Julien Grall wrote:
Hi Stefano,
On 09/25/2018 09:45 PM, Stefano Stabellini wrote:
On Tue, 4 Sep 2018, Andrew Cooper wrote:
On 04/09/18 20:35, Julien Grall wrote:
Hi,
On 09/04/2018 08:21 PM, Julien Grall wrote:
A follow-up patch will require to know the number of vCPUs when
initializating the vGICv3 domain structure. However this information
is
not available at domain creation. This is only known once
XEN_DOMCTL_max_vpus is called for that domain.
In order to get the max vCPUs around, delay the domain part of the
vGIC
v3 initialization until the first vCPU of the domain is initialized.
Signed-off-by: Julien Grall
---
Cc: Andrew Cooper
This is nasty but I can't find a better way for Xen 4.11 and older.
This
is not necessary for unstable as the number of vCPUs is known at
domain
creation.
Andrew, I have CCed you to know whether you have a better idea where
to
place this call on Xen 4.11 and older.
I just noticed that d->max_vcpus is initialized after
arch_domain_create. So without this patch on Xen 4.12, it will not work.
This is getting nastier because arch_domain_init is the one initialize
the value returned by dom0_max_vcpus. So I am not entirely sure what
to do here.
The positioning after arch_domain_create() is unfortunate, but I
couldn’t manage better with ARM's current behaviour and Jan's insistence
that the allocation of d->vcpu was common. I'd prefer if the dependency
could be broken and the allocation moved earlier.
One option might be to have an arch_check_domainconfig() (or similar?)
which is called very early on and can sanity check the values, including
cross-checking the vgic and max_vcpus settings? It could even be
responsible for mutating XEN_DOMCTL_CONFIG_GIC_NATIVE into the correct
real value.
As for your patch here, its a gross hack, but its probably the best
which can be done.
*Sighs*
If that is what we have to do, it is as ugly as hell, but that is what
we'll do.
This is the best we can do with the current code base. I think it would be
worth reworking the code to make it nicer. I will add it in my TODO list.
My only suggestion to marginally improve it would be instead of:
+if ( v->vcpu_id == 0 )
+{
+rc = vgic_v3_real_domain_init(d);
+if ( rc )
+return rc;
+}
to check on d->arch.vgic.rdist_regions instead:
if ( d->arch.vgic.rdist_regions == NULL )
{
// initialize domain
I would prefer to keep v->vcpu_id == 0 just in case we end up to re-order the
allocation in the future.
I was suggesting to check on (rdist_regions == NULL) exactly for
potential re-ordering, in case in the future we end up calling
vcpu_vgic_init differently and somehow vcpu_init(vcpu1) is done before
before vcpu_init(vcpu0). Ideally we would like a way to check that
vgic_v3_real_domain_init has been called before and I thought
rdist_regions == NULL could do just that...
What I meant by re-ordering is we manage to allocate the re-distributors
before the vCPUs are created but still need vgic_v3_real_domain_init for
other purpose.
But vCPU initialization is potentially other issue.
Anyway. both way have drawbacks. Yet I still prefer checking on the
vCPU. It less likely vCPU0 will not be the first one initialized.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128191: tolerable all pass - PUSHED
flight 128191 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128191/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen b6417fc19fba57c8d23180d2efda568d8eb78d80 baseline version: xen c62c53d61477dfeb63a47b0673c389082112babc Last test of basis 128173 2018-09-28 13:02:37 Z0 days Failing since128186 2018-09-28 16:04:14 Z0 days2 attempts Testing same since 128191 2018-09-28 17:08:03 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git c62c53d614..b6417fc19f b6417fc19fba57c8d23180d2efda568d8eb78d80 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] flask: Add check for io{port,mem}con sorting
These entries are not always sorted by checkpolicy. Enforce the sorting
(which can be done manually if using an unpatched checkpolicy) when
loading the policy so that later uses by the security server do not
incorrectly use the initial sid.
Reported-by: Nicolas Poirot
Signed-off-by: Daniel De Graaf
---
xen/xsm/flask/ss/policydb.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 3a12d96ef9..fcf63693b9 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -2007,7 +2007,6 @@ int policydb_read(struct policydb *p, void *fp)
l->next = c;
else
p->ocontexts[i] = c;
-l = c;
rc = -EINVAL;
switch ( i )
{
@@ -2050,6 +2049,12 @@ int policydb_read(struct policydb *p, void *fp)
rc = context_read_and_validate(>context, p, fp);
if ( rc )
goto bad;
+if ( l && l->u.ioport.high_ioport > c->u.ioport.low_ioport )
+{
+printk(KERN_ERR
+"Flask: Invalid policy, ioportcon not sorted\n");
+goto bad;
+}
break;
case OCON_IOMEM:
if ( p->target_type != TARGET_XEN )
@@ -2078,6 +2083,12 @@ int policydb_read(struct policydb *p, void *fp)
rc = context_read_and_validate(>context, p, fp);
if ( rc )
goto bad;
+if ( l && l->u.iomem.high_iomem > c->u.iomem.low_iomem )
+{
+printk(KERN_ERR
+"Flask: Invalid policy, iomemcon not sorted\n");
+goto bad;
+}
break;
case OCON_DEVICE:
if ( p->target_type != TARGET_XEN )
@@ -2123,6 +2134,7 @@ int policydb_read(struct policydb *p, void *fp)
rc = -EINVAL;
goto bad;
}
+l = c;
}
}
--
2.14.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Xen-users] XSM/Flask iomem
This is apparently a mismatch between what the checkpolicy compilation does and what it is expected to do. While some parts of checkpolicy do this sorting, the main compilation flow does not, and the policy compilation process does not ensure inputs are sorted. In the future, newer versions of checkpolicy should fix this bug. Newer versions of Xen may also start checking this ordering on policy load (I'll submit a patch to do this). This bug also applies to I/O ports, but not the other types of policy items (IRQs, PCI devices, or devicetree). It will cause non-sorted entries to be skipped in most cases, instead querying the default sid, but larger iomem/ioport ranges might also query the skipped entry (always in addition to the default). Until the fixed version of checkpoicy is released and adopted, policy writers can manually sort their iomem/ioport ranges as a workaround. On 09/27/2018 06:18 AM, George Dunlap wrote: [Moving to xen-devel] Daniel, Any comments on this one? -George On Wed, Sep 26, 2018 at 12:41 PM wrote: Hi, I just noticed from a bad behaviour of my installation and the security_iterate_iomem_sids function that the iomem ranges have to be sorted in the device_contexts file. The flask load policy takes iomem ranges declaration as it comes but the sid attribution and check function expects the list of iomem ocontexts to be sorted. My file didn't comply with this statement which ended to use the default iomem sid instead of computing one before checking the permission. This doesn't seem to be documented anywhere in the xen release 4.11.0. Thanks. Nicolas 1 ___ Xen-users mailing list xen-us...@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-users ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75310: trouble: blocked/broken
This run is configured for baseline tests only. flight 75310 ovmf real [real] http://osstest.xensource.com/osstest/logs/75310/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm broken build-i386 broken build-amd64-pvopsbroken build-i386-xsm broken build-amd64 broken build-i386-pvops broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64 4 host-install(4) broken baseline untested build-amd64-xsm 4 host-install(4) broken baseline untested build-i386-pvops 4 host-install(4) broken baseline untested build-i3864 host-install(4) broken baseline untested build-amd64-pvops 4 host-install(4) broken baseline untested build-i386-xsm4 host-install(4) broken baseline untested version targeted for testing: ovmf 6532fdec11d7940a584a73797b5cc067d64f84a5 baseline version: ovmf 6a147d6dae733f3a1d5ddf9af9adce5fb8504a53 Last test of basis75305 2018-09-27 18:20:23 Z1 days Testing same since75310 2018-09-28 08:20:06 Z0 days1 attempts People who touched revisions under test: Chasel, Chiu Jiaxin Wu Laszlo Ersek shenglei Star Zeng Wu Jiaxin jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-amd64-pvops broken broken-job build-i386-xsm broken broken-job build-amd64 broken broken-job build-i386-pvops broken broken-step build-amd64 host-install(4) broken-step build-amd64-xsm host-install(4) broken-step build-i386-pvops host-install(4) broken-step build-i386 host-install(4) broken-step build-amd64-pvops host-install(4) broken-step build-i386-xsm host-install(4) Push not applicable. (No revision log; it would be 536 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen/xsm: Add new SILO mode for XSM
On 09/28/2018 04:18 AM, Xin Li wrote: When SILO is enabled, there would be no page-sharing or event notifications between unprivileged VMs (no grant tables or event channels). Signed-off-by: Xin Li v3: make copies of dummy functions to avoid indirect call. This still makes indirect calls. You will need to #include xsm/dummy.h, and a third case in line 44's #ifdef CONFIG_XSM / #else may be required to adjust XSM_INLINE to avoid compiler warnings. The function xsm_fixup_ops() will already set the unused parts of your xsm_operations struct to the dummy functions; you don't need to do that in silo_init by copying dummy_xsm_ops. You should use register_xsm to assign to xsm_ops instead of doing it yourself. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] xen/vsprintf: Introduce %pd formatter for domains
This allows all system domids to be printed by name, rather than special
casing the idle vcpus alone.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
v2:
* Render system names in square brackets.
* Drop DOMID_{SELF,INVALID} names because there are no struct domain *'s for
them.
* Cope with NULL pointers.
* Fix a length-counting bug.
---
docs/misc/printk-formats.txt | 14 --
xen/common/vsprintf.c| 61 +---
2 files changed, 58 insertions(+), 17 deletions(-)
diff --git a/docs/misc/printk-formats.txt b/docs/misc/printk-formats.txt
index 525108f..b5570bc 100644
--- a/docs/misc/printk-formats.txt
+++ b/docs/misc/printk-formats.txt
@@ -28,5 +28,15 @@ Symbol/Function pointers:
Domain and vCPU information:
- %pv Domain and vCPU ID from a 'struct vcpu *' (printed as
- "dv")
+ %pd Domain from a 'struct domain *'
+
+ Regular domains are printed with their ID in decimal. System
+ domains are printed with their name.
+ e.g. d0
+ d[IDLE]
+
+ %pv Domain and vCPU ID from a 'struct vcpu *'
+
+ The domain part as above, with the vcpu_id printed in decimal.
+ e.g. d0v1
+ d[IDLE]v0
diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index f92fb67..df347d3 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -264,6 +264,47 @@ static char *string(char *str, char *end, const char *s,
return str;
}
+/* Print a domain id, using names for system domains. (e.g. d0 or d[IDLE]) */
+static char *print_domain(char *str, char *end, const struct domain *d)
+{
+const char *name = NULL;
+
+/* Some debugging may have an optionally-NULL pointer. */
+if ( unlikely(!d) )
+return string(str, end, "NULL", -1, -1, 0);
+
+if ( str < end )
+*str = 'd';
+
+switch ( d->domain_id )
+{
+case DOMID_IO: name = "[IO]"; break;
+case DOMID_XEN: name = "[XEN]"; break;
+case DOMID_COW: name = "[COW]"; break;
+case DOMID_IDLE: name = "[IDLE]"; break;
+}
+
+if ( name )
+return string(str + 1, end, name, -1, -1, 0);
+else
+return number(str + 1, end, d->domain_id, 10, -1, -1, 0);
+}
+
+/* Print a vcpu id. (e.g. d0v1 or d[IDLE]v0) */
+static char *print_vcpu(char *str, char *end, const struct vcpu *v)
+{
+/* Some debugging may have an optionally-NULL pointer. */
+if ( unlikely(!v) )
+return string(str, end, "NULL", -1, -1, 0);
+
+str = print_domain(str, end, v->domain);
+
+if ( str < end )
+*str = 'v';
+
+return number(str + 1, end, v->vcpu_id, 10, -1, -1, 0);
+}
+
static char *pointer(char *str, char *end, const char **fmt_ptr,
const void *arg, int field_width, int precision,
int flags)
@@ -273,6 +314,10 @@ static char *pointer(char *str, char *end, const char
**fmt_ptr,
/* Custom %p suffixes. See XEN_ROOT/docs/misc/printk-formats.txt */
switch ( fmt[1] )
{
+case 'd': /* Domain ID from a struct domain *. */
+++*fmt_ptr;
+return print_domain(str, end, arg);
+
case 'h': /* Raw buffer as hex string. */
{
const uint8_t *hex_buffer = arg;
@@ -370,22 +415,8 @@ static char *pointer(char *str, char *end, const char
**fmt_ptr,
}
case 'v': /* dv from a struct vcpu */
-{
-const struct vcpu *v = arg;
-
++*fmt_ptr;
-if ( unlikely(v->domain->domain_id == DOMID_IDLE) )
-str = string(str, end, "IDLE", -1, -1, 0);
-else
-{
-if ( str < end )
-*str = 'd';
-str = number(str + 1, end, v->domain->domain_id, 10, -1, -1, 0);
-}
-if ( str < end )
-*str = 'v';
-return number(str + 1, end, v->vcpu_id, 10, -1, -1, 0);
-}
+return print_vcpu(str, end, arg);
}
if ( field_width == -1 )
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen/xsm: Introduce new boot parameter xsm
On 09/28/2018 04:18 AM, Xin Li wrote: Introduce new boot parameter xsm to choose which xsm module is enabled, and set default to dummy. Signed-off-by: Xin Li This changes the default behavior of a hypervisor compiled with XSM+FLASK when booted with no command line arguments from enabling FLASK to enabling the dummy module. I think the default value of the "xsm=" parameter should be settable in Kconfig to allow existing systems to continue working after an upgrade. If not, this new command line argument needs to be mentioned in more locations in the documentation; at least docs/misc/xsm-flask "Setting up FLASK" will need to mention it. I think a mention in the release notes for the next version is also a good idea (in addition to or as part of the note on the new SILO feature), but that's not a part of the patch. Untested Kconfig snippet: choice prompt "Default XSM implementation" default XSM_FLASK_DEFAULT if XSM_FLASK default XSM_SILO_DEFAULT if XSM_SILO default XSM_DUMMY_DEFAULT config XSM_DUMMY_DEFAULT bool "Match non-XSM behavior" config XSM_FLASK_DEFAULT bool "FLux Advanced Security Kernel" if XSM_FLASK config XSM_SILO_DEFAULT bool "SILO" if XSM_SILO endchoice The multiple "default" statements are intended to cause the default to be the chosen enabled system, or dummy if there are no existing Kconfig settings. I also think the question for XSM_FLASK should be removed from EXPERT now that there is a reason to enable XSM without FLASK. The name "default" might end up being misleading in this case; "none", "off", or "dummy" might be better. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] xen: initialise opt_xen_console early in PVH boot path
On 28/09/18 18:06, Wei Liu wrote: > This helps capture issues before console is initialised. > > Signed-off-by: Wei Liu Much nicer behaviour. Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86: make sure module array is large enough in pvh-boot.c
On 28/09/18 18:06, Wei Liu wrote:
> diff --git a/xen/arch/x86/guest/pvh-boot.c b/xen/arch/x86/guest/pvh-boot.c
> index 0e9e5bfdf6..3b44aee90a 100644
> --- a/xen/arch/x86/guest/pvh-boot.c
> +++ b/xen/arch/x86/guest/pvh-boot.c
> @@ -42,7 +42,17 @@ static void __init convert_pvh_info(void)
> module_t *mod;
> unsigned int i;
>
> -ASSERT(pvh_info->magic == XEN_HVM_START_MAGIC_VALUE);
> +if ( pvh_info->magic != XEN_HVM_START_MAGIC_VALUE )
> +panic("Magic value is wrong: %X\n", pvh_info->magic);
%x ?
> +
> +/*
> + * Temporary module array needs to be at least one element bigger than
> + * required. The extra element is used to aid relocation. See
> + * arch/x86/setup.c:__start_xen().
> + */
> +if ( ARRAY_SIZE(pvh_mbi_mods) <= pvh_info->nr_modules )
> +panic("The module array is too small, size %lu, requested %u.\n",
%zu for size_t, and please drop the unnecessary trailing .
Otherwise, Reviewed-by: Andrew Cooper
> + ARRAY_SIZE(pvh_mbi_mods), pvh_info->nr_modules);
>
> /*
> * Turn hvm_start_info into mbi. Luckily all modules are placed under 4GB
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/2] xen: initialise opt_xen_console early in PVH boot path
This helps capture issues before console is initialised.
Signed-off-by: Wei Liu
---
xen/arch/x86/setup.c | 5 +
xen/drivers/char/console.c | 10 --
xen/include/xen/console.h | 2 ++
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2fbf7d574c..20cb0acc3f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -708,6 +708,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
if ( pvh_boot )
{
+/*
+ * Force xen console to be enabled. We will reset it later in console
+ * initialisation code.
+ */
+opt_console_xen = -1;
ASSERT(mbi_p == 0);
mbi = pvh_init();
}
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index e48039dd82..3b75f7a472 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -91,7 +91,8 @@ static uint32_t conringc, conringp;
static int __read_mostly sercon_handle = -1;
#ifdef CONFIG_X86
-static bool __read_mostly opt_console_xen; /* console=xen */
+/* Tristate: 0 disabled, 1 user enabled, -1 default enabled */
+int8_t __read_mostly opt_console_xen; /* console=xen */
#endif
static DEFINE_SPINLOCK(console_lock);
@@ -832,7 +833,7 @@ void __init console_init_preirq(void)
pv_console_init();
#ifdef CONFIG_X86
else if ( !strncmp(p, "xen", 3) )
-opt_console_xen = true;
+opt_console_xen = 1;
#endif
else if ( !strncmp(p, "none", 4) )
continue;
@@ -852,6 +853,11 @@ void __init console_init_preirq(void)
}
}
+#ifdef CONFIG_X86
+if ( opt_console_xen == -1 )
+opt_console_xen = 0;
+#endif
+
serial_set_rx_handler(sercon_handle, serial_rx);
pv_console_set_rx_handler(serial_rx);
diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index ea06fd8078..70c9911a49 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -43,4 +43,6 @@ void console_giveback(int id);
int console_suspend(void);
int console_resume(void);
+extern int8_t opt_console_xen;
+
#endif /* __CONSOLE_H__ */
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 1/2] x86: make sure module array is large enough in pvh-boot.c
The relocation code in __start_xen requires one extra element in the
module array. By the looks of it the temporary array is already large
enough. Panic if that's not the case.
While at it, turn an ASSERT to panic() as well.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/pvh-boot.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/guest/pvh-boot.c b/xen/arch/x86/guest/pvh-boot.c
index 0e9e5bfdf6..3b44aee90a 100644
--- a/xen/arch/x86/guest/pvh-boot.c
+++ b/xen/arch/x86/guest/pvh-boot.c
@@ -42,7 +42,17 @@ static void __init convert_pvh_info(void)
module_t *mod;
unsigned int i;
-ASSERT(pvh_info->magic == XEN_HVM_START_MAGIC_VALUE);
+if ( pvh_info->magic != XEN_HVM_START_MAGIC_VALUE )
+panic("Magic value is wrong: %X\n", pvh_info->magic);
+
+/*
+ * Temporary module array needs to be at least one element bigger than
+ * required. The extra element is used to aid relocation. See
+ * arch/x86/setup.c:__start_xen().
+ */
+if ( ARRAY_SIZE(pvh_mbi_mods) <= pvh_info->nr_modules )
+panic("The module array is too small, size %lu, requested %u.\n",
+ ARRAY_SIZE(pvh_mbi_mods), pvh_info->nr_modules);
/*
* Turn hvm_start_info into mbi. Luckily all modules are placed under 4GB
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/2] Minor improvement to early boot code
Wei Liu (2): x86: make sure module array is large enough in pvh-boot.c xen: initialise opt_xen_console early in PVH boot path xen/arch/x86/guest/pvh-boot.c | 12 +++- xen/arch/x86/setup.c | 5 + xen/drivers/char/console.c| 10 -- xen/include/xen/console.h | 2 ++ 4 files changed, 26 insertions(+), 3 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] mm/memory_hotplug: Introduce memory block types
It's really nice if these kinds of things are broken up. First, replace
the old want_memblock parameter, then add the parameter to the
__add_page() calls.
> +/*
> + * NONE: No memory block is to be created (e.g. device memory).
> + * NORMAL: Memory block that represents normal (boot or hotplugged) memory
> + * (e.g. ACPI DIMMs) that should be onlined either automatically
> + * (memhp_auto_online) or manually by user space to select a
> + * specific zone.
> + * Applicable to memhp_auto_online.
> + * STANDBY: Memory block that represents standby memory that should only
> + * be onlined on demand by user space (e.g. standby memory on
> + * s390x), but never automatically by the kernel.
> + * Not applicable to memhp_auto_online.
> + * PARAVIRT: Memory block that represents memory added by
> + * paravirtualized mechanisms (e.g. hyper-v, xen) that will
> + * always automatically get onlined. Memory will be unplugged
> + * using ballooning, not by relying on the MOVABLE ZONE.
> + * Not applicable to memhp_auto_online.
> + */
> +enum {
> + MEMORY_BLOCK_NONE,
> + MEMORY_BLOCK_NORMAL,
> + MEMORY_BLOCK_STANDBY,
> + MEMORY_BLOCK_PARAVIRT,
> +};
This does not seem like the best way to expose these.
STANDBY, for instance, seems to be essentially a replacement for a check
against running on s390 in userspace to implement a _typical_ s390
policy. It seems rather weird to try to make the userspace policy
determination easier by telling userspace about the typical s390 policy
via the kernel.
As for the OOM issues, that sounds like something we need to fix by
refusing to do (or delaying) hot-add operations once we consume too much
ZONE_NORMAL from memmap[]s rather than trying to indirectly tell
userspace to hurry thing along.
So, to my eye, we need:
+enum {
+ MEMORY_BLOCK_NONE,
+ MEMORY_BLOCK_STANDBY, /* the default */
+ MEMORY_BLOCK_AUTO_ONLINE,
+};
and we can probably collapse NONE into AUTO_ONLINE because userspace
ends up doing the same thing for both: nothing.
> struct memory_block {
> unsigned long start_section_nr;
> unsigned long end_section_nr;
> @@ -34,6 +58,7 @@ struct memory_block {
> int (*phys_callback)(struct memory_block *);
> struct device dev;
> int nid;/* NID for this memory block */
> + int type; /* type of this memory block */
> };
Shouldn't we just be creating and using an actual named enum type?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
On Fri, Sep 28, 2018 at 05:19:50PM +0100, Wei Liu wrote: > On Fri, Sep 28, 2018 at 10:05:21AM -0600, Jan Beulich wrote: > > >>> On 28.09.18 at 17:53, wrote: > > > At the moment the ordering of the options matter, which means if "xen" > > > is not the first option we can lose output. > > > > > > I think one easy way of improving is to parse opt_console twice. The > > > first time solely looks for "xen" and the second time parses the rest > > > options. > > > > What's wrong with making the variable a tristate, and move your > > set-to-false after the parsing loop? If the user said "false" for the > > option, then they apparently don't care much about the output. > > Oh, there is nothing wrong with that. It just I didn't think about that > solution while thinking about this problem. > > > > > But yes, what you suggest is an option as well. > > Yeah, I already got code for it. After fixing the bugs in my code it has become too long for my liking so I will turn to use tristate instead. :p Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128186: regressions - trouble: blocked/fail
flight 128186 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128186/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128173
build-amd64 6 xen-buildfail REGR. vs. 128173
build-armhf 6 xen-buildfail REGR. vs. 128173
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a
test-armhf-armhf-xl 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
version targeted for testing:
xen 3d3feaa45609fb4d3a2541d78e0e9717dbb223fb
baseline version:
xen c62c53d61477dfeb63a47b0673c389082112babc
Last test of basis 128173 2018-09-28 13:02:37 Z0 days
Testing same since 128186 2018-09-28 16:04:14 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
Wei Liu
jobs:
build-arm64-xsm fail
build-amd64 fail
build-armhf fail
build-amd64-libvirt blocked
test-armhf-armhf-xl blocked
test-arm64-arm64-xl-xsm blocked
test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked
test-amd64-amd64-libvirt blocked
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 3d3feaa45609fb4d3a2541d78e0e9717dbb223fb
Author: Andrew Cooper
Date: Fri Sep 28 16:21:54 2018 +0100
tools/libgnttab: Undo incorrect SONAME bump in c/s ee8105cab
Xen 4.11 shipped with a SONAME of 1.1.
For staging (and 4.12 eventually), the SONAME was bumped to 1.2 by c/s
28ca696a3. Further changes before 4.12 ships should not bump the SONAME.
Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
commit 9c4bfc5d667e3c9a226f5386d2ef0282dce8289f
Author: Andrew Cooper
Date: Fri Sep 28 15:46:53 2018 +0100
tools/configure: Drop libgcrypt detection
This was last used by blktap1, which was deleted by c/s f6bcc035084 in 2014.
Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
commit 82f7659c9bd72e80c4734113f30907198326e39c
Author: Jan Beulich
Date: Fri Sep 28 17:13:38 2018 +0200
x86: hap_enabled() is HVM-only
There at least two cases where the field so far got accessed for PV
guests as well: One is in iommu_construct(), via iommu_use_hap_pt(),
and the other is
arch_domain_create()
-> paging_domain_init()
-> p2m_init()
-> p2m_init_hostp2m()
-> p2m_init_one()
-> p2m_initialise()
It just so happens that the field currently lives in struct hvm_domain
at an offset larger than sizeof(struct pv_domain).
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
commit 2fb57e4beefeda923446b73f88b392e59b07d847
Author: Jan Beulich
Date: Fri Sep 28 17:12:14 2018 +0200
x86: silence false log messages for plain "xpti" / "pv-l1tf"
While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
parsing") claimed to have got rid of the 'parameter "xpti" has invalid
value "", rc=-22!' log message for "xpti" alone on the command line,
this wasn't the case (the option took effect nevertheless).
Fix this there as well as for plain "pv-l1tf".
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
On Fri, Sep 28, 2018 at 10:05:21AM -0600, Jan Beulich wrote: > >>> On 28.09.18 at 17:53, wrote: > > At the moment the ordering of the options matter, which means if "xen" > > is not the first option we can lose output. > > > > I think one easy way of improving is to parse opt_console twice. The > > first time solely looks for "xen" and the second time parses the rest > > options. > > What's wrong with making the variable a tristate, and move your > set-to-false after the parsing loop? If the user said "false" for the > option, then they apparently don't care much about the output. Oh, there is nothing wrong with that. It just I didn't think about that solution while thinking about this problem. > > But yes, what you suggest is an option as well. Yeah, I already got code for it. Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/altp2m: propagate ept.ad changes to all active altp2ms
On 9/28/18 6:55 PM, Jan Beulich wrote:
On 28.09.18 at 17:25, wrote:
>> On 9/28/18 5:52 PM, Jan Beulich wrote:
>> On 28.09.18 at 13:55, wrote:
@@ -1218,34 +1219,67 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
ept_sync_domain_mask(p2m, p2m->domain->dirty_cpumask);
}
+static void ept_set_ad_sync(struct p2m_domain *p2m, int value)
+{
+struct domain *d = p2m->domain;
+unsigned int i;
+
+if ( likely(!altp2m_active(d)) )
+{
+p2m_lock(p2m);
+p2m->ept.ad = value;
+p2m_unlock(p2m);
+
+return;
+}
>>>
>>> Why would you want to skip updating the host p2m's flag when
>>> altp2m is active?
>>
>> It's not really skipped if I understand the altp2m code correctly: in
>> that case the hostp2m is d->arch.altp2m_p2m[0], which is take care of in
>> the loop below the code you've quoted.
>
> p2m_init_altp2m() (and other code in p2m.c) suggests otherwise to me.
That's interesting, p2m_set_mem_access() is treating altp2m index 0 as
the hostp2m:
360 /*
361 * Set access type for a region of gfns.
362 * If gfn == INVALID_GFN, sets the default access type.
363 */
364 long p2m_set_mem_access(struct domain *d, gfn_t gfn, uint32_t nr,
365 uint32_t start, uint32_t mask,
xenmem_access_t access,
366 unsigned int altp2m_idx)
367 {
368 struct p2m_domain *p2m = p2m_get_hostp2m(d), *ap2m = NULL;
369 p2m_access_t a;
370 unsigned long gfn_l;
371 long rc = 0;
372
373 /* altp2m view 0 is treated as the hostp2m */
374 #ifdef CONFIG_HVM
375 if ( altp2m_idx )
376 {
377 if ( altp2m_idx >= MAX_ALTP2M ||
378 d->arch.altp2m_eptp[altp2m_idx] == mfn_x(INVALID_MFN) )
379 return -EINVAL;
380
381 ap2m = d->arch.altp2m_p2m[altp2m_idx];
382 }
383 #else
384 ASSERT(!altp2m_idx);
385 #endif
which would seem to imply that either we should be able to treat
d->arch.altp2m_p2m[0] and hostp2m interchangeably, or we are currently
wasting an altp2m array slot.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
>>> On 28.09.18 at 17:53, wrote: > At the moment the ordering of the options matter, which means if "xen" > is not the first option we can lose output. > > I think one easy way of improving is to parse opt_console twice. The > first time solely looks for "xen" and the second time parses the rest > options. What's wrong with making the variable a tristate, and move your set-to-false after the parsing loop? If the user said "false" for the option, then they apparently don't care much about the output. But yes, what you suggest is an option as well. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools/libgnttab: Fix build following c/s 3d3feaa4560
On Fri, Sep 28, 2018 at 04:59:16PM +0100, Andrew Cooper wrote: > VERS_1.2 can't extend itself. It should extend VERS_1.1 > > Signed-off-by: Andrew Cooper Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-jessie test] 75309: trouble: blocked/broken
flight 75309 distros-debian-jessie real [real] http://osstest.xensource.com/osstest/logs/75309/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i386 broken build-amd64-pvopsbroken build-armhf broken build-amd64 broken build-i386-pvops broken Tests which did not succeed, but are not blocking: test-amd64-i386-i386-jessie-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-jessie-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-jessie-netboot-pygrub 1 build-check(1) blocked n/a test-armhf-armhf-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-jessie-netboot-pvgrub 1 build-check(1) blocked n/a build-armhf-pvops 4 host-install(4) broken like 75261 build-armhf 4 host-install(4) broken like 75261 build-i386-pvops 4 host-install(4) broken like 75261 build-amd64-pvops 4 host-install(4) broken like 75261 build-i3864 host-install(4) broken like 75261 build-amd64 4 host-install(4) broken like 75261 baseline version: flight 75261 jobs: build-amd64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-jessie-netboot-pvgrub blocked test-amd64-i386-i386-jessie-netboot-pvgrub blocked test-amd64-i386-amd64-jessie-netboot-pygrub blocked test-armhf-armhf-armhf-jessie-netboot-pygrub blocked test-amd64-amd64-i386-jessie-netboot-pygrub blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tools/libgnttab: Fix build following c/s 3d3feaa4560
VERS_1.2 can't extend itself. It should extend VERS_1.1
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/libs/gnttab/libxengnttab.map | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/gnttab/libxengnttab.map
b/tools/libs/gnttab/libxengnttab.map
index e15f6e9..d2a9b7e 100644
--- a/tools/libs/gnttab/libxengnttab.map
+++ b/tools/libs/gnttab/libxengnttab.map
@@ -35,4 +35,4 @@ VERS_1.2 {
xengnttab_dmabuf_exp_wait_released;
xengnttab_dmabuf_imp_to_refs;
xengnttab_dmabuf_imp_release;
-} VERS_1.2;
+} VERS_1.1;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/altp2m: propagate ept.ad changes to all active altp2ms
>>> On 28.09.18 at 17:25, wrote:
> On 9/28/18 5:52 PM, Jan Beulich wrote:
> On 28.09.18 at 13:55, wrote:
>>> @@ -1218,34 +1219,67 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
>>> ept_sync_domain_mask(p2m, p2m->domain->dirty_cpumask);
>>> }
>>>
>>> +static void ept_set_ad_sync(struct p2m_domain *p2m, int value)
>>> +{
>>> +struct domain *d = p2m->domain;
>>> +unsigned int i;
>>> +
>>> +if ( likely(!altp2m_active(d)) )
>>> +{
>>> +p2m_lock(p2m);
>>> +p2m->ept.ad = value;
>>> +p2m_unlock(p2m);
>>> +
>>> +return;
>>> +}
>>
>> Why would you want to skip updating the host p2m's flag when
>> altp2m is active?
>
> It's not really skipped if I understand the altp2m code correctly: in
> that case the hostp2m is d->arch.altp2m_p2m[0], which is take care of in
> the loop below the code you've quoted.
p2m_init_altp2m() (and other code in p2m.c) suggests otherwise to me.
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -360,11 +360,7 @@ void p2m_enable_hardware_log_dirty(struct domain *d)
>>> struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>>
>>> if ( p2m->enable_hardware_log_dirty )
>>> -{
>>> -p2m_lock(p2m);
>>> p2m->enable_hardware_log_dirty(p2m);
>>> -p2m_unlock(p2m);
>>> -}
>>> }
>>>
>>> void p2m_disable_hardware_log_dirty(struct domain *d)
>>> @@ -372,11 +368,7 @@ void p2m_disable_hardware_log_dirty(struct domain *d)
>>> struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>>
>>> if ( p2m->disable_hardware_log_dirty )
>>> -{
>>> -p2m_lock(p2m);
>>> p2m->disable_hardware_log_dirty(p2m);
>>> -p2m_unlock(p2m);
>>> -}
>>> }
>>
>> I don't understand how this removal can be correct.
>
> Do you mean because the lock is supposed to protect the
> vmx_domain_disable_pml(d); and vmx_domain_update_eptp(d); calls as well?
Not just there - I think you need to keep at least a read lock on
the host p2m until you've managed to update all the altp2m-s.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
On Fri, Sep 28, 2018 at 04:23:24PM +0100, Wei Liu wrote: > On Fri, Sep 28, 2018 at 09:19:56AM -0600, Jan Beulich wrote: > > >>> On 28.09.18 at 17:12, wrote: > > > On Fri, Sep 28, 2018 at 09:08:34AM -0600, Jan Beulich wrote: > > >> >>> On 28.09.18 at 10:24, wrote: > > >> > --- a/xen/drivers/char/console.c > > >> > +++ b/xen/drivers/char/console.c > > >> > @@ -91,7 +91,8 @@ static uint32_t conringc, conringp; > > >> > static int __read_mostly sercon_handle = -1; > > >> > > > >> > #ifdef CONFIG_X86 > > >> > -static bool __read_mostly opt_console_xen; /* console=xen */ > > >> > +/* Set to true at start of day to catch early boot issues */ > > >> > +static bool __read_mostly opt_console_xen = true; /* console=xen */ > > >> > > >> When Andrew suggested this, iirc he said to make the variable > > >> tristate. Otherwise ... > > > > > > I figure it doesn't need to be tristate. > > > > > >> > > >> > @@ -821,6 +822,10 @@ void __init console_init_preirq(void) > > >> > > > >> > serial_init_preirq(); > > >> > > > >> > +#ifdef CONFIG_X86 > > >> > +opt_console_xen = false; > > >> > +#endif > > >> > > >> ... you possibly override a user specified "true" here. > > > > > > Do I? This is right before option parsing, during which opt_console_xen > > > is set. > > > > Hmm, I see - I didn't recall we still have this ad hoc parsing in > > place, instead of using custom_param(). But isn't this too early then, > > as messages issued from the parsing code then would not be visible? > > To me it doesn't make anything worse than before. But I see your point. > I will see if there is an easy way to fix this. At the moment the ordering of the options matter, which means if "xen" is not the first option we can lose output. I think one easy way of improving is to parse opt_console twice. The first time solely looks for "xen" and the second time parses the rest options. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 09/11] pci: add vpci hooks for device addition/removal
>>> On 17.07.18 at 11:48, wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -768,6 +768,13 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
> goto out;
> }
>
> +ret = vpci_add_handlers(pdev);
> +if ( ret )
> +{
> +pdev->domain = NULL;
> +goto out;
> +}
> +
> list_add(>domain_list, _domain->arch.pdev_list);
> }
> else
> @@ -812,6 +819,7 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
> list_for_each_entry ( pdev, >alldevs_list, alldevs_list )
> if ( pdev->bus == bus && pdev->devfn == devfn )
> {
> +vpci_remove_device(pdev);
> ret = iommu_remove_device(pdev);
> if ( pdev->domain )
> list_del(>domain_list);
These should have been here even without SR-IOV in mind, as we don't
guarantee to find all devices during our boot time scan. Does this have
any dependencies on the earlier patches in the series? If not, I think it
should go in as soon as it's ready, independent of the rest of this series.
However, error handling in the "add" case looks wrong:
iommu_add_device() either needs undoing, or your call should be done
earlier (and its effects undone in case iommu_add_device() fails).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: correct purging of persistent grants
On 9/28/18 1:28 AM, Juergen Gross wrote:
> Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
> stale persistent grants") introduced a regression as purged persistent
> grants were not pu into the list of free grants again. Correct that.
I'll apply this for 4.19, and if things unexpectedly don't work out,
we can always revert the series next week.
--
Jens Axboe
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 08/11] vpci/header: allow multiple map operations
>>> On 17.07.18 at 11:48, wrote:
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -184,7 +184,19 @@ static void defer_map(struct domain *d, struct pci_dev
> *pdev,
> * started for the same device if the domain is not well-behaved.
> */
> curr->vpci.pdev = pdev;
> -curr->vpci.mem = mem;
> +if ( !curr->vpci.mem )
> +curr->vpci.mem = mem;
> +else
> +{
> +int rc = rangeset_merge(curr->vpci.mem, mem);
> +
> +if ( rc )
> +gprintk(XENLOG_WARNING,
> +"%04x:%02x:%02x.%u: unable to %smap memory region: %d\n",
> +pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> +PCI_FUNC(pdev->devfn), map ? "" : "un", rc);
> +rangeset_destroy(mem);
> +}
> curr->vpci.map = map;
> curr->vpci.rom_only = rom_only;
Is it certain that all other arguments match (pdev, map, rom_only)?
If so, please add ASSERT()s to that effect, and perhaps also half a
sentence to the description as to why that is guaranteed.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 06/11] vpci/header: add teardown cleanup
>>> On 17.07.18 at 11:48, wrote:
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -131,12 +131,15 @@ bool vpci_process_pending(struct vcpu *v)
> if ( rc == -ERESTART )
> return true;
>
> -spin_lock(>vpci.pdev->vpci_lock);
> -if ( v->vpci.pdev->vpci )
> -/* Disable memory decoding unconditionally on failure. */
> -modify_decoding(v->vpci.pdev, !rc && v->vpci.map,
> -!rc && v->vpci.rom_only);
> -spin_unlock(>vpci.pdev->vpci_lock);
> +if ( v->vpci.pdev )
> +{
> +spin_lock(>vpci.pdev->vpci_lock);
> +if ( v->vpci.pdev->vpci )
> +/* Disable memory decoding unconditionally on failure. */
> +modify_decoding(v->vpci.pdev, !rc && v->vpci.map,
> +!rc && v->vpci.rom_only);
> +spin_unlock(>vpci.pdev->vpci_lock);
> +}
>
> rangeset_destroy(v->vpci.mem);
> v->vpci.mem = NULL;
A few lines down from here there is
vpci_remove_device(v->vpci.pdev);
which I think has the same issue.
> @@ -560,7 +563,25 @@ static int init_bars(struct pci_dev *pdev)
>
> return (cmd & PCI_COMMAND_MEMORY) ? modify_bars(pdev, true, false) : 0;
> }
> -REGISTER_VPCI_INIT(init_bars, NULL, VPCI_PRIORITY_MIDDLE);
> +
> +static void teardown_bars(struct pci_dev *pdev)
> +{
> +uint16_t cmd = pci_conf_read16(pdev->seg, pdev->bus,
> PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn), PCI_COMMAND);
> +
> +if ( cmd & PCI_COMMAND_MEMORY )
> +{
> +/* Unmap all BARs from guest p2m. */
> +modify_bars(pdev, false, false);
> +/*
> + * Since this operation is deferred at the point when it finishes the
> + * device might have been removed, so don't attempt to disable memory
> + * decoding afterwards.
> + */
> +current->vpci.pdev = NULL;
Did you not mean to prefix the comment with FIXME: ? Ultimately
device removal should be delayed until all cleanup has been done,
imo.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools/libgnttab: Undo incorrect SONAME bump in c/s ee8105cab
On Fri, Sep 28, 2018 at 04:22:28PM +0100, Andrew Cooper wrote: > Xen 4.11 shipped with a SONAME of 1.1. > > For staging (and 4.12 eventually), the SONAME was bumped to 1.2 by c/s > 28ca696a3. Further changes before 4.12 ships should not bump the SONAME. > > Signed-off-by: Andrew Cooper Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/altp2m: propagate ept.ad changes to all active altp2ms
On 9/28/18 5:52 PM, Jan Beulich wrote:
On 28.09.18 at 13:55, wrote:
>> @@ -1218,34 +1219,67 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
>> ept_sync_domain_mask(p2m, p2m->domain->dirty_cpumask);
>> }
>>
>> +static void ept_set_ad_sync(struct p2m_domain *p2m, int value)
>
> Can the second parameter be bool please (and the true/false
> arguments in the callers)?
Of course.
>> +{
>> +struct domain *d = p2m->domain;
>> +unsigned int i;
>> +
>> +if ( likely(!altp2m_active(d)) )
>> +{
>> +p2m_lock(p2m);
>> +p2m->ept.ad = value;
>> +p2m_unlock(p2m);
>> +
>> +return;
>> +}
>
> Why would you want to skip updating the host p2m's flag when
> altp2m is active?
It's not really skipped if I understand the altp2m code correctly: in
that case the hostp2m is d->arch.altp2m_p2m[0], which is take care of in
the loop below the code you've quoted.
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -360,11 +360,7 @@ void p2m_enable_hardware_log_dirty(struct domain *d)
>> struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>
>> if ( p2m->enable_hardware_log_dirty )
>> -{
>> -p2m_lock(p2m);
>> p2m->enable_hardware_log_dirty(p2m);
>> -p2m_unlock(p2m);
>> -}
>> }
>>
>> void p2m_disable_hardware_log_dirty(struct domain *d)
>> @@ -372,11 +368,7 @@ void p2m_disable_hardware_log_dirty(struct domain *d)
>> struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>
>> if ( p2m->disable_hardware_log_dirty )
>> -{
>> -p2m_lock(p2m);
>> p2m->disable_hardware_log_dirty(p2m);
>> -p2m_unlock(p2m);
>> -}
>> }
>
> I don't understand how this removal can be correct.
Do you mean because the lock is supposed to protect the
vmx_domain_disable_pml(d); and vmx_domain_update_eptp(d); calls as well?
Otherwise, I've removed them because the locking is now done in
ept_set_ad_sync().
I had hoped that would address the following comments from George from a
previous RFC patch:
"> static void ept_enable_pml(struct p2m_domain *p2m)
> {
> +unsigned int i;
> +struct domain *d = p2m->domain;
> +
> /* Domain must have been paused */
> -ASSERT(atomic_read(>domain->pause_count));
> +ASSERT(atomic_read(>pause_count));
>
> /*
> * No need to return whether vmx_domain_enable_pml has succeeded, as
> * ept_p2m_type_to_flags will do the check, and write protection
will be
> * used if PML is not enabled.
> */
> -if ( vmx_domain_enable_pml(p2m->domain) )
> +if ( vmx_domain_enable_pml(d) )
> return;
>
> /* Enable EPT A/D bit for PML */
> p2m->ept.ad = 1;
> -vmx_domain_update_eptp(p2m->domain);
> +
> +if ( altp2m_active(d) )
> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +{
> +if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
> +continue;
> +
> +p2m = d->arch.altp2m_p2m[i];
> +p2m->ept.ad = 1;
> +}
You're not grabbing the respective p2m locks here -- I'm pretty sure
this will end up being three separate instructions (read, set ad bit,
write).
But there would something a bit funny here about grabbing the main p2m
lock in p2m.c, and then grabbing altp2m locks within the function. But
on the other hand, you clearly only want to call this...
> +vmx_domain_update_eptp(d);
...once. Some refactoring might be wanted."
Hence my refactoring attempt.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
On Fri, Sep 28, 2018 at 09:19:56AM -0600, Jan Beulich wrote: > >>> On 28.09.18 at 17:12, wrote: > > On Fri, Sep 28, 2018 at 09:08:34AM -0600, Jan Beulich wrote: > >> >>> On 28.09.18 at 10:24, wrote: > >> > --- a/xen/drivers/char/console.c > >> > +++ b/xen/drivers/char/console.c > >> > @@ -91,7 +91,8 @@ static uint32_t conringc, conringp; > >> > static int __read_mostly sercon_handle = -1; > >> > > >> > #ifdef CONFIG_X86 > >> > -static bool __read_mostly opt_console_xen; /* console=xen */ > >> > +/* Set to true at start of day to catch early boot issues */ > >> > +static bool __read_mostly opt_console_xen = true; /* console=xen */ > >> > >> When Andrew suggested this, iirc he said to make the variable > >> tristate. Otherwise ... > > > > I figure it doesn't need to be tristate. > > > >> > >> > @@ -821,6 +822,10 @@ void __init console_init_preirq(void) > >> > > >> > serial_init_preirq(); > >> > > >> > +#ifdef CONFIG_X86 > >> > +opt_console_xen = false; > >> > +#endif > >> > >> ... you possibly override a user specified "true" here. > > > > Do I? This is right before option parsing, during which opt_console_xen > > is set. > > Hmm, I see - I didn't recall we still have this ad hoc parsing in > place, instead of using custom_param(). But isn't this too early then, > as messages issued from the parsing code then would not be visible? To me it doesn't make anything worse than before. But I see your point. I will see if there is an easy way to fix this. Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tools/libgnttab: Undo incorrect SONAME bump in c/s ee8105cab
Xen 4.11 shipped with a SONAME of 1.1.
For staging (and 4.12 eventually), the SONAME was bumped to 1.2 by c/s
28ca696a3. Further changes before 4.12 ships should not bump the SONAME.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Oleksandr Andrushchenko
---
tools/libs/gnttab/Makefile | 2 +-
tools/libs/gnttab/libxengnttab.map | 4
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/tools/libs/gnttab/Makefile b/tools/libs/gnttab/Makefile
index 0befbd1..6c2e7e3 100644
--- a/tools/libs/gnttab/Makefile
+++ b/tools/libs/gnttab/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
include $(XEN_ROOT)/tools/Rules.mk
MAJOR= 1
-MINOR= 3
+MINOR= 2
SHLIB_LDFLAGS += -Wl,--version-script=libxengnttab.map
CFLAGS += -Werror -Wmissing-prototypes
diff --git a/tools/libs/gnttab/libxengnttab.map
b/tools/libs/gnttab/libxengnttab.map
index 9de2183..e15f6e9 100644
--- a/tools/libs/gnttab/libxengnttab.map
+++ b/tools/libs/gnttab/libxengnttab.map
@@ -31,10 +31,6 @@ VERS_1.2 {
global:
xengnttab_fd;
xengntshr_fd;
-} VERS_1.1;
-
-VERS_1.3 {
- global:
xengnttab_dmabuf_exp_from_refs;
xengnttab_dmabuf_exp_wait_released;
xengnttab_dmabuf_imp_to_refs;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
>>> On 28.09.18 at 17:12, wrote: > On Fri, Sep 28, 2018 at 09:08:34AM -0600, Jan Beulich wrote: >> >>> On 28.09.18 at 10:24, wrote: >> > --- a/xen/drivers/char/console.c >> > +++ b/xen/drivers/char/console.c >> > @@ -91,7 +91,8 @@ static uint32_t conringc, conringp; >> > static int __read_mostly sercon_handle = -1; >> > >> > #ifdef CONFIG_X86 >> > -static bool __read_mostly opt_console_xen; /* console=xen */ >> > +/* Set to true at start of day to catch early boot issues */ >> > +static bool __read_mostly opt_console_xen = true; /* console=xen */ >> >> When Andrew suggested this, iirc he said to make the variable >> tristate. Otherwise ... > > I figure it doesn't need to be tristate. > >> >> > @@ -821,6 +822,10 @@ void __init console_init_preirq(void) >> > >> > serial_init_preirq(); >> > >> > +#ifdef CONFIG_X86 >> > +opt_console_xen = false; >> > +#endif >> >> ... you possibly override a user specified "true" here. > > Do I? This is right before option parsing, during which opt_console_xen > is set. Hmm, I see - I didn't recall we still have this ad hoc parsing in place, instead of using custom_param(). But isn't this too early then, as messages issued from the parsing code then would not be visible? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
On Fri, Sep 28, 2018 at 04:13:51PM +0100, Andrew Cooper wrote: > On 28/09/18 16:12, Wei Liu wrote: > > On Fri, Sep 28, 2018 at 09:08:34AM -0600, Jan Beulich wrote: > > On 28.09.18 at 10:24, wrote: > >>> --- a/xen/drivers/char/console.c > >>> +++ b/xen/drivers/char/console.c > >>> @@ -91,7 +91,8 @@ static uint32_t conringc, conringp; > >>> static int __read_mostly sercon_handle = -1; > >>> > >>> #ifdef CONFIG_X86 > >>> -static bool __read_mostly opt_console_xen; /* console=xen */ > >>> +/* Set to true at start of day to catch early boot issues */ > >>> +static bool __read_mostly opt_console_xen = true; /* console=xen */ > >> When Andrew suggested this, iirc he said to make the variable > >> tristate. Otherwise ... > > I figure it doesn't need to be tristate. > > > >>> @@ -821,6 +822,10 @@ void __init console_init_preirq(void) > >>> > >>> serial_init_preirq(); > >>> > >>> +#ifdef CONFIG_X86 > >>> +opt_console_xen = false; > >>> +#endif > >> ... you possibly override a user specified "true" here. > > Do I? This is right before option parsing, during which opt_console_xen > > is set. > > This is fine in principle, but you can't initialise it to true at > compile time, or native boots will try using hypercalls / port 0xe9. > > The best bet is to set it to true in the PVH entry asm. Right. I will set it in the PVH entry instead. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 128173: tolerable all pass - PUSHED
flight 128173 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/128173/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen c62c53d61477dfeb63a47b0673c389082112babc baseline version: xen a8c7e309d1fec898a2731b6e0f63d66c509c7233 Last test of basis 128152 2018-09-28 00:00:44 Z0 days Testing same since 128173 2018-09-28 13:02:37 Z0 days1 attempts People who touched revisions under test: George Dunlap Ian Jackson Samuel Thibault jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git a8c7e309d1..c62c53d614 c62c53d61477dfeb63a47b0673c389082112babc -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
On 28/09/18 16:12, Wei Liu wrote: > On Fri, Sep 28, 2018 at 09:08:34AM -0600, Jan Beulich wrote: > On 28.09.18 at 10:24, wrote: >>> --- a/xen/drivers/char/console.c >>> +++ b/xen/drivers/char/console.c >>> @@ -91,7 +91,8 @@ static uint32_t conringc, conringp; >>> static int __read_mostly sercon_handle = -1; >>> >>> #ifdef CONFIG_X86 >>> -static bool __read_mostly opt_console_xen; /* console=xen */ >>> +/* Set to true at start of day to catch early boot issues */ >>> +static bool __read_mostly opt_console_xen = true; /* console=xen */ >> When Andrew suggested this, iirc he said to make the variable >> tristate. Otherwise ... > I figure it doesn't need to be tristate. > >>> @@ -821,6 +822,10 @@ void __init console_init_preirq(void) >>> >>> serial_init_preirq(); >>> >>> +#ifdef CONFIG_X86 >>> +opt_console_xen = false; >>> +#endif >> ... you possibly override a user specified "true" here. > Do I? This is right before option parsing, during which opt_console_xen > is set. This is fine in principle, but you can't initialise it to true at compile time, or native boots will try using hypercalls / port 0xe9. The best bet is to set it to true in the PVH entry asm. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86: make sure module array is large enough in pvh-boot.c
On Fri, Sep 28, 2018 at 09:06:25AM -0600, Jan Beulich wrote: > >>> On 28.09.18 at 10:24, wrote: > > The relocation code in __start_xen requires one extra element in the > > module array. By the looks of it the temporary array is already large > > enough. Add a BUG_ON to catch any issue in the future. > > > > While at it, turn another ASSERT to BUG_ON as well. > > Hmm, a little strange - I thought we had agreed on panic() before. > The extra output BUG_ON() produces is unlikely to be helpful here. > With this switched to panic() it certainly can have my ack. Oops, I have no idea why I agreed to use panic but wrote BUG_ON instead. My memory has failed me. I will resend this patch. Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
On Fri, Sep 28, 2018 at 09:08:34AM -0600, Jan Beulich wrote: > >>> On 28.09.18 at 10:24, wrote: > > --- a/xen/drivers/char/console.c > > +++ b/xen/drivers/char/console.c > > @@ -91,7 +91,8 @@ static uint32_t conringc, conringp; > > static int __read_mostly sercon_handle = -1; > > > > #ifdef CONFIG_X86 > > -static bool __read_mostly opt_console_xen; /* console=xen */ > > +/* Set to true at start of day to catch early boot issues */ > > +static bool __read_mostly opt_console_xen = true; /* console=xen */ > > When Andrew suggested this, iirc he said to make the variable > tristate. Otherwise ... I figure it doesn't need to be tristate. > > > @@ -821,6 +822,10 @@ void __init console_init_preirq(void) > > > > serial_init_preirq(); > > > > +#ifdef CONFIG_X86 > > +opt_console_xen = false; > > +#endif > > ... you possibly override a user specified "true" here. Do I? This is right before option parsing, during which opt_console_xen is set. Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/2] x86: undefine BOOSTRAP_MAP_LIMIT after its last user
>>> On 28.09.18 at 10:39, wrote: > Requested-by: Jan Beulich > Signed-off-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/2] x86: fix comment on super page alignment requirement
>>> On 28.09.18 at 10:39, wrote: > BOOTSTRAP_DIRECTMAP_END is gone. The comment in question should refer > to BOOSTRAP_MAP_BASE and 4GB instead. > > Move the entire comment block to where it belongs -- immediately > before the loop which does the things said in the comment. > > Remove two trailing spaces while at it. > > Signed-off-by: Wei Liu I guess it's good enough this way for now, so Acked-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
>>> On 28.09.18 at 10:24, wrote: > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -91,7 +91,8 @@ static uint32_t conringc, conringp; > static int __read_mostly sercon_handle = -1; > > #ifdef CONFIG_X86 > -static bool __read_mostly opt_console_xen; /* console=xen */ > +/* Set to true at start of day to catch early boot issues */ > +static bool __read_mostly opt_console_xen = true; /* console=xen */ When Andrew suggested this, iirc he said to make the variable tristate. Otherwise ... > @@ -821,6 +822,10 @@ void __init console_init_preirq(void) > > serial_init_preirq(); > > +#ifdef CONFIG_X86 > +opt_console_xen = false; > +#endif ... you possibly override a user specified "true" here. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86: make sure module array is large enough in pvh-boot.c
>>> On 28.09.18 at 10:24, wrote: > The relocation code in __start_xen requires one extra element in the > module array. By the looks of it the temporary array is already large > enough. Add a BUG_ON to catch any issue in the future. > > While at it, turn another ASSERT to BUG_ON as well. Hmm, a little strange - I thought we had agreed on panic() before. The extra output BUG_ON() produces is unlikely to be helpful here. With this switched to panic() it certainly can have my ack. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RFC] mm/memory_hotplug: Introduce memory block types
How to/when to online hotplugged memory is hard to manage for
distributions because different memory types are to be treated differently.
Right now, we need complicated udev rules that e.g. check if we are
running on s390x, on a physical system or on a virtualized system. But
there is also sometimes the demand to really online memory immediately
while adding in the kernel and not to wait for user space to make a
decision. And on virtualized systems there might be different
requirements, depending on "how" the memory was added (and if it will
eventually get unplugged again - DIMM vs. paravirtualized mechanisms).
On the one hand, we have physical systems where we sometimes
want to be able to unplug memory again - e.g. a DIMM - so we have to online
it to the MOVABLE zone optionally. That decision is usually made in user
space.
On the other hand, we have memory that should never be onlined
automatically, only when asked for by an administrator. Such memory only
applies to virtualized environments like s390x, where the concept of
"standby" memory exists. Memory is detected and added during boot, so it
can be onlined when requested by the admininistrator or some tooling.
Only when onlining, memory will be allocated in the hypervisor.
But then, we also have paravirtualized devices (namely xen and hyper-v
balloons), that hotplug memory that will never ever be removed from a
system right now using offline_pages/remove_memory. If at all, this memory
is logically unplugged and handed back to the hypervisor via ballooning.
For paravirtualized devices it is relevant that memory is onlined as
quickly as possible after adding - and that it is added to the NORMAL
zone. Otherwise, it could happen that too much memory in a row is added
(but not onlined), resulting in out-of-memory conditions due to the
additional memory for "struct pages" and friends. MOVABLE zone as well
as delays might be very problematic and lead to crashes (e.g. zone
imbalance).
Therefore, introduce memory block types and online memory depending on
it when adding the memory. Expose the memory type to user space, so user
space handlers can start to process only "normal" memory. Other memory
block types can be ignored. One thing less to worry about in user space.
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Greg Kroah-Hartman
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: "Jérôme Glisse"
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Dan Williams
Cc: Stephen Rothwell
Cc: Michal Hocko
Cc: "Kirill A. Shutemov"
Cc: David Hildenbrand
Cc: Nicholas Piggin
Cc: "Jonathan Neuschäfer"
Cc: Joe Perches
Cc: Michael Neuling
Cc: Mauricio Faria de Oliveira
Cc: Balbir Singh
Cc: Rashmica Gupta
Cc: Pavel Tatashin
Cc: Rob Herring
Cc: Philippe Ombredanne
Cc: Kate Stewart
Cc: "mike.tra...@hpe.com"
Cc: Joonsoo Kim
Cc: Oscar Salvador
Cc: Mathieu Malaterre
Signed-off-by: David Hildenbrand
---
This patch is based on the current mm-tree, where some related
patches from me are currently residing that touched the add_memory()
functions.
arch/ia64/mm/init.c | 4 +-
arch/powerpc/mm/mem.c | 4 +-
arch/powerpc/platforms/powernv/memtrace.c | 3 +-
arch/s390/mm/init.c | 4 +-
arch/sh/mm/init.c | 4 +-
arch/x86/mm/init_32.c | 4 +-
arch/x86/mm/init_64.c | 8 +--
drivers/acpi/acpi_memhotplug.c| 3 +-
drivers/base/memory.c | 63 ---
drivers/hv/hv_balloon.c | 33 ++--
drivers/s390/char/sclp_cmd.c | 3 +-
drivers/xen/balloon.c | 2 +-
include/linux/memory.h| 28 +-
include/linux/memory_hotplug.h| 17 +++---
mm/hmm.c | 6 ++-
mm/memory_hotplug.c | 31 ++-
16 files changed, 139 insertions(+), 78 deletions(-)
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index d5e12ff1d73c..813d1d86bf95 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -646,13 +646,13 @@ mem_init (void)
#ifdef CONFIG_MEMORY_HOTPLUG
int arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
- bool want_memblock)
+ int memory_block_type)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
- ret = __add_pages(nid, start_pfn, nr_pages, altmap, want_memblock);
+ ret = __add_pages(nid, start_pfn, nr_pages, altmap,
Re: [Xen-devel] [PATCH] tools/configure: Drop libgcrypt detection
On Fri, Sep 28, 2018 at 03:51:35PM +0100, Andrew Cooper wrote: > This was last used by blktap1, which was deleted by c/s f6bcc035084 in 2014. > > Signed-off-by: Andrew Cooper Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/altp2m: propagate ept.ad changes to all active altp2ms
>>> On 28.09.18 at 13:55, wrote:
> @@ -1218,34 +1219,67 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
> ept_sync_domain_mask(p2m, p2m->domain->dirty_cpumask);
> }
>
> +static void ept_set_ad_sync(struct p2m_domain *p2m, int value)
Can the second parameter be bool please (and the true/false
arguments in the callers)?
> +{
> +struct domain *d = p2m->domain;
> +unsigned int i;
> +
> +if ( likely(!altp2m_active(d)) )
> +{
> +p2m_lock(p2m);
> +p2m->ept.ad = value;
> +p2m_unlock(p2m);
> +
> +return;
> +}
Why would you want to skip updating the host p2m's flag when
altp2m is active?
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -360,11 +360,7 @@ void p2m_enable_hardware_log_dirty(struct domain *d)
> struct p2m_domain *p2m = p2m_get_hostp2m(d);
>
> if ( p2m->enable_hardware_log_dirty )
> -{
> -p2m_lock(p2m);
> p2m->enable_hardware_log_dirty(p2m);
> -p2m_unlock(p2m);
> -}
> }
>
> void p2m_disable_hardware_log_dirty(struct domain *d)
> @@ -372,11 +368,7 @@ void p2m_disable_hardware_log_dirty(struct domain *d)
> struct p2m_domain *p2m = p2m_get_hostp2m(d);
>
> if ( p2m->disable_hardware_log_dirty )
> -{
> -p2m_lock(p2m);
> p2m->disable_hardware_log_dirty(p2m);
> -p2m_unlock(p2m);
> -}
> }
I don't understand how this removal can be correct.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tools/configure: Drop libgcrypt detection
This was last used by blktap1, which was deleted by c/s f6bcc035084 in 2014.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
config/Tools.mk.in | 1 -
tools/configure| 44
tools/configure.ac | 2 --
3 files changed, 47 deletions(-)
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index bdba087..1e5cc20 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -69,7 +69,6 @@ LINUX_BACKEND_MODULES := @LINUX_BACKEND_MODULES@
#System options
ZLIB:= @zlib@
CONFIG_LIBICONV := @libiconv@
-CONFIG_GCRYPT := @libgcrypt@
EXTFS_LIBS := @EXTFS_LIBS@
CURSES_LIBS := @CURSES_LIBS@
TINFO_LIBS := @TINFO_LIBS@
diff --git a/tools/configure b/tools/configure
index acbcf9e..acc8575 100755
--- a/tools/configure
+++ b/tools/configure
@@ -639,7 +639,6 @@ PTYFUNCS_LIBS
PTHREAD_LIBS
PTHREAD_LDFLAGS
PTHREAD_CFLAGS
-libgcrypt
EXTFS_LIBS
system_aio
zlib
@@ -8624,49 +8623,6 @@ fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for gcry_md_hash_buffer in
-lgcrypt" >&5
-$as_echo_n "checking for gcry_md_hash_buffer in -lgcrypt... " >&6; }
-if ${ac_cv_lib_gcrypt_gcry_md_hash_buffer+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-lgcrypt $LIBS"
-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h. */
-
-/* Override any GCC internal prototype to avoid an error.
- Use char because int might match the return type of a GCC
- builtin and then its argument prototype would still apply. */
-#ifdef __cplusplus
-extern "C"
-#endif
-char gcry_md_hash_buffer ();
-int
-main ()
-{
-return gcry_md_hash_buffer ();
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_link "$LINENO"; then :
- ac_cv_lib_gcrypt_gcry_md_hash_buffer=yes
-else
- ac_cv_lib_gcrypt_gcry_md_hash_buffer=no
-fi
-rm -f core conftest.err conftest.$ac_objext \
-conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&5
-$as_echo "$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&6; }
-if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" = xyes; then :
- libgcrypt="y"
-else
- libgcrypt="n"
-fi
-
-
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread flag" >&5
$as_echo_n "checking for pthread flag... " >&6; }
diff --git a/tools/configure.ac b/tools/configure.ac
index e7d2e6f..1499344 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -407,8 +407,6 @@ AC_CHECK_LIB([aio], [io_setup], [], [AC_MSG_ERROR([Could
not find libaio])])
])
AC_SUBST(system_aio)
AX_CHECK_EXTFS
-AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
-AC_SUBST(libgcrypt)
AX_CHECK_PTHREAD
AX_CHECK_PTYFUNCS
AC_CHECK_LIB([yajl], [yajl_alloc], [],
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tools: remove libgcrypt check
Its user blktap is long gone in f6bcc035 ("tools: remove blktap1").
Reported-by: Cc: Andrew Cooper
Signed-off-by: Wei Liu
---
config/Tools.mk.in | 1 -
tools/configure| 44
tools/configure.ac | 2 --
3 files changed, 47 deletions(-)
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index bdba087af0..1e5cc20bf7 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -69,7 +69,6 @@ LINUX_BACKEND_MODULES := @LINUX_BACKEND_MODULES@
#System options
ZLIB:= @zlib@
CONFIG_LIBICONV := @libiconv@
-CONFIG_GCRYPT := @libgcrypt@
EXTFS_LIBS := @EXTFS_LIBS@
CURSES_LIBS := @CURSES_LIBS@
TINFO_LIBS := @TINFO_LIBS@
diff --git a/tools/configure b/tools/configure
index acbcf9eb3e..acc857510e 100755
--- a/tools/configure
+++ b/tools/configure
@@ -639,7 +639,6 @@ PTYFUNCS_LIBS
PTHREAD_LIBS
PTHREAD_LDFLAGS
PTHREAD_CFLAGS
-libgcrypt
EXTFS_LIBS
system_aio
zlib
@@ -8624,49 +8623,6 @@ fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for gcry_md_hash_buffer in
-lgcrypt" >&5
-$as_echo_n "checking for gcry_md_hash_buffer in -lgcrypt... " >&6; }
-if ${ac_cv_lib_gcrypt_gcry_md_hash_buffer+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-lgcrypt $LIBS"
-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h. */
-
-/* Override any GCC internal prototype to avoid an error.
- Use char because int might match the return type of a GCC
- builtin and then its argument prototype would still apply. */
-#ifdef __cplusplus
-extern "C"
-#endif
-char gcry_md_hash_buffer ();
-int
-main ()
-{
-return gcry_md_hash_buffer ();
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_link "$LINENO"; then :
- ac_cv_lib_gcrypt_gcry_md_hash_buffer=yes
-else
- ac_cv_lib_gcrypt_gcry_md_hash_buffer=no
-fi
-rm -f core conftest.err conftest.$ac_objext \
-conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&5
-$as_echo "$ac_cv_lib_gcrypt_gcry_md_hash_buffer" >&6; }
-if test "x$ac_cv_lib_gcrypt_gcry_md_hash_buffer" = xyes; then :
- libgcrypt="y"
-else
- libgcrypt="n"
-fi
-
-
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for pthread flag" >&5
$as_echo_n "checking for pthread flag... " >&6; }
diff --git a/tools/configure.ac b/tools/configure.ac
index e7d2e6f4ff..1499344ce6 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -407,8 +407,6 @@ AC_CHECK_LIB([aio], [io_setup], [], [AC_MSG_ERROR([Could
not find libaio])])
])
AC_SUBST(system_aio)
AX_CHECK_EXTFS
-AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
-AC_SUBST(libgcrypt)
AX_CHECK_PTHREAD
AX_CHECK_PTYFUNCS
AC_CHECK_LIB([yajl], [yajl_alloc], [],
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: correct purging of persistent grants
On 9/28/18 9:52 AM, Juergen Gross wrote:
> On 28/09/2018 15:33, Boris Ostrovsky wrote:
>> On 9/28/18 9:13 AM, Juergen Gross wrote:
>>> On 28/09/2018 14:45, Boris Ostrovsky wrote:
On 9/28/18 3:28 AM, Juergen Gross wrote:
> Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
> stale persistent grants") introduced a regression as purged persistent
> grants were not pu into the list of free grants again. Correct that.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/block/xen-blkfront.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index a71d817e900d..429d20131c7e 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2670,8 +2670,8 @@ static void purge_persistent_grants(struct
> blkfront_info *info)
> list_del(_list_entry->node);
> gnttab_end_foreign_access(gnt_list_entry->gref, 0, 0UL);
> rinfo->persistent_gnts_c--;
> - __free_page(gnt_list_entry->page);
> - kfree(gnt_list_entry);
> + gnt_list_entry->gref = GRANT_INVALID_REF;
> + list_add_tail(_list_entry->node, >grants);
Sorry, I don't follow this. What is the purpose of removing the grant
from rinfo->grants list with list_del() and then adding it back with
list_add_tail()?
>>> The persistent grants are at the list head and the non-persistent ones
>>> at the tail.
>> Oh, I didn't realize that. But isn't that an optimization (and so not
>> following this rule should not cause errors)?
> In theory: yes.
>
> The persistent grant handling is rather complicated so I'd like to make
> sure not to deviate from the common standards.
I am not arguing with correctness of your patch, so
Reviewed-by: Boris Ostrovsky
but I am a little surprised that it fixes Sander's problem.
-boris
>
> When I find some time I want to modify the persistent grant handling to
> be more explicit and controlled completely by the frontend (within the
> backend defined limits, of course). Until then we should try to modify
> persistent grants not too much IMO.
>
>
> Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: correct purging of persistent grants
On 28/09/2018 15:33, Boris Ostrovsky wrote:
> On 9/28/18 9:13 AM, Juergen Gross wrote:
>> On 28/09/2018 14:45, Boris Ostrovsky wrote:
>>> On 9/28/18 3:28 AM, Juergen Gross wrote:
Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
stale persistent grants") introduced a regression as purged persistent
grants were not pu into the list of free grants again. Correct that.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index a71d817e900d..429d20131c7e 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2670,8 +2670,8 @@ static void purge_persistent_grants(struct
blkfront_info *info)
list_del(_list_entry->node);
gnttab_end_foreign_access(gnt_list_entry->gref, 0, 0UL);
rinfo->persistent_gnts_c--;
- __free_page(gnt_list_entry->page);
- kfree(gnt_list_entry);
+ gnt_list_entry->gref = GRANT_INVALID_REF;
+ list_add_tail(_list_entry->node, >grants);
>>> Sorry, I don't follow this. What is the purpose of removing the grant
>>> from rinfo->grants list with list_del() and then adding it back with
>>> list_add_tail()?
>> The persistent grants are at the list head and the non-persistent ones
>> at the tail.
>
> Oh, I didn't realize that. But isn't that an optimization (and so not
> following this rule should not cause errors)?
In theory: yes.
The persistent grant handling is rather complicated so I'd like to make
sure not to deviate from the common standards.
When I find some time I want to modify the persistent grant handling to
be more explicit and controlled completely by the frontend (within the
backend defined limits, of course). Until then we should try to modify
persistent grants not too much IMO.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation
Am Thu, 13 Sep 2018 09:39:13 +0200 schrieb Olaf Hering : > this patch was not applied yet, even after a few "pings". No reaction since months. So scrap that patch, just in case it is still part of someones to-consider queue. Olaf pgpFtD6Pj968F.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 128163: all pass - PUSHED
flight 128163 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/128163/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b9cee524e6c1941b77b6780e19bd57052e53249c baseline version: ovmf 6532fdec11d7940a584a73797b5cc067d64f84a5 Last test of basis 128143 2018-09-27 17:52:19 Z0 days Testing same since 128163 2018-09-28 08:02:47 Z0 days1 attempts People who touched revisions under test: Chasel Chiu Chasel, Chiu Dongao Guo Guo, Dongao Jian J Wang Jiaxin Wu shenglei Star Zeng Wu Jiaxin jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 6532fdec11..b9cee524e6 b9cee524e6c1941b77b6780e19bd57052e53249c -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
On 28/09/2018 14:55, Omkar Bolla wrote: > Hi, > I tried to run script after pause the domain and unpause domain after > run script. But I ended up with same error I looked at the script again, it is wrong. The permissions should be set for each node under the root path of the respective domains, the first permission should be "n$domid" ($domid is the owner who can always read/write, the n is "no access" for all domains not explicitly listed), the second permission should be "r$domid" as the other side should be able to read only. In order to do it correctly the script should be: #!/bin/bash DOMU_ID=$1 if [ -z "$DOMU_ID" ]; then echo "Usage: $0 [domU ID]]" echo echo "Connects the new device, with dom0 as backend, domU as frontend" exit 1 fi # Pause domU as a script can't write an entry and set permission # in a single operation. xl pause $DOMU_ID DEVICE=mydevice DOMU_KEY=/local/domain/$DOMU_ID/device/$DEVICE/0 DOM0_KEY=/local/domain/0/backend/$DEVICE/$DOMU_ID/0 # Tell the domU about the new device and its backend xenstore-write $DOMU_KEY/backend-id 0 xenstore-write $DOMU_KEY/backend "/local/domain/0/backend/$DEVICE/$DOMU_ID/0" # Tell the dom0 about the new device and its frontend xenstore-write $DOM0_KEY/frontend-id $DOMU_ID xenstore-write $DOM0_KEY/frontend "/local/domain/$DOMU_ID/device/$DEVICE/0" # Activate the device, dom0 needs to be activated last xenstore-write $DOMU_KEY/state 1 xenstore-write $DOM0_KEY/state 1 # Make sure the domU can read the dom0 data xenstore-chmod -r $DOM0_KEY n0 r$DOMU_ID xenstore-chmod -r $DOMU_KEY n$DOMU_ID r0 xl unpause $DOMU_ID Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 128127: regressions - trouble: blocked/broken/fail/pass
flight 128127 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/128127/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd broken test-armhf-armhf-xl-vhd 10 debian-di-install fail in 128096 REGR. vs. 127486 Tests which are failing intermittently (not blocking): test-amd64-i386-qemut-rhel6hvm-amd 4 host-install(4)broken pass in 128096 test-armhf-armhf-xl-vhd 7 xen-boot fail pass in 128096 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 127486 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 127486 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 127486 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 127486 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 127486 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 127486 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass build-arm64-pvops 6 kernel-build fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linux921b2fed6a79439ef1609ef4af0ada5cccb3555c baseline version: linuxc0305995d3676c8f7764eb79a7f99de8d18c591a Last test of basis 127486 2018-09-10 23:39:53 Z 17 days Testing same since 128096 2018-09-26 06:42:33 Z2 days2 attempts People who touched revisions under test: Aaron Knister Adam Radford Alan Stern Aleh Filipovich Aleh Filipovich Alexandre Belloni Amit Pundir Anatoly Trosinenko Andreas Gruenbacher Andrew Morton
Re: [Xen-devel] [PATCH] xen/blkfront: correct purging of persistent grants
On 9/28/18 9:13 AM, Juergen Gross wrote:
> On 28/09/2018 14:45, Boris Ostrovsky wrote:
>> On 9/28/18 3:28 AM, Juergen Gross wrote:
>>> Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
>>> stale persistent grants") introduced a regression as purged persistent
>>> grants were not pu into the list of free grants again. Correct that.
>>>
>>> Signed-off-by: Juergen Gross
>>> ---
>>> drivers/block/xen-blkfront.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>>> index a71d817e900d..429d20131c7e 100644
>>> --- a/drivers/block/xen-blkfront.c
>>> +++ b/drivers/block/xen-blkfront.c
>>> @@ -2670,8 +2670,8 @@ static void purge_persistent_grants(struct
>>> blkfront_info *info)
>>> list_del(_list_entry->node);
>>> gnttab_end_foreign_access(gnt_list_entry->gref, 0, 0UL);
>>> rinfo->persistent_gnts_c--;
>>> - __free_page(gnt_list_entry->page);
>>> - kfree(gnt_list_entry);
>>> + gnt_list_entry->gref = GRANT_INVALID_REF;
>>> + list_add_tail(_list_entry->node, >grants);
>> Sorry, I don't follow this. What is the purpose of removing the grant
>> from rinfo->grants list with list_del() and then adding it back with
>> list_add_tail()?
> The persistent grants are at the list head and the non-persistent ones
> at the tail.
Oh, I didn't realize that. But isn't that an optimization (and so not
following this rule should not cause errors)?
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 128118: regressions - FAIL
flight 128118 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/128118/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 128084 test-amd64-i386-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 128084 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. vs. 128084 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128084 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128084 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128084 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128084 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128084 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128084 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 128084 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 128084 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128084 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen c759fb5bc303411e70322948a6ced81b6219ad3a baseline version: xen 940185b2f6f343251c2b83bd96e599398cea51ec Last test of basis 128084 2018-09-26 01:51:53 Z2 days Testing same since 128118 2018-09-27 00:37:03 Z1 days1 attempts People who touched revisions under test: Alexandru Isaila Amit Singh Tomar Andrew Cooper Christopher Clark Dario Faggioli Doug Goldstein George Dunlap Jan Beulich Julien Grall Razvan Cojocaru Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-amd64-xsm
Re: [Xen-devel] [PATCH] xen/blkfront: correct purging of persistent grants
On 28/09/2018 14:45, Boris Ostrovsky wrote:
> On 9/28/18 3:28 AM, Juergen Gross wrote:
>> Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
>> stale persistent grants") introduced a regression as purged persistent
>> grants were not pu into the list of free grants again. Correct that.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> drivers/block/xen-blkfront.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index a71d817e900d..429d20131c7e 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -2670,8 +2670,8 @@ static void purge_persistent_grants(struct
>> blkfront_info *info)
>> list_del(_list_entry->node);
>> gnttab_end_foreign_access(gnt_list_entry->gref, 0, 0UL);
>> rinfo->persistent_gnts_c--;
>> -__free_page(gnt_list_entry->page);
>> -kfree(gnt_list_entry);
>> +gnt_list_entry->gref = GRANT_INVALID_REF;
>> +list_add_tail(_list_entry->node, >grants);
>
> Sorry, I don't follow this. What is the purpose of removing the grant
> from rinfo->grants list with list_del() and then adding it back with
> list_add_tail()?
The persistent grants are at the list head and the non-persistent ones
at the tail.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen performance related work needed
Hi there! In a possible scenario where I (and a whole academic team) could work on improving Xen, what are the major areas requiring exploration/optimizations? Ideally, part that would be not that hard to work on, but allow high potential "reward". From my perspective, storage is probably a side that could be massively improved, but it's only based on my perception of Xen (especially on NVMe drives, where IOPS are high and latency small). So this question had a broad spectrum: in your opinion, the best ratio between effort and reward to improve perfs in general (could be storage, network, compute). I know security impact since side channel attack is huge, so it could be interesting to have new contributors more focused directly on perfs/optimizations. Any ideas and pointers toward those areas are welcome! Best, Oliver ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/6] docs/qemu-deprivilege: Revise and update with status and future plans
On Fri, Sep 28, 2018 at 12:37:22PM +0100, George Dunlap wrote: > On Tue, Sep 25, 2018 at 12:20 PM Anthony PERARD > wrote: > > > > On Fri, Sep 21, 2018 at 06:04:23PM +0100, George Dunlap wrote: > > > +## Migration > > > + > > > +When calling xen-save-devices-state, since QEMU is running in a chroot > > > +it is not useful to pass a filename (it doesn't even have write access > > > +inside the chroot). Instead, give it an open fd using the add-fd > > > +mechanism. > > > > That describe an issue only on save. The restore part of a migration > > also have an issue: > > > > On restore, QEMU signal to libxl that it is ready only after priviledge > > restriction have been put in place (and after or when it receive the > > migration data). But xenstore isn't available anymore, so restore fails > > from libxl point-of-view. > > > > > > Or maybe you describe here an issue that would arise when an hypothetic > > chroot is apply. But the migration issue describe here still apply > > without chroot and with only -runas, the path libxl give to QEMU is > > accessible by root only. > > Do our other restrictions -- chroot, deprivilege, -- all work on > restore at the moment? chroot isn't an issue for restore. But running QEMU as non-root user is currently an issue for restore. I think the only issue with restore that doesn't also exist when creating a guest is restricted access to xenstore. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing baseline-only test] 75307: trouble: blocked/broken
This run is configured for baseline tests only. flight 75307 xen-4.10-testing real [real] http://osstest.xensource.com/osstest/logs/75307/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 broken build-amd64-prev broken build-i386 broken build-armhf-pvopsbroken build-i386-xsm broken build-amd64-xtf broken build-amd64-xsm broken build-amd64-pvopsbroken build-i386-pvops broken build-armhf broken build-i386-prev broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-11 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-armhf-armhf-xl-midway1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-rumprun1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-41 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-31 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw
Re: [Xen-devel] [PATCH] x86/altp2m: propagate ept.ad changes to all active altp2ms
On 9/28/18 2:55 PM, Razvan Cojocaru wrote:
> This patch is a pre-requisite for fixing the logdirty VGA issue
> (display freezes when switching to a new altp2m view early in a
> domain's lifetime), but sent separately for easier review.
> The new ept_set_ad_sync() function has been added to update all
> active altp2ms' ept.ad. New altp2ms will inherit the hostp2m's
> ept.ad value. ept_set_ad_sync() is now also the code
> responsible for locking updated p2ms.
>
> Signed-off-by: Razvan Cojocaru
> Suggested-by: George Dunlap
> ---
> xen/arch/x86/mm/p2m-ept.c | 55
> ---
> xen/arch/x86/mm/p2m.c | 8 ---
> 2 files changed, 47 insertions(+), 16 deletions(-)
>
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index d376966..432ff5c 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1218,34 +1219,67 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
> ept_sync_domain_mask(p2m, p2m->domain->dirty_cpumask);
> }
>
> +static void ept_set_ad_sync(struct p2m_domain *p2m, int value)
> +{
> +struct domain *d = p2m->domain;
> +unsigned int i;
> +
> +if ( likely(!altp2m_active(d)) )
> +{
> +p2m_lock(p2m);
> +p2m->ept.ad = value;
> +p2m_unlock(p2m);
> +
> +return;
> +}
> +
> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +{
> +if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
> +continue;
> +
> +p2m = d->arch.altp2m_p2m[i];
> +
> +p2m_lock(p2m);
> +p2m->ept.ad = value;
> +p2m_unlock(p2m);
> +}
> +}
> +
> static void ept_enable_pml(struct p2m_domain *p2m)
> {
> +struct domain *d = p2m->domain;
> +
> /* Domain must have been paused */
> -ASSERT(atomic_read(>domain->pause_count));
> +ASSERT(atomic_read(>pause_count));
>
> /*
> * No need to return whether vmx_domain_enable_pml has succeeded, as
> * ept_p2m_type_to_flags will do the check, and write protection will be
> * used if PML is not enabled.
> */
> -if ( vmx_domain_enable_pml(p2m->domain) )
> +if ( vmx_domain_enable_pml(d) )
> return;
>
> /* Enable EPT A/D bit for PML */
> -p2m->ept.ad = 1;
> -vmx_domain_update_eptp(p2m->domain);
> +ept_set_ad_sync(p2m, 1);
> +
> +vmx_domain_update_eptp(d);
> }
>
> static void ept_disable_pml(struct p2m_domain *p2m)
> {
> +struct domain *d = p2m->domain;
> +
> /* Domain must have been paused */
> -ASSERT(atomic_read(>domain->pause_count));
> +ASSERT(atomic_read(>pause_count));
>
> -vmx_domain_disable_pml(p2m->domain);
> +vmx_domain_disable_pml(d);
>
> /* Disable EPT A/D bit */
> -p2m->ept.ad = 0;
> -vmx_domain_update_eptp(p2m->domain);
> +ept_set_ad_sync(p2m, 0);
> +
> +vmx_domain_update_eptp(d);
> }
>
> static void ept_flush_pml_buffers(struct p2m_domain *p2m)
> @@ -1386,8 +1420,13 @@ void setup_ept_dump(void)
> void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
> {
> struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
> +struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
> struct ept_data *ept;
>
> +p2m_lock(hostp2m);
> +p2m->ept.ad = hostp2m->ept.ad;
> +p2m_unlock(hostp2m);
Just realised I shouldn't lock the hostp2m here, sorry for the oversight.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains
Hi,
I tried to run script after pause the domain and unpause domain after run
script. But I ended up with same error
Below I shared PV device log, and attached my FE and BE driver and script
that i used,
root@hikey960:/debian#
[XEN_BUF]xen_vdevb_be_probe(): 124: Probe called. We are good to go.
[ 165.087419] [XEN_BUF]xen_vdevb_be_probe(): 125: ffc017fb7000 1
[ 165.093759] [XEN_BUF]xen_vdevb_be_probe(): 137: info->domid: 1
[ 165.099641] [XEN_BUF]xen_vdevb_be_probe(): 138: devicetype: vdevb,
nodename: backend/vdevb/1/0, otherend: /local/domain/1/device/vdevb/0
[ 165.112939] [XEN_BUF]xen_vdevb_be_frontend_changed(): 177: dev->state:
XenbusStateInitialising-1, frontend_state: XenbusStateInitialising-1
root@hikey960:/debian#
root@hikey960:/debian#
root@hikey960:/debian#
root@hikey960:/debian#
root@hikey960:/debian# xl console debian
[ 22.243570] [XEN_BUF]xen_vdevb_fe_probe(): 24: Probe called. We are good
to go.
[ 22.243606] [XEN_BUF]xen_vdevb_fe_probe(): 25: ffc0160b4000 0
[ 22.243620] [XEN_BUF]xen_vdevb_fe_probe(): 38: info->domid: 0
[ 22.243633] [XEN_BUF]xen_vdevb_fe_probe(): 39: devicetype: vdevb,
nodename: device/vdevb/0, otherend: /local/domain/0/backend/vdevb/1/0
[ 22.244669] [XEN_BUF]xen_vdevb_fe_backend_changed(): 64: dev->state:
XenbusStateInitialising-1, backend_state: XenbusStateInitWait-2
[ 22.244701] [XEN_BUF]frontend_connect(): 53: Connecting the frontend now
[ 22.245866] vdevb vdevb-0: 13 writing new state
[ 22.246085] vdevb vdevb-0: failed to write error node for device/vdevb/0
(13 writing new state)
[ 22.250005] vdevb vdevb-0: 13 writing new state
[ 22.250220] vdevb vdevb-0: failed to write error node for device/vdevb/0
(13 writing new state)
root@hikey960:~#
Thanks,
Omkar B
On Thu, Sep 27, 2018 at 4:33 PM Juergen Gross wrote:
> On 27/09/2018 12:35, Omkar Bolla wrote:
> > Hi,
> >
> > Sorry, I forgot, I used code from github chapter [2] from that link, and
> > I just changed name "mydevice" to "vdevb"
>
> Okay.
>
> >
> >> Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
> >> are not sufficient to write the needed entries.
> > Where I have to provide access rights, i.e from Kernel code or from from
> > command line in domain-0 or modify in xen source?
>
> I guess you have your frontend already loaded when running the
> script creating the Xenstore entries?
>
> This would explain the problem: as soon as the entries are written
> the frontend will react. At this point the access rights are not setup
> properly, this is done a little bit later in the script.
>
> Possible solutions are to either load the frontend driver only after
> setting up the Xenstore entries, or to pause the domain while doing
> so and unpause it afterwards (or start the domain paused, create the
> Xenstore entries, and unpause the domain).
>
> The really correct way to do it would be to setup Xenstore in a single
> transaction (write all the entries and set access rights).
>
> > Any thing that I have to do/change in xenbits xen-4.8 sources code, to
> > add new PV device?
>
> Only if you want to include domain config file entries for your device.
>
> >
> >> Did you modify Xen tools (xl/libxl) for adding the new device type?
> > No, is it needed to modify some thing in xl/libxl for adding new device
> > type?
>
> This was just a question to learn how Xenstore is being initialized
> in your scenario.
>
> >
> >> If not you need to setup the Xenstore nodes manually.
> > Setup manually Xenstore means, using commands?
>
> Yes, like your script does.
>
>
> Juergen
>
--
This
message contains confidential information and is intended only
for the
individual(s) named. If you are not the intended
recipient, you are
notified that disclosing, copying, distributing or taking any
action in
reliance on the contents of this mail and attached file/s is strictly
prohibited. Please notify the
sender immediately and delete this e-mail
from your system. E-mail transmission
cannot be guaranteed to be secured or
error-free as information could be
intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain
viruses. The sender therefore does
not accept liability for any errors or
omissions in the contents of this
message, which arise as a result of e-mail
transmission.
#include /* Needed by all modules */
#include /* Needed for KERN_ALERT */
#include/* We are doing something with Xen */
#include
#include "xen_buf.h"
struct vdevbfrnt_info {
struct xenbus_device *dev;
unsigned int evtchn;
unsigned int irq;
grant_ref_t ring_ref;
};
// The function is called on activation of the device
static int xen_vdevb_fe_probe(struct xenbus_device *dev,
const struct xenbus_device_id *id)
{
struct vdevbfrnt_info *info = NULL;
pr_log("Probe called. We are good to go.\n");
pr_log(" %p %d\n", dev, dev->otherend_id);
/* Allocating memory for private structure */
info = kzalloc(sizeof(struct vdevbfrnt_info), GFP_KERNEL);
if
Re: [Xen-devel] [PATCH] xen/blkfront: correct purging of persistent grants
On 9/28/18 3:28 AM, Juergen Gross wrote:
> Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
> stale persistent grants") introduced a regression as purged persistent
> grants were not pu into the list of free grants again. Correct that.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/block/xen-blkfront.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index a71d817e900d..429d20131c7e 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2670,8 +2670,8 @@ static void purge_persistent_grants(struct
> blkfront_info *info)
> list_del(_list_entry->node);
> gnttab_end_foreign_access(gnt_list_entry->gref, 0, 0UL);
> rinfo->persistent_gnts_c--;
> - __free_page(gnt_list_entry->page);
> - kfree(gnt_list_entry);
> + gnt_list_entry->gref = GRANT_INVALID_REF;
> + list_add_tail(_list_entry->node, >grants);
Sorry, I don't follow this. What is the purpose of removing the grant
from rinfo->grants list with list_del() and then adding it back with
list_add_tail()?
-boris
> }
>
> spin_unlock_irqrestore(>ring_lock, flags);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/altp2m: propagate ept.ad changes to all active altp2ms
This patch is a pre-requisite for fixing the logdirty VGA issue
(display freezes when switching to a new altp2m view early in a
domain's lifetime), but sent separately for easier review.
The new ept_set_ad_sync() function has been added to update all
active altp2ms' ept.ad. New altp2ms will inherit the hostp2m's
ept.ad value. ept_set_ad_sync() is now also the code
responsible for locking updated p2ms.
Signed-off-by: Razvan Cojocaru
Suggested-by: George Dunlap
---
xen/arch/x86/mm/p2m-ept.c | 55 ---
xen/arch/x86/mm/p2m.c | 8 ---
2 files changed, 47 insertions(+), 16 deletions(-)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index d376966..432ff5c 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1218,34 +1219,67 @@ static void ept_tlb_flush(struct p2m_domain *p2m)
ept_sync_domain_mask(p2m, p2m->domain->dirty_cpumask);
}
+static void ept_set_ad_sync(struct p2m_domain *p2m, int value)
+{
+struct domain *d = p2m->domain;
+unsigned int i;
+
+if ( likely(!altp2m_active(d)) )
+{
+p2m_lock(p2m);
+p2m->ept.ad = value;
+p2m_unlock(p2m);
+
+return;
+}
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+
+p2m_lock(p2m);
+p2m->ept.ad = value;
+p2m_unlock(p2m);
+}
+}
+
static void ept_enable_pml(struct p2m_domain *p2m)
{
+struct domain *d = p2m->domain;
+
/* Domain must have been paused */
-ASSERT(atomic_read(>domain->pause_count));
+ASSERT(atomic_read(>pause_count));
/*
* No need to return whether vmx_domain_enable_pml has succeeded, as
* ept_p2m_type_to_flags will do the check, and write protection will be
* used if PML is not enabled.
*/
-if ( vmx_domain_enable_pml(p2m->domain) )
+if ( vmx_domain_enable_pml(d) )
return;
/* Enable EPT A/D bit for PML */
-p2m->ept.ad = 1;
-vmx_domain_update_eptp(p2m->domain);
+ept_set_ad_sync(p2m, 1);
+
+vmx_domain_update_eptp(d);
}
static void ept_disable_pml(struct p2m_domain *p2m)
{
+struct domain *d = p2m->domain;
+
/* Domain must have been paused */
-ASSERT(atomic_read(>domain->pause_count));
+ASSERT(atomic_read(>pause_count));
-vmx_domain_disable_pml(p2m->domain);
+vmx_domain_disable_pml(d);
/* Disable EPT A/D bit */
-p2m->ept.ad = 0;
-vmx_domain_update_eptp(p2m->domain);
+ept_set_ad_sync(p2m, 0);
+
+vmx_domain_update_eptp(d);
}
static void ept_flush_pml_buffers(struct p2m_domain *p2m)
@@ -1386,8 +1420,13 @@ void setup_ept_dump(void)
void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
{
struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
struct ept_data *ept;
+p2m_lock(hostp2m);
+p2m->ept.ad = hostp2m->ept.ad;
+p2m_unlock(hostp2m);
+
p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
p2m->max_remapped_gfn = 0;
ept = >ept;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index d6a8810..d90c624 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -360,11 +360,7 @@ void p2m_enable_hardware_log_dirty(struct domain *d)
struct p2m_domain *p2m = p2m_get_hostp2m(d);
if ( p2m->enable_hardware_log_dirty )
-{
-p2m_lock(p2m);
p2m->enable_hardware_log_dirty(p2m);
-p2m_unlock(p2m);
-}
}
void p2m_disable_hardware_log_dirty(struct domain *d)
@@ -372,11 +368,7 @@ void p2m_disable_hardware_log_dirty(struct domain *d)
struct p2m_domain *p2m = p2m_get_hostp2m(d);
if ( p2m->disable_hardware_log_dirty )
-{
-p2m_lock(p2m);
p2m->disable_hardware_log_dirty(p2m);
-p2m_unlock(p2m);
-}
}
void p2m_flush_hardware_cached_dirty(struct domain *d)
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/6] docs/qemu-deprivilege: Revise and update with status and future plans
On Tue, Sep 25, 2018 at 12:20 PM Anthony PERARD wrote: > > On Fri, Sep 21, 2018 at 06:04:23PM +0100, George Dunlap wrote: > > +## Migration > > + > > +When calling xen-save-devices-state, since QEMU is running in a chroot > > +it is not useful to pass a filename (it doesn't even have write access > > +inside the chroot). Instead, give it an open fd using the add-fd > > +mechanism. > > That describe an issue only on save. The restore part of a migration > also have an issue: > > On restore, QEMU signal to libxl that it is ready only after priviledge > restriction have been put in place (and after or when it receive the > migration data). But xenstore isn't available anymore, so restore fails > from libxl point-of-view. > > > Or maybe you describe here an issue that would arise when an hypothetic > chroot is apply. But the migration issue describe here still apply > without chroot and with only -runas, the path libxl give to QEMU is > accessible by root only. Do our other restrictions -- chroot, deprivilege, -- all work on restore at the moment? -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 128114: regressions - FAIL
flight 128114 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/128114/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125898 test-amd64-i386-examine 8 reboot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-examine 8 reboot fail REGR. vs. 125898 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125898 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 125898 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125898 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125898 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125898 test-amd64-i386-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-win10-i386 10 windows-install fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-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-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-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
[Xen-devel] [freebsd-master test] 128168: trouble: blocked/broken
flight 128168 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/128168/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd broken build-amd64-freebsd 5 host-install(5)broken REGR. vs. 128102 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 53634ed3beec18a276da423e9aa25bc59786a58a baseline version: freebsd a62d8e729c6db95f0c2e1de618be0b0796c0a97a Last test of basis 128102 2018-09-26 09:19:09 Z2 days Testing same since 128168 2018-09-28 09:19:05 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> ae andrew bdrewery brooks bz emaste gjb gordon imp jhb kib mjg np sef slavash tuexen ygy jobs: build-amd64-freebsd-againblocked build-amd64-freebsd broken 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 broken-job build-amd64-freebsd broken broken-step build-amd64-freebsd host-install(5) Not pushing. (No revision log; it would be 562 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/6] xen/arm: cpufeature: Add helper to check constant caps
Hi, On 09/27/2018 11:34 PM, Stefano Stabellini wrote: On Wed, 26 Sep 2018, Julien Grall wrote: Hi Stefano, On 09/26/2018 05:53 PM, Stefano Stabellini wrote: On Tue, 25 Sep 2018, Julien Grall wrote: Some capababilities are set right during boot and will never change afterwards. At the moment, the function cpu_have_caps will check whether the cap is enabled from the memory. It is possible to avoid the load from the memory by using an ALTERNATIVE. With that the check is just reduced to 1 instruction. Signed-off-by: Julien Grall I enjoyed reading the patch :-) But I don't think it is worth going into this extreme level of optimization. test_bit is efficient enough, right? What do you think we need to use alternatives just to check one bit? We already have an helper using test_bit (see cpus_have_cap). However test_bit requires to load the word from the memory. This is an overhead when the decision never change after boot. One load may be insignificant by itself (thought may have a cache miss), but if you are in hotpath this is a win in long term. The mechanism is very similar to static key but for the poor (I don't have much time to implement better for now). We already use similar construction on other places (see CHECK_WORKAROUND_HELPER). I like the mechanism and the little ALTERNATIVE trick. I can see it could very useful in some cases. It is just that it is a bit of a waste to use it on SMCCC virtualization -- SMCCC calls cannot be done often enough for this to make a difference. I would not be so sure ;). SMC can be called at *every* entry and exit into the hypervisor to apply SSBD workaround. While SSBD will directly call arm_smccc_1_1_smc (and not the generic one), I would not rule out more hotpath with SMC call in it. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Backports to stable trees
>>> On 28.09.18 at 10:28, wrote: > On Thu, 2018-09-27 at 15:36 +0100, Andrew Cooper wrote: >> Hello, >> >> Please can the following patches be considered for stable. >> > Can we also include: > > 6e395f477fb85 - xen: sched/Credit2: fix bug when moving CPUs between > two Credit2 cpupools > > for 4.10 and 4.11 ? I have this queued already. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/6] xen/arm: add SMC wrapper that is compatible with SMCCC v1.0
Hi Stefano, On 09/28/2018 12:02 AM, Stefano Stabellini wrote: On Wed, 26 Sep 2018, Julien Grall wrote: Hi Stefano, On 09/26/2018 12:50 AM, Stefano Stabellini wrote: On Tue, 25 Sep 2018, Julien Grall wrote: From: Volodymyr Babchuk Existing SMC wrapper call_smc() allows only 4 parameters and returns only one value. This is enough for existing use in PSCI code, but TEE mediator will need a call that is fully compatible with ARM SMCCC v1.0. This patch adds a wrapper for both arm32 and arm64. In the case of arm32, the wrapper is just an alias to the ARM SMCCC v1.1 as the convention is the same. CC: "Edgar E. Iglesias" Signed-off-by: Volodymyr Babchuk [julien: Rework the wrapper to make it closer to SMCC 1.1 wrapper] Signed-off-by: Julien Grall I have been struggling to find the old doc for SMCCC v1.0, all the references have been updated to v1.1 online now. Do you have a link? Are you sure? All the references are still to v1.0 (DEN 0028B). See [1]. The lack of version in the doc confused me. diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S new file mode 100644 index 00..b0752be57e --- /dev/null +++ b/xen/arch/arm/arm64/smc.S @@ -0,0 +1,32 @@ +/* + * xen/arch/arm/arm64/smc.S + * + * Wrapper for Secure Monitors Calls + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include + +/* + * void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2, + * register_t a3, register_t a4, register_t a5, + * register_t a6, register_t a7, + * struct arm_smccc_res *res) + */ +ENTRY(__arm_smccc_1_0_smc) +smc #0 +ldr x4, [sp] +cbz x4, 1f /* No need to store the result */ +stp x0, x1, [x4, #SMCCC_RES_a0] +stp x2, x3, [x4, #SMCCC_RES_a2] +1: +ret As I mentioned, I couldn't find the doc, but it looks like the Linux implementation always copies back the results (arch/arm64/kernel/smccc-call.S)? Shouldn't we zero x0-x3 at least? Could you provide more details on what looks wrong? The results are copied in the array res using stp instructions. The only difference with Linux implementation is we don't handle quirk. The only difference is that in this implementation we handle `res' being NULL, which I think is a good idea: Oh yeah I forgot that difference :/. I added it to keep the behavior similar to the SMCCC v1.1 implementation. Reviewed-by: Stefano Stabellini Thank you! Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V5] x86/altp2m: Add a subop for obtaining the mem access of a page
On 9/28/18 12:04 PM, Wei Liu wrote: > On Wed, Sep 26, 2018 at 03:26:20PM +0300, Razvan Cojocaru wrote: >> but is it OK that the hypervisor builds with a set of flags that >> includes CONFIG_HVM and the firmware code with a set that doesn't? > > To answer this question: yes, it is OK to do that. And that's deliberate > for the shim because it doesn't need any HVM interfaces. Jan has given > the reason why your build failed in his replies. > > This build failure just exposed how much we took for granted some code > is always there. :) I understand. Thanks for the reply! In that case, V6 should be correct in that respect, so when you have the time please consider that version for review. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V5] x86/altp2m: Add a subop for obtaining the mem access of a page
On Wed, Sep 26, 2018 at 03:26:20PM +0300, Razvan Cojocaru wrote: > but is it OK that the hypervisor builds with a set of flags that > includes CONFIG_HVM and the firmware code with a set that doesn't? To answer this question: yes, it is OK to do that. And that's deliberate for the shim because it doesn't need any HVM interfaces. Jan has given the reason why your build failed in his replies. This build failure just exposed how much we took for granted some code is always there. :) Wei. > > > Thanks, > Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/2] x86: undefine BOOSTRAP_MAP_LIMIT after its last user
Requested-by: Jan Beulich Signed-off-by: Wei Liu --- xen/arch/x86/setup.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index cf404ec..ae6f4d9 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -416,6 +416,8 @@ static void *__init move_memory( return NULL; } +#undef BOOTSTRAP_MAP_LIMIT + static uint64_t __init consider_modules( uint64_t s, uint64_t e, uint32_t size, const module_t *mod, unsigned int nr_mods, unsigned int this_mod) -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 0/2] Miscellaneous patches for early boot mapping code
Wei Liu (2): x86: fix comment on super page alignment requirement x86: undefine BOOSTRAP_MAP_LIMIT after its last user xen/arch/x86/setup.c | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) base-commit: a8c7e309d1fec898a2731b6e0f63d66c509c7233 -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 1/2] x86: fix comment on super page alignment requirement
BOOTSTRAP_DIRECTMAP_END is gone. The comment in question should refer
to BOOSTRAP_MAP_BASE and 4GB instead.
Move the entire comment block to where it belongs -- immediately
before the loop which does the things said in the comment.
Remove two trailing spaces while at it.
Signed-off-by: Wei Liu
---
xen/arch/x86/setup.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 2fbf7d5..cf404ec 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -942,19 +942,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
initial_images = mod;
nr_initial_images = mbi->mods_count;
-/*
- * Iterate backwards over all superpage-aligned RAM regions.
- *
- * We require superpage alignment because the boot allocator is not yet
- * initialised. Hence we can only map superpages in the address range
- * 0 to BOOTSTRAP_DIRECTMAP_END, as this is guaranteed not to require
- * dynamic allocation of pagetables.
- *
- * As well as mapping superpages in that range, in preparation for
- * initialising the boot allocator, we also look for a region to which
- * we can relocate the dom0 kernel and other multiboot modules. Also, on
- * x86/64, we relocate Xen to higher memory.
- */
for ( i = 0; !efi_enabled(EFI_LOADER) && i < mbi->mods_count; i++ )
{
if ( mod[i].mod_start & (PAGE_SIZE - 1) )
@@ -987,6 +974,19 @@ void __init noreturn __start_xen(unsigned long mbi_p)
highmem_start &= ~((1UL << L3_PAGETABLE_SHIFT) - 1);
#endif
+/*
+ * Iterate backwards over all superpage-aligned RAM regions.
+ *
+ * We require superpage alignment because the boot allocator is
+ * not yet initialised. Hence we can only map superpages in the
+ * address range BOOTSTRAP_MAP_BASE to 4GB, as this is guaranteed
+ * not to require dynamic allocation of pagetables.
+ *
+ * As well as mapping superpages in that range, in preparation for
+ * initialising the boot allocator, we also look for a region to which
+ * we can relocate the dom0 kernel and other multiboot modules. Also, on
+ * x86/64, we relocate Xen to higher memory.
+ */
for ( i = boot_e820.nr_map-1; i >= 0; i-- )
{
uint64_t s, e, mask = (1UL << L2_PAGETABLE_SHIFT) - 1;
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Granting huge memory regions?
On 28/09/18 09:24, Simon Kuenzer wrote: > Hey, > > for some research we are currently looking into mapping big memory > regions to PV guests. With big I mean 100s to 1000s of mega bytes. > Using one grant for each 4K page seems to be expensive although we got > it working so far. > Is there another mechanism we could look into? Is changing the > granularity to huge pages promising? What would we need to do roughly > to support it? There is no provision in the Grant API for >4k grants at the moment. In principle, one could be added. That said, PV guests are allocated using exclusively 4k pages. They don't in general end up physically contiguous, so superpage grants won't be of any help. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Backports to stable trees
On Thu, 2018-09-27 at 15:36 +0100, Andrew Cooper wrote: > Hello, > > Please can the following patches be considered for stable. > Can we also include: 6e395f477fb85 - xen: sched/Credit2: fix bug when moving CPUs between two Credit2 cpupools for 4.10 and 4.11 ? From a quick check, it' not as easy as cherry-picking/applying the patch (there's 1 hunk that fails), but it shouldn't be too bad. And I can provide the backport, if you want me to. Thanks, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] xen: make opt_xen_console true before console initialisation
This helps capture issues before console is initialised. The impact is
minimal because it only affects Xen running in as a guest.
Signed-off-by: Wei Liu
---
xen/drivers/char/console.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index e48039dd82..bbec98304e 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -91,7 +91,8 @@ static uint32_t conringc, conringp;
static int __read_mostly sercon_handle = -1;
#ifdef CONFIG_X86
-static bool __read_mostly opt_console_xen; /* console=xen */
+/* Set to true at start of day to catch early boot issues */
+static bool __read_mostly opt_console_xen = true; /* console=xen */
#endif
static DEFINE_SPINLOCK(console_lock);
@@ -821,6 +822,10 @@ void __init console_init_preirq(void)
serial_init_preirq();
+#ifdef CONFIG_X86
+opt_console_xen = false;
+#endif
+
/* Where should console output go? */
for ( p = opt_console; p != NULL; p = strchr(p, ',') )
{
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] x86: make sure module array is large enough in pvh-boot.c
The relocation code in __start_xen requires one extra element in the module array. By the looks of it the temporary array is already large enough. Add a BUG_ON to catch any issue in the future. While at it, turn another ASSERT to BUG_ON as well. Signed-off-by: Wei Liu --- xen/arch/x86/guest/pvh-boot.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/guest/pvh-boot.c b/xen/arch/x86/guest/pvh-boot.c index 0e9e5bfdf6..2e103105fa 100644 --- a/xen/arch/x86/guest/pvh-boot.c +++ b/xen/arch/x86/guest/pvh-boot.c @@ -42,7 +42,14 @@ static void __init convert_pvh_info(void) module_t *mod; unsigned int i; -ASSERT(pvh_info->magic == XEN_HVM_START_MAGIC_VALUE); +BUG_ON(pvh_info->magic != XEN_HVM_START_MAGIC_VALUE); + +/* + * Temporary module array needs to be at least one element bigger than + * required. The extra element is used to aid relocation. See + * arch/x86/setup.c:__start_xen(). + */ +BUG_ON(ARRAY_SIZE(pvh_mbi_mods) <= pvh_info->nr_modules); /* * Turn hvm_start_info into mbi. Luckily all modules are placed under 4GB -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Granting huge memory regions?
Hey, for some research we are currently looking into mapping big memory regions to PV guests. With big I mean 100s to 1000s of mega bytes. Using one grant for each 4K page seems to be expensive although we got it working so far. Is there another mechanism we could look into? Is changing the granularity to huge pages promising? What would we need to do roughly to support it? Thanks, Simon ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/2] Minor improvement to early boot code
Wei Liu (2): x86: make sure module array is large enough in pvh-boot.c xen: make opt_xen_console true before console initialisation xen/arch/x86/guest/pvh-boot.c | 9 - xen/drivers/char/console.c| 7 ++- 2 files changed, 14 insertions(+), 2 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] xen/xsm: Add new SILO mode for XSM
When SILO is enabled, there would be no page-sharing or event notifications
between unprivileged VMs (no grant tables or event channels).
Signed-off-by: Xin Li
---
CC: Daniel De Graaf
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Sergey Dyasli
CC: Andrew Cooper
CC: Ming Lu
v3: make copies of dummy functions to avoid indirect call.
---
docs/misc/xen-command-line.markdown | 5 +-
xen/common/Kconfig | 12 +++
xen/include/xsm/xsm.h | 6 ++
xen/xsm/Makefile| 1 +
xen/xsm/silo.c | 123
xen/xsm/xsm_core.c | 9 ++
6 files changed, 155 insertions(+), 1 deletion(-)
create mode 100644 xen/xsm/silo.c
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 6a3c0e71c7..e0a9b4d268 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -900,7 +900,7 @@ Note that specifying zero as domU value means zero, while
for dom0 it means
to use the default.
### xsm
-> `= default | flask`
+> `= default | flask | silo`
> Default: `default`
@@ -911,6 +911,9 @@ the hypervisor was compiled with XSM support.
(the dummy module) will be applied. it's also used when XSM is compiled out.
* `flask`: this is the policy based access control. To choose this, the
separated option in kconfig must also be enabled.
+* `silo`: this will deny any unmediated communication channels between
+ unprivileged VMs. To choose this, the separated option in kconfig must also
+ be enabled.
### flask
> `= permissive | enforcing | late | disabled`
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 1a6d6281c1..2fe668ba5a 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -154,6 +154,18 @@ config XSM_FLASK_POLICY
If unsure, say Y.
+config XSM_SILO
+ def_bool y
+ prompt "SILO support"
+ depends on XSM
+ ---help---
+ Enables SILO as the access control mechanism used by the XSM
framework.
+ This is not the default module, add boot parameter xsm=silo to choose
+ it. This will deny any unmediated communication channels (grant tables
+ and event channels) between unprivileged VMs.
+
+ If unsure, say Y.
+
config LATE_HWDOM
bool "Dedicated hardware domain"
default n
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3d67962493..3b192b5c31 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -733,6 +733,12 @@ extern const unsigned char xsm_flask_init_policy[];
extern const unsigned int xsm_flask_init_policy_size;
#endif
+#ifdef CONFIG_XSM_SILO
+extern void silo_init(void);
+#else
+static inline void silo_init(void) {}
+#endif
+
#else /* CONFIG_XSM */
#include
diff --git a/xen/xsm/Makefile b/xen/xsm/Makefile
index 8bb4a24f09..e4d581e065 100644
--- a/xen/xsm/Makefile
+++ b/xen/xsm/Makefile
@@ -1,5 +1,6 @@
obj-y += xsm_core.o
obj-$(CONFIG_XSM) += xsm_policy.o
obj-$(CONFIG_XSM) += dummy.o
+obj-$(CONFIG_XSM_SILO) += silo.o
subdir-$(CONFIG_XSM_FLASK) += flask
diff --git a/xen/xsm/silo.c b/xen/xsm/silo.c
new file mode 100644
index 00..020b0c8e94
--- /dev/null
+++ b/xen/xsm/silo.c
@@ -0,0 +1,123 @@
+/**
+ * xsm/silo.c
+ *
+ * SILO module for XSM(Xen Security Modules)
+ *
+ * Copyright (c) 2018 Citrix Systems Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see
Re: [Xen-devel] null scheduler bug
Hi, thank you for explanation, links and advices. I'm gonna go through all that literature. Best regards! On Thu, Sep 27, 2018 at 7:06 PM Dario Faggioli wrote: > > On Thu, 2018-09-27 at 16:09 +0100, Julien Grall wrote: > > Hi Dario, > > > Hi, > > > On 09/27/2018 03:32 PM, Dario Faggioli wrote: > > > On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote: > > > > > > In one of your e-mail, you wrote: > > > > "Well, our implementation of RCU requires that, from time to time, > > the > > various physical CPUs of your box become idle, or get an interrupt, > > or > > go executing inside Xen (for hypercalls, vmexits, etc). In fact, a > > CPU > > going through Xen is what allow us to tell that it reached a so- > > called > > 'quiescent state', which in turns is necessary for declaring a so- > > called 'RCU grace period' over." > > > > I don't quite agree with you on the definition of "quiescent state" > > here. > > > Hehe... I was trying to be both quick and accurate. It's more than > possible that I failed. :-) > > > To take the domain example, we want to wait until all the CPU has > > stopped using the pointer (an hypercall could race put_domain). > > > I'm not sure what you mean with "an hypercall could race put_domain". > What we want is to wait until all the CPUs that are involved in the > grace period, have gone through rcupdate.c:cpu_quiet(), or have become > idle. > > Receiving an interrupt, or experiencing a context switch, or even going > idle, it's "just" how it happens that these CPUs have their chance to > go through cpu_quiet(). It is in this sense that I meant that those > events are used as markers of a quiescent state. > > And "wfi=native" (in particular in combination with the null scheduler, > but I guess also with other ones, at least to a certain extent) makes > figuring out the "or have become idle" part tricky. That is the problem > here, isn't it? > > > That > > pointer will not be in-use if the CPU is in kernel-mode/user-mode or > > in > > the idle loop. Am I correct? > > > Right. > > So, we want that all the CPUs that were in Xen to have either left Xen > at least once or, if they're still there and have never left, that must > be because they've become idle. > > And currently we treat all the CPUs that have not told the RCU > subsystem that they're idle (via rcu_idle_enter()) as busy, without > distinguishing between the ones that are busy in Xen from the one which > are busy in guest (kernel or user) mode. > > > So I am wondering whether we could: > > - Mark any CPU in kernel-mode/user-mode quiet > > > Right. We'd need something like a rcu_guest_enter()/rcu_guest_exit() > (or a rcu_xen_exit()/rcu_xen_enter()), which works for all combination > of arches and guest types. > > It looks to me too that this would help in this case, as the vCPU that > stays in guest mode because of wfi=idle would be counted as quiet, and > we won't have to wait for it. > > > - Raise a RCU_SOFTIRQ in call_rcu? > > > Mmm... what would be the point of this? > > > With that solution, it may even be possible to avoid the timer in > > the > > idle loop. > > > Not sure. The timer is there to deal with the case when a CPU which has > a callback queued wants to go idle. It may have quiesced already, but > if there are others which have not, either: > 1) we let it go idle, but then the callback will run only when it >wakes up from idle which, without the timer, could be far ahead in >time; > 2) we don't let it go idle, but we waste resources; > 3) we let it go idle and keep the timer. :-) > > But anyway, even if it would not let us get rid of the timer, it seems > like it could be nicer than any other approaches. I accept > help/suggestions about the "let's intercept guest-Xen and Xen-guest > transitions, and track that inside RCU code. > > Regards, > Dario > -- > <> (Raistlin Majere) > - > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Software Engineer @ SUSE https://www.suse.com/ ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] xen/xsm: Introduce new boot parameter xsm
Introduce new boot parameter xsm to choose which xsm module is enabled,
and set default to dummy.
Signed-off-by: Xin Li
---
CC: Daniel De Graaf
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Sergey Dyasli
CC: Andrew Cooper
CC: Ming Lu
v3: change the default XSM boot parameter name from "dummy" to "default".
---
docs/misc/xen-command-line.markdown | 13 +
xen/xsm/xsm_core.c | 41 -
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 1ffd586224..6a3c0e71c7 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -899,6 +899,19 @@ hardware domain is architecture dependent.
Note that specifying zero as domU value means zero, while for dom0 it means
to use the default.
+### xsm
+> `= default | flask`
+
+> Default: `default`
+
+Specify which XSM module should be enabled. This option is only available if
+the hypervisor was compiled with XSM support.
+
+* `default`: this is the default choice. Basic restriction for common
deployment
+ (the dummy module) will be applied. it's also used when XSM is compiled out.
+* `flask`: this is the policy based access control. To choose this, the
+ separated option in kconfig must also be enabled.
+
### flask
> `= permissive | enforcing | late | disabled`
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 9645e244c3..658af40c6e 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -31,6 +31,32 @@
struct xsm_operations *xsm_ops;
+enum xsm_bootparam {
+XSM_BOOTPARAM_DUMMY,
+XSM_BOOTPARAM_FLASK,
+};
+
+static enum xsm_bootparam __initdata xsm_bootparam = XSM_BOOTPARAM_DUMMY;
+
+static int __init parse_xsm_param(const char *s)
+{
+int rc = 0;
+
+if ( !strcmp(s, "default") )
+xsm_bootparam = XSM_BOOTPARAM_DUMMY;
+#ifdef CONFIG_XSM_FLASK
+else if ( !strcmp(s, "flask") )
+xsm_bootparam = XSM_BOOTPARAM_FLASK;
+#endif
+else {
+printk("XSM: can't parse boot parameter xsm=%s\n", s);
+rc = -EINVAL;
+}
+
+return rc;
+}
+custom_param("xsm", parse_xsm_param);
+
static inline int verify(struct xsm_operations *ops)
{
/* verify the security_operations structure exists */
@@ -57,7 +83,20 @@ static int __init xsm_core_init(const void *policy_buffer,
size_t policy_size)
}
xsm_ops = _xsm_ops;
-flask_init(policy_buffer, policy_size);
+
+switch ( xsm_bootparam )
+{
+case XSM_BOOTPARAM_DUMMY:
+break;
+
+case XSM_BOOTPARAM_FLASK:
+flask_init(policy_buffer, policy_size);
+break;
+
+default:
+printk("XSM: Invalid value for xsm= boot parameter\n");
+break;
+}
return 0;
}
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 128143: all pass - PUSHED
flight 128143 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/128143/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 6532fdec11d7940a584a73797b5cc067d64f84a5 baseline version: ovmf 6a147d6dae733f3a1d5ddf9af9adce5fb8504a53 Last test of basis 128119 2018-09-27 00:40:44 Z1 days Testing same since 128143 2018-09-27 17:52:19 Z0 days1 attempts People who touched revisions under test: Chasel, Chiu Jiaxin Wu Laszlo Ersek shenglei Star Zeng Wu Jiaxin jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 6a147d6dae..6532fdec11 6532fdec11d7940a584a73797b5cc067d64f84a5 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: correct purging of persistent grants
On Fri, Sep 28, 2018 at 09:28:27AM +0200, Juergen Gross wrote:
> Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
> stale persistent grants") introduced a regression as purged persistent
> grants were not pu into the list of free grants again. Correct that.
s/pu /put /
Alan
smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/blkfront: correct purging of persistent grants
Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
stale persistent grants") introduced a regression as purged persistent
grants were not pu into the list of free grants again. Correct that.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index a71d817e900d..429d20131c7e 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2670,8 +2670,8 @@ static void purge_persistent_grants(struct blkfront_info
*info)
list_del(_list_entry->node);
gnttab_end_foreign_access(gnt_list_entry->gref, 0, 0UL);
rinfo->persistent_gnts_c--;
- __free_page(gnt_list_entry->page);
- kfree(gnt_list_entry);
+ gnt_list_entry->gref = GRANT_INVALID_REF;
+ list_add_tail(_list_entry->node, >grants);
}
spin_unlock_irqrestore(>ring_lock, flags);
--
2.16.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Backports to stable trees
>>> On 27.09.18 at 19:54, wrote: > On 27/09/18 15:36, Andrew Cooper wrote: >> Hello, >> >> Please can the following patches be considered for stable. >> >> 18cd4997d26b - x86/efi: move the logic to detect PE build support >> 93249f7fc17c - x86/efi: split compiler vs linker support >> >> CentOS and RHEL 7.x GCC's are capable of compiling xen.gz with EFI >> support, but LD doesn't have i386pep support. Without a bodge to the >> build system (and several downstreams have borrowed by XenServer bodge), >> making a EFI-capable xen.gz isn't possible with the default toolchain. >> >> These patches resolve the issue. > > In addition, it looks like: > > 328ca55b7bd4 - x86/shutdown: use ACPI reboot method for Dell PowerEdge R540 > 7626edeaca97 - x86/hvm/emulate: make sure rep I/O emulation does not > cross GFN boundaries Hmm, odd - I had certainly meant to (and actually thought I did already) apply the latter. I'll queue up all of the above (afaict the former two are relevant only back to 4.9). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer
On 28/09/2018 00:03, Sander Eikelenboom wrote:
> On 27/09/18 23:48, Boris Ostrovsky wrote:
>> On 9/27/18 5:37 PM, Jens Axboe wrote:
>>> On 9/27/18 2:33 PM, Sander Eikelenboom wrote:
On 27/09/18 21:06, Boris Ostrovsky wrote:
> On 9/27/18 2:56 PM, Jens Axboe wrote:
>> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>>> On 27/09/18 16:26, Jens Axboe wrote:
On 9/27/18 1:12 AM, Juergen Gross wrote:
> On 22/09/18 21:55, Boris Ostrovsky wrote:
>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>> added support for purging persistent grants when they are not in
>> use. As
>> part of the purge, the grants were removed from the grant buffer,
>> This
>> eventually causes the buffer to become empty, with BUG_ON triggered
>> in
>> get_free_grant(). This can be observed even on an idle system, within
>> 20-30 minutes.
>>
>> We should keep the grants in the buffer when purging, and only free
>> the
>> grant ref.
>>
>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>> Signed-off-by: Boris Ostrovsky
> Reviewed-by: Juergen Gross
Since Konrad is out, I'm going to queue this up for 4.19.
>>> Hi Boris/Juergen.
>>>
>>> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch
>>> from Boris pulled on top.
>>> Unfortunately it made a VM hang (probably because it's rootFS is
>>> shuffled from under it's feet
> What do you mean by "rootFS is shuffled from under it's feet " ?
Assumption that block-front getting borked and either a kernel crash or
rootfs becoming mounted readonly. Didn't (try) to check though.
>>> and it gave these in dom0 dmesg:
>>>
>>> [ 9251.696090] xen-blkback: requesting a grant already in use
>>> [ 9251.705861] xen-blkback: trying to add a gref that's already in the
>>> tree
>>> [ 9251.715781] xen-blkback: requesting a grant already in use
>>> [ 9251.725756] xen-blkback: trying to add a gref that's already in the
>>> tree
>>> [ 9251.735698] xen-blkback: requesting a grant already in use
>>> [ 9251.745573] xen-blkback: trying to add a gref that's already in the
>>> tree
>>>
>>> The VM was a HVM with 4 vcpu's and 2 phy disks:
>>> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1
>>> (x86_64-abi) persistent grants
>>> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1
>>> (x86_64-abi) persistent grants
>>>
>>>
>>> Currently i have been running 4.19-rc5 with xen-next on top and commit
>>> a46b53672b2c reverted, for a couple of days. That seems to run stable
>>> for me (since it's a small box so i'm not hit by what a46b53672b2c
>>> tried to fix.
>>>
>>> If you can come up with a debug patch i can give that a spin tomorrow
>>> evening or in the weekend, so we are hopefully still in time for the
>>> 4.19 release.
>> At this late in the game, might make more sense to simply revert the
>> buggy commit. Especially since what is currently out there doesn't fix
>> the issue for you.
Don't know if Boris or Juergen have a hunch about the issue, if not
perhaps a revert is the best.
>>> Anyone? Unless I hear otherwise, I'll revert the series tomorrow.
>>
>> Juergen may have something to say by tomorrow, but from my perspective,
>> given that we are coming up on rc6 --- yes.
>>
>> I looked at the patches again and didn't see anything obvious.
>>
>> -boris
>
> Could also be that what i hit is a latent bug,
> that is not caused by these patches but merely got uncovered by them.
>
> xl dmesg also shows quite some:
> (XEN) [2018-09-24 03:15:46.847] grant_table.c:1755:d14v0 Expanding d14
> grant table from 19 to 20 frames
> (XEN) [2018-09-24 03:15:46.849] grant_table.c:1755:d14v0 Expanding d14
> grant table from 20 to 21 frames
> (and has done that for ages on my box not leading to any direct problems to
> my knowledge)
>
> I don't know if there could be related and something around the (persistent)
> grants for block devices could be leaking under some conditions?
I could reproduce the issue Boris has seen and I have found the fault
in his patch. Just testing a fix.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 128125: regressions - FAIL
flight 128125 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/128125/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-amd64-xsm 6 xen-buildfail REGR. vs. 123814 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a version targeted for testing: libvirt b7ccd0757de73344a4b973ede946dad40de846c7 baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 115 days Failing since123840 2018-06-06 04:19:28 Z 114 days 95 attempts Testing same since 128125 2018-09-27 04:18:51 Z1 days1 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bing Niu Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Clementine Hayat Cole Robinson Dan Kenigsberg Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Fabiano Fidêncio Farhan Ali Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jim Fehlig Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Lin Ma Lubomir Rintel Luyao Huang Marc Hartmayer Marc Hartmayer Marcos Paulo de Souza Marek Marczykowski-Górecki Mark Asselstine Martin Kletzander Matthias Bolte Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Roman Bolshakov Shi Lei Shi Lei Shichangkuo Shivaprasad G Bhat Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský Vitaly Kuznetsov w00251574 Wang Huaqiang Wang Yechao Weilun Zhu Wu Zongyong xinhua.Cao jobs: build-amd64-xsm fail build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked
