[Xen-devel] [ovmf test] 130026: regressions - FAIL
flight 130026 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/130026/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 129475 build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf 85588389222a3636baf0f9ed8227f2434af4c3f9 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z8 days Failing since129526 2018-11-06 20:49:26 Z7 days 64 attempts Testing same since 130014 2018-11-14 03:43:46 Z0 days4 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 871 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/6] x86/emul: dedup hvmemul_cpuid() and pv_emul_cpuid()
>>> On 14.11.18 at 01:20, wrote: > On Mon, Nov 12, 2018 at 01:17:59AM -0700, Jan Beulich wrote: >> >>> On 09.11.18 at 18:16, wrote: >> > LWP doesn't exist any more, even on the hardware it used to exist on. >> > It was never implemented on Fam17h, and was removed from Fam15/16h in a >> > microcode update to make room to implement IBPB for Spectre v2 mitigations. >> > >> > I recommend we purge the support completely. >> >> I certainly don't mind; I'd prefer though if such a withdrawal of >> functionality came actually from AMD. Brian? > > LWP support isn't enabled on F15h system with the latest Ucode and it > isn't available on F17h. I don't see any reason to keep it if it's > hampering cleanup and reformatting. Okay, this confirms your agreement with the removal plans, but is there any chance the patch removing it could actually come from an AMD person, as suggested above? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 2/2] xen: use SYMBOL when required
>>> On 13.11.18 at 23:02, wrote: > On Tue, 13 Nov 2018, Jan Beulich wrote: >> >>> On 13.11.18 at 14:17, wrote: >> > On 13/11/2018 12:56, Jan Beulich wrote: >> > On 13.11.18 at 00:06, wrote: >> >>> @@ -33,8 +33,8 @@ static int init_percpu_area(unsigned int cpu) >> >>> if ( (p = alloc_xenheap_pages(PERCPU_ORDER, 0)) == NULL ) >> >>> return -ENOMEM; >> >>> >> >>> -memset(p, 0, __per_cpu_data_end - __per_cpu_start); >> >>> -__per_cpu_offset[cpu] = p - __per_cpu_start; >> >>> +memset(p, 0, SYMBOL(__per_cpu_data_end) - SYMBOL(__per_cpu_start)); >> >>> +__per_cpu_offset[cpu] = (unsigned long)p - SYMBOL(__per_cpu_start); >> >> >> >> Can't you make SYMBOL() retain the original type, such that casts >> >> like this one aren't needed? As soon as the compiler doesn't know >> >> anymore that particular globals (or statics) are used, it can't infer >> >> anymore that two pointers can't possibly point into the same array. >> > >> > If SYMBOL() keeps the original type, then you will still substract 2 >> > pointers. If the compiler can't infer the cannot possibly point into the >> > same array, it also cannot infer they point to the same. So that would >> > be undefined, right? >> >> Undefined behavior results if you _actually_ subtract pointers pointing >> into different objects. Subtracting of pointers is not generally undefined. >> The compiler can use undefined-ness only if it can prove that both >> pointers do point into different objects. > > Let's remember that we are not trying to work-around the compiler, we > are trying to make our code C standard compliant :-) The compiler might > not be able to infer anymore that two pointers can't possibly point into > the same array, but we would still be not-compliant. It doesn't solve > our problem, especially in regards to certifications. But then this entire patch is pointless: SYMBOL() is exclusively about deluding the compiler. To make the code standard compliant, you'd have to e.g. do away with all combined (start and end) uses (in C files) of symbols bounding sections. I at least cannot think of a standard compliant way of expressing these. Oddly enough I had once tried to deal with this issue (for other reasons), but the patch wasn't liked: https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg02718.html All the remaining end symbols then could obviously go away in favor of using the size expressions, but as you see further C limitations make it necessary to use asm() for the ones which get converted. Talking of asm()-s: C standard compliance, in a strict sense, would require dropping all of them as well. I'm afraid that when writing special purpose code like OS kernels or hypervisors are, if you want to avoid to resort extensively to assembly code, you'll have to accept to bend some of the language rules, just making sure that the compiler won't have means to mis-interpret the constructs used. > I is safer to use unsigned long as return type for SYMBOL and avoid > pointers comparisons completely. The code impact is very limited and > then we don't have to prove same or different "objectness" at all. Well, that's one perspective to take. The other is that hidden or explicit casts are always a risk (and hence when reviewing code I'm quite picky about any ones introduced anew or even just retained without reason). Making constructs needing to cast things at least finally cast back to the original type often at least lowers this risk. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V5 3/3] x86/altp2m: fix display frozen when switching to a new view early
On 11/14/18 9:35 AM, Tian, Kevin wrote:
+#ifdef CONFIG_HVM
+/* There's already a memory_type_changed() in asm/mtrr.h. */
+static void _memory_type_changed(struct p2m_domain *p2m)
+{
+if ( p2m->memory_type_changed )
+p2m->memory_type_changed(p2m);
}
void p2m_memory_type_changed(struct domain *d)
>>> why making whole p2m_memory_type_changed under CONFIG_HVM?
>> It has been requested by Jan and Wei in V3:
>>
>> https://lists.xenproject.org/archives/html/xen-devel/2018-
>> 10/msg02495.html
>>
> then it's good to mention it in patch description.
>
> Reviewed-by: Kevin Tian
With George's comments yesterday there'll be at least one more iteration
of the series (probably minus the first patch, which seems ready to go
in) - so I'll update the patch description in the next version.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V5 3/3] x86/altp2m: fix display frozen when switching to a new view early
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Wednesday, November 14, 2018 3:33 PM
>
> On 11/14/18 7:55 AM, Tian, Kevin wrote:
> >> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> >> Sent: Sunday, November 11, 2018 10:07 PM
> >>
> >> When an new altp2m view is created very early on guest boot, the
> >> display will freeze (although the guest will run normally). This
> >> may also happen on resizing the display. The reason is the way
> >> Xen currently (mis)handles logdirty VGA: it intentionally
> >> misconfigures VGA pages so that they will fault.
> >>
> >> The problem is that it only does this in the host p2m. Once we
> >> switch to a new altp2m, the misconfigured entries will no longer
> >> fault, so the display will not be updated.
> >>
> >> This patch:
> >> * updates ept_handle_misconfig() to use the active altp2m instead
> >> of the hostp2m;
> >> * modifies p2m_change_entry_type_global(),
> p2m_memory_type_changed
> >> and p2m_change_type_range() to propagate their changes to all
> >> valid altp2ms.
> >>
> >> Signed-off-by: Razvan Cojocaru
> >> Suggested-by: George Dunlap
> >>
> >> ---
> >> CC: Jun Nakajima
> >> CC: Kevin Tian
> >> CC: George Dunlap
> >> CC: Jan Beulich
> >> CC: Andrew Cooper
> >> CC: Wei Liu
> >>
> >> ---
> >> Changes since V4:
> >> - Now ASSERT()ing that altp2m is _not_ active in
> >>p2m_pt_handle_deferred_changes(), with added comment.
> >> - p2m_memory_type_changed() and p2m_change_type_range() now
> >>process altp2ms with the hostp2m lock taken.
> >> ---
> >> xen/arch/x86/mm/p2m-ept.c | 8
> >> xen/arch/x86/mm/p2m-pt.c | 8
> >> xen/arch/x86/mm/p2m.c | 115
> >> ++
> >> xen/include/asm-x86/p2m.h | 6 +--
> >> 4 files changed, 114 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> >> index fabcd06..e6fa85f 100644
> >> --- a/xen/arch/x86/mm/p2m-ept.c
> >> +++ b/xen/arch/x86/mm/p2m-ept.c
> >> @@ -657,6 +657,9 @@ bool_t ept_handle_misconfig(uint64_t gpa)
> >> bool_t spurious;
> >> int rc;
> >>
> >> +if ( altp2m_active(curr->domain) )
> >> +p2m = p2m_get_altp2m(curr);
> >> +
> >> p2m_lock(p2m);
> >>
> >> spurious = curr->arch.hvm.vmx.ept_spurious_misconfig;
> >> @@ -1440,6 +1443,11 @@ void p2m_init_altp2m_ept(struct domain *d,
> >> unsigned int i)
> >> struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
> >> struct ept_data *ept;
> >>
> >> +p2m->max_mapped_pfn = hostp2m->max_mapped_pfn;
> >> +p2m->default_access = hostp2m->default_access;
> >> +p2m->domain = hostp2m->domain;
> >> +
> >> +p2m->global_logdirty = hostp2m->global_logdirty;
> >> p2m->ept.ad = hostp2m->ept.ad;
> >> p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
> >> p2m->max_remapped_gfn = 0;
> >> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> >> index 55df185..3828088 100644
> >> --- a/xen/arch/x86/mm/p2m-pt.c
> >> +++ b/xen/arch/x86/mm/p2m-pt.c
> >> @@ -29,6 +29,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -464,6 +465,13 @@ int p2m_pt_handle_deferred_changes(uint64_t
> >> gpa)
> >> struct p2m_domain *p2m = p2m_get_hostp2m(current->domain);
> >> int rc;
> >>
> >> +/*
> >> + * Should altp2m ever be enabled for NPT / shadow use, this code
> >> + * should be updated to make use of the active altp2m, like
> >> + * ept_handle_misconfig().
> >> + */
> >> +ASSERT(!altp2m_active(current->domain));
> >> +
> >> p2m_lock(p2m);
> >> rc = do_recalc(p2m, PFN_DOWN(gpa));
> >> p2m_unlock(p2m);
> >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> >> index 69536c1..c8561ba 100644
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -277,7 +277,6 @@ int p2m_init(struct domain *d)
> >> int p2m_is_logdirty_range(struct p2m_domain *p2m, unsigned long
> start,
> >>unsigned long end)
> >> {
> >> -ASSERT(p2m_is_hostp2m(p2m));
> >> if ( p2m->global_logdirty ||
> >> rangeset_contains_range(p2m->logdirty_ranges, start, end) )
> >> return 1;
> >> @@ -286,31 +285,79 @@ int p2m_is_logdirty_range(struct
> p2m_domain
> >> *p2m, unsigned long start,
> >> return 0;
> >> }
> >>
> >> +static void change_entry_type_global(struct p2m_domain *p2m,
> >> + p2m_type_t ot, p2m_type_t nt)
> >> +{
> >> +p2m->change_entry_type_global(p2m, ot, nt);
> >> +p2m->global_logdirty = (nt == p2m_ram_logdirty);
> >> +}
> >> +
> >> void p2m_change_entry_type_global(struct domain *d,
> >>p2m_type_t ot, p2m_type_t nt)
> >> {
> >> -struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >> +struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
> >>
> >> ASSERT(ot != nt);
> >> ASSERT(p2m_is_changeable(ot) &&
Re: [Xen-devel] [PATCH V5 3/3] x86/altp2m: fix display frozen when switching to a new view early
On 11/14/18 7:55 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>> Sent: Sunday, November 11, 2018 10:07 PM
>>
>> When an new altp2m view is created very early on guest boot, the
>> display will freeze (although the guest will run normally). This
>> may also happen on resizing the display. The reason is the way
>> Xen currently (mis)handles logdirty VGA: it intentionally
>> misconfigures VGA pages so that they will fault.
>>
>> The problem is that it only does this in the host p2m. Once we
>> switch to a new altp2m, the misconfigured entries will no longer
>> fault, so the display will not be updated.
>>
>> This patch:
>> * updates ept_handle_misconfig() to use the active altp2m instead
>> of the hostp2m;
>> * modifies p2m_change_entry_type_global(), p2m_memory_type_changed
>> and p2m_change_type_range() to propagate their changes to all
>> valid altp2ms.
>>
>> Signed-off-by: Razvan Cojocaru
>> Suggested-by: George Dunlap
>>
>> ---
>> CC: Jun Nakajima
>> CC: Kevin Tian
>> CC: George Dunlap
>> CC: Jan Beulich
>> CC: Andrew Cooper
>> CC: Wei Liu
>>
>> ---
>> Changes since V4:
>> - Now ASSERT()ing that altp2m is _not_ active in
>>p2m_pt_handle_deferred_changes(), with added comment.
>> - p2m_memory_type_changed() and p2m_change_type_range() now
>>process altp2ms with the hostp2m lock taken.
>> ---
>> xen/arch/x86/mm/p2m-ept.c | 8
>> xen/arch/x86/mm/p2m-pt.c | 8
>> xen/arch/x86/mm/p2m.c | 115
>> ++
>> xen/include/asm-x86/p2m.h | 6 +--
>> 4 files changed, 114 insertions(+), 23 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
>> index fabcd06..e6fa85f 100644
>> --- a/xen/arch/x86/mm/p2m-ept.c
>> +++ b/xen/arch/x86/mm/p2m-ept.c
>> @@ -657,6 +657,9 @@ bool_t ept_handle_misconfig(uint64_t gpa)
>> bool_t spurious;
>> int rc;
>>
>> +if ( altp2m_active(curr->domain) )
>> +p2m = p2m_get_altp2m(curr);
>> +
>> p2m_lock(p2m);
>>
>> spurious = curr->arch.hvm.vmx.ept_spurious_misconfig;
>> @@ -1440,6 +1443,11 @@ void p2m_init_altp2m_ept(struct domain *d,
>> unsigned int i)
>> struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
>> struct ept_data *ept;
>>
>> +p2m->max_mapped_pfn = hostp2m->max_mapped_pfn;
>> +p2m->default_access = hostp2m->default_access;
>> +p2m->domain = hostp2m->domain;
>> +
>> +p2m->global_logdirty = hostp2m->global_logdirty;
>> p2m->ept.ad = hostp2m->ept.ad;
>> p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
>> p2m->max_remapped_gfn = 0;
>> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
>> index 55df185..3828088 100644
>> --- a/xen/arch/x86/mm/p2m-pt.c
>> +++ b/xen/arch/x86/mm/p2m-pt.c
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -464,6 +465,13 @@ int p2m_pt_handle_deferred_changes(uint64_t
>> gpa)
>> struct p2m_domain *p2m = p2m_get_hostp2m(current->domain);
>> int rc;
>>
>> +/*
>> + * Should altp2m ever be enabled for NPT / shadow use, this code
>> + * should be updated to make use of the active altp2m, like
>> + * ept_handle_misconfig().
>> + */
>> +ASSERT(!altp2m_active(current->domain));
>> +
>> p2m_lock(p2m);
>> rc = do_recalc(p2m, PFN_DOWN(gpa));
>> p2m_unlock(p2m);
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 69536c1..c8561ba 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -277,7 +277,6 @@ int p2m_init(struct domain *d)
>> int p2m_is_logdirty_range(struct p2m_domain *p2m, unsigned long start,
>>unsigned long end)
>> {
>> -ASSERT(p2m_is_hostp2m(p2m));
>> if ( p2m->global_logdirty ||
>> rangeset_contains_range(p2m->logdirty_ranges, start, end) )
>> return 1;
>> @@ -286,31 +285,79 @@ int p2m_is_logdirty_range(struct p2m_domain
>> *p2m, unsigned long start,
>> return 0;
>> }
>>
>> +static void change_entry_type_global(struct p2m_domain *p2m,
>> + p2m_type_t ot, p2m_type_t nt)
>> +{
>> +p2m->change_entry_type_global(p2m, ot, nt);
>> +p2m->global_logdirty = (nt == p2m_ram_logdirty);
>> +}
>> +
>> void p2m_change_entry_type_global(struct domain *d,
>>p2m_type_t ot, p2m_type_t nt)
>> {
>> -struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
>>
>> ASSERT(ot != nt);
>> ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
>>
>> -p2m_lock(p2m);
>> -p2m->change_entry_type_global(p2m, ot, nt);
>> -p2m->global_logdirty = (nt == p2m_ram_logdirty);
>> -p2m_unlock(p2m);
>> +p2m_lock(hostp2m);
>> +
>> +change_entry_type_global(hostp2m, ot, nt);
>> +
>> +#ifdef CONFIG_HVM
>> +if ( unlikely(altp2m_active(d)) )
>> +{
>> +unsigned int i;
>> +
Re: [Xen-devel] [PATCH V5 1/3] x86/altp2m: propagate ept.ad changes to all active altp2ms
On 11/14/18 7:44 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>> Sent: Sunday, November 11, 2018 10:07 PM
>>
>> 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.
>
> it's in the series now, instead of sending separately.
Right, sorry for that omission - although now with your Reviewed-by it
can be applied now and escape the series. :)
>> 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.
>>
>> The p2m_{en,dis}able_hardware_log_dirty() hostp2m locking has
>> been moved to the new ept_{en,dis}able_hardware_log_dirty()
>> functions as part of the code refactoring, while locks for the
>> individual altp2ms are taken in ept_set_ad_sync() (called by
>> ept_{en,dis}able_pml()).
>>
>> Signed-off-by: Razvan Cojocaru
>> Suggested-by: George Dunlap
>> Tested-by: Tamas K Lengyel
>> Acked-by: George Dunlap
>
> Reviewed-by: Kevin Tian
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 130021: regressions - FAIL
flight 130021 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/130021/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 129475 build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: ovmf 85588389222a3636baf0f9ed8227f2434af4c3f9 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z8 days Failing since129526 2018-11-06 20:49:26 Z7 days 63 attempts Testing same since 130014 2018-11-14 03:43:46 Z0 days3 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 871 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.7-testing test] 129791: regressions - FAIL
flight 129791 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/129791/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail REGR. vs. 129540 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 129688 pass in 129791 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 129688 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 129540 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 129540 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 129540 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 129540 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 129540 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 129540 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 129540 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 129540 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 129540 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 129540 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 129540 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 129540 test-amd64-amd64-xl-rtds 10 debian-install fail like 129540 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 129540 test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-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-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen
[Xen-devel] [linux-linus test] 129789: regressions - FAIL
flight 129789 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/129789/ 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-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ovmf-amd64 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-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qcow2 7 xen-boot 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-libvirt-vhd 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 125898 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-examine 8 reboot fail REGR. vs. 125898 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125898 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-xl7 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-amd64-examine 8 reboot fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat 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-amd64-amd64-xl-credit1 7 xen-bootfail baseline untested 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-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-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-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-check
Re: [Xen-devel] [PATCH V5 3/3] x86/altp2m: fix display frozen when switching to a new view early
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Sunday, November 11, 2018 10:07 PM
>
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is the way
> Xen currently (mis)handles logdirty VGA: it intentionally
> misconfigures VGA pages so that they will fault.
>
> The problem is that it only does this in the host p2m. Once we
> switch to a new altp2m, the misconfigured entries will no longer
> fault, so the display will not be updated.
>
> This patch:
> * updates ept_handle_misconfig() to use the active altp2m instead
> of the hostp2m;
> * modifies p2m_change_entry_type_global(), p2m_memory_type_changed
> and p2m_change_type_range() to propagate their changes to all
> valid altp2ms.
>
> Signed-off-by: Razvan Cojocaru
> Suggested-by: George Dunlap
>
> ---
> CC: Jun Nakajima
> CC: Kevin Tian
> CC: George Dunlap
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Wei Liu
>
> ---
> Changes since V4:
> - Now ASSERT()ing that altp2m is _not_ active in
>p2m_pt_handle_deferred_changes(), with added comment.
> - p2m_memory_type_changed() and p2m_change_type_range() now
>process altp2ms with the hostp2m lock taken.
> ---
> xen/arch/x86/mm/p2m-ept.c | 8
> xen/arch/x86/mm/p2m-pt.c | 8
> xen/arch/x86/mm/p2m.c | 115
> ++
> xen/include/asm-x86/p2m.h | 6 +--
> 4 files changed, 114 insertions(+), 23 deletions(-)
>
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index fabcd06..e6fa85f 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -657,6 +657,9 @@ bool_t ept_handle_misconfig(uint64_t gpa)
> bool_t spurious;
> int rc;
>
> +if ( altp2m_active(curr->domain) )
> +p2m = p2m_get_altp2m(curr);
> +
> p2m_lock(p2m);
>
> spurious = curr->arch.hvm.vmx.ept_spurious_misconfig;
> @@ -1440,6 +1443,11 @@ void p2m_init_altp2m_ept(struct domain *d,
> unsigned int i)
> struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
> struct ept_data *ept;
>
> +p2m->max_mapped_pfn = hostp2m->max_mapped_pfn;
> +p2m->default_access = hostp2m->default_access;
> +p2m->domain = hostp2m->domain;
> +
> +p2m->global_logdirty = hostp2m->global_logdirty;
> p2m->ept.ad = hostp2m->ept.ad;
> p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
> p2m->max_remapped_gfn = 0;
> diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
> index 55df185..3828088 100644
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -464,6 +465,13 @@ int p2m_pt_handle_deferred_changes(uint64_t
> gpa)
> struct p2m_domain *p2m = p2m_get_hostp2m(current->domain);
> int rc;
>
> +/*
> + * Should altp2m ever be enabled for NPT / shadow use, this code
> + * should be updated to make use of the active altp2m, like
> + * ept_handle_misconfig().
> + */
> +ASSERT(!altp2m_active(current->domain));
> +
> p2m_lock(p2m);
> rc = do_recalc(p2m, PFN_DOWN(gpa));
> p2m_unlock(p2m);
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 69536c1..c8561ba 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -277,7 +277,6 @@ int p2m_init(struct domain *d)
> int p2m_is_logdirty_range(struct p2m_domain *p2m, unsigned long start,
>unsigned long end)
> {
> -ASSERT(p2m_is_hostp2m(p2m));
> if ( p2m->global_logdirty ||
> rangeset_contains_range(p2m->logdirty_ranges, start, end) )
> return 1;
> @@ -286,31 +285,79 @@ int p2m_is_logdirty_range(struct p2m_domain
> *p2m, unsigned long start,
> return 0;
> }
>
> +static void change_entry_type_global(struct p2m_domain *p2m,
> + p2m_type_t ot, p2m_type_t nt)
> +{
> +p2m->change_entry_type_global(p2m, ot, nt);
> +p2m->global_logdirty = (nt == p2m_ram_logdirty);
> +}
> +
> void p2m_change_entry_type_global(struct domain *d,
>p2m_type_t ot, p2m_type_t nt)
> {
> -struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
>
> ASSERT(ot != nt);
> ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
>
> -p2m_lock(p2m);
> -p2m->change_entry_type_global(p2m, ot, nt);
> -p2m->global_logdirty = (nt == p2m_ram_logdirty);
> -p2m_unlock(p2m);
> +p2m_lock(hostp2m);
> +
> +change_entry_type_global(hostp2m, ot, nt);
> +
> +#ifdef CONFIG_HVM
> +if ( unlikely(altp2m_active(d)) )
> +{
> +unsigned int i;
> +
> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) )
> +{
> +struct p2m_domain
Re: [Xen-devel] [PATCH V5 1/3] x86/altp2m: propagate ept.ad changes to all active altp2ms
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Sunday, November 11, 2018 10:07 PM
>
> 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.
it's in the series now, instead of sending separately.
> 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.
>
> The p2m_{en,dis}able_hardware_log_dirty() hostp2m locking has
> been moved to the new ept_{en,dis}able_hardware_log_dirty()
> functions as part of the code refactoring, while locks for the
> individual altp2ms are taken in ept_set_ad_sync() (called by
> ept_{en,dis}able_pml()).
>
> Signed-off-by: Razvan Cojocaru
> Suggested-by: George Dunlap
> Tested-by: Tamas K Lengyel
> Acked-by: George Dunlap
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: Unify hvm_event_pending()'s API with the !CONFIG_HVM version
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Friday, November 9, 2018 10:42 PM > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 8/8] x86/vvmx: fix I/O and MSR bitmaps mapping
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Tuesday, November 6, 2018 8:08 PM > > Currently Xen tries to map bitmaps during emulation of vmptrld and > vmwrite. This is wrong: a guest can store arbitrary values in those > fields. > > Make bitmaps mapping happen only during a nested vmentry and only if > the appropriate execution controls are turned on by L1 hypervisor. > > For performance reasons, Xen maps bitmaps only: > > 1. During the first nested vmentry > 2. After L1 has changed an appropriate vmcs field > 3. After nvmx_purge_vvmcs() was previously called > > Signed-off-by: Sergey Dyasli Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 130017: regressions - FAIL
flight 130017 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/130017/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 129475 build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf 85588389222a3636baf0f9ed8227f2434af4c3f9 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z8 days Failing since129526 2018-11-06 20:49:26 Z7 days 62 attempts Testing same since 130014 2018-11-14 03:43:46 Z0 days2 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 871 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 130014: regressions - FAIL
flight 130014 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/130014/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 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 version targeted for testing: ovmf 85588389222a3636baf0f9ed8227f2434af4c3f9 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z8 days Failing since129526 2018-11-06 20:49:26 Z7 days 61 attempts Testing same since 130014 2018-11-14 03:43:46 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 871 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 130006: regressions - FAIL
flight 130006 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/130006/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: ovmf bd224a5dad4d32f5224f5e8ae998b70e4621dcd3 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z8 days Failing since129526 2018-11-06 20:49:26 Z7 days 60 attempts Testing same since 129963 2018-11-13 14:41:56 Z0 days 10 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 842 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 12/13] IOMMU/x86: remove indirection from certain IOMMU hook accesses
> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, November 9, 2018 12:16 AM > > There's no need to go through an extra level of indirection. In order to > limit code churn, call sites using struct domain_iommu's platform_ops > don't get touched here, however. > > Signed-off-by: Jan Beulich Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 7/8] x86/vvmx: correctly report vvmcs size
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Tuesday, November 6, 2018 8:08 PM > > The size of Xen's virtual vmcs region is 4096 bytes (see comment about > Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly > report > it to the guest in case when VMCS shadowing is not available instead of > providing H/W value (which is usually smaller). > > Signed-off-by: Sergey Dyasli Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 6/8] x86/vvmx: refactor nvmx_handle_vmclear()
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Tuesday, November 6, 2018 8:08 PM > > 1. Add VMX_INSN_VMCLEAR_WITH_VMXON_PTR errno and add the > appropriate >check to the function. > > 2. Correct the return value for not-4KB-aligned case and for invalid >physaddr (when hvm_map_guest_frame_rw() fails). > > 3. Remove enum vmx_ops_result and use vmfail/vmsucceed() calls directly. > > Signed-off-by: Sergey Dyasli Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/8] x86/vvmx: correct vmfail() usage for vmptrld and vmclear
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Tuesday, November 6, 2018 8:08 PM > > Calling vmfail_valid() is correct only if vvmcx is valid. Modify > functions to use vmfail() instead which performs the necessary check. > > While at it, add ASSERTs into vmfail_valid/invalid() to quickly catch > an incorrect usage in the future. > > Signed-off-by: Sergey Dyasli Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/8] x86/vvmx: add VMX_INSN_INVEPT_INVVPID_INVALID_OP errno
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Tuesday, November 6, 2018 8:08 PM > > And use it in nvmx_handle_invept() and nvmx_handle_invvpid(). > > Signed-off-by: Sergey Dyasli Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/8] x86/nestedhvm: introduce vvmcx_valid()
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Tuesday, November 6, 2018 8:08 PM > > As a convenient helper function and refactor the code to use it. > > No functional change. > > Signed-off-by: Sergey Dyasli Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 130003: regressions - FAIL
flight 130003 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/130003/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf bd224a5dad4d32f5224f5e8ae998b70e4621dcd3 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z8 days Failing since129526 2018-11-06 20:49:26 Z7 days 59 attempts Testing same since 129963 2018-11-13 14:41:56 Z0 days9 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 842 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 130000: regressions - FAIL
flight 13 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/13/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf bd224a5dad4d32f5224f5e8ae998b70e4621dcd3 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z8 days Failing since129526 2018-11-06 20:49:26 Z7 days 58 attempts Testing same since 129963 2018-11-13 14:41:56 Z0 days8 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 842 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [GIT PULL] xen: fixes for 4.20-rc2
The pull request you sent on Sat, 10 Nov 2018 14:46:12 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-4.20a-rc2-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ab6e1f378f546b0caa616ac0fcc730725cc2d222 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/6] x86/emul: dedup hvmemul_cpuid() and pv_emul_cpuid()
On Mon, Nov 12, 2018 at 01:17:59AM -0700, Jan Beulich wrote: > >>> On 09.11.18 at 18:16, wrote: > > On 06/11/18 16:16, Jan Beulich wrote: > > On 06.11.18 at 16:52, wrote: > >>> On 06/11/18 15:38, Jan Beulich wrote: > >>> On 05.11.18 at 12:21, wrote: > > They are identical, so provide a single x86emul_cpuid() instead. > > > > As x86_emulate() now only uses the ->cpuid() hook for real CPUID > >>> instructions, > > the hook can be omitted from all special-purpose emulation ops. > So I was expecting the hook to go away altogether, but I > now realize that it can't because of some of the customization > that's needed. That, in turn, means that the removal of the > hook specification as per above will get us into problems the > moment we need to check a feature that can't be taken > straight from the policy object. I'm therefore unconvinced we > actually want to go this far. It'll require enough care already > to not blindly clone a new vcpu_has_...() wrongly from the > many pre-existing examples in such a case. Thoughts? > >>> All dynamic bits in CPUID are derived from other control state. e.g. we > >>> check CR4.OSXSAVE, not CPUID.OSXSAVE. The other dynamic bits are APIC, > >>> which comes from MSR_APIC_BASE, and OSPKE which also comes from CR4. > >>> > >>> In the emulator itself, I think it would be a bug if we ever had > >>> vcpu_has_osxsave etc, because that isn't how pipelines actually behave. > >>> The feature checks here are semantically equivalent to "do the > >>> instruction decode and execution units have silicon to cope with these > >>> instructions". > >> I agree that vcpu_has_os* makes no sense, but the APIC bit for > >> example isn't really pipeline / decoder related. > > > > Correct, so why do you think APIC matters? All interaction with the > > APIC is via its MMIO/MSR interface, rather than via dedicated instructions. > > It was a general example, not something that specifically matters here. > > >> And finally LWP, which again we can only hope we'll never have > >> to emulate. > > > > LWP doesn't exist any more, even on the hardware it used to exist on. > > It was never implemented on Fam17h, and was removed from Fam15/16h in a > > microcode update to make room to implement IBPB for Spectre v2 mitigations. > > > > I recommend we purge the support completely. > > I certainly don't mind; I'd prefer though if such a withdrawal of > functionality came actually from AMD. Brian? > > Jan LWP support isn't enabled on F15h system with the latest Ucode and it isn't available on F17h. I don't see any reason to keep it if it's hampering cleanup and reformatting. -- Brian Woods ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 13/18] xen/arm: Implement PSCI SYSTEM_SUSPEND call (physical interface)
On Mon, 12 Nov 2018, Mirela Simonovic wrote:
> PSCI system suspend function shall be invoked to finalize Xen suspend
> procedure. Resume entry point, which needs to be passed via 1st argument
> of PSCI system suspend call to the EL3, is hyp_resume. For now, hyp_resume
> is just a placeholder that will be implemented in assembly. Context ID,
> which is 2nd argument of system suspend PSCI call, is unused, as in Linux.
>
> Signed-off-by: Mirela Simonovic
> Signed-off-by: Saeed Nowshadi
>
> ---
> Changes in v2:
>
> -The commit message was stale - referring to the do_suspend function
> that has been renamed long time ago. Fixed commit message
> ---
> xen/arch/arm/arm64/entry.S| 3 +++
> xen/arch/arm/psci.c | 16
> xen/arch/arm/suspend.c| 4
> xen/include/asm-arm/psci.h| 1 +
> xen/include/asm-arm/suspend.h | 1 +
> 5 files changed, 25 insertions(+)
>
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index 97b05f53ea..dbc4717903 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -533,6 +533,9 @@ ENTRY(__context_switch)
> mov sp, x9
> ret
>
> +ENTRY(hyp_resume)
> +b .
> +
> /*
> * Local variables:
> * mode: ASM
> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> index a93121f43b..b100bd8ad2 100644
> --- a/xen/arch/arm/psci.c
> +++ b/xen/arch/arm/psci.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * While a 64-bit OS can make calls with SMC32 calling conventions, for
> @@ -67,6 +68,21 @@ void call_psci_cpu_off(void)
> }
> }
>
> +int call_psci_system_suspend(void)
> +{
> +#ifdef CONFIG_ARM_64
> +struct arm_smccc_res res;
> +
> +/* 2nd argument (context ID) is not used */
> +arm_smccc_smc(PSCI_1_0_FN64_SYSTEM_SUSPEND, __pa(hyp_resume), );
> +
> +return PSCI_RET(res);
> +#else
> +/* not supported */
> +return 1;
> +#endif
> +}
Given that suspend is unimplemented on arm32, the #ifdef is OK. But
in that case return PSCI_NOT_SUPPORTED for arm32.
Otherwise you should be able to remove this #ifdef by introducing
something similar to PSCI_0_2_FN_NATIVE, but for PSCI_1_0 calls.
> void call_psci_system_off(void)
> {
> if ( psci_ver > PSCI_VERSION(0, 1) )
> diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
> index d1b48c339a..37926374bc 100644
> --- a/xen/arch/arm/suspend.c
> +++ b/xen/arch/arm/suspend.c
> @@ -141,6 +141,10 @@ static long system_suspend(void *data)
> goto resume_irqs;
> }
>
> +status = call_psci_system_suspend();
> +if ( status )
> +dprintk(XENLOG_ERR, "PSCI system suspend failed, err=%d\n", status);
> +
> system_state = SYS_STATE_resume;
>
> gic_resume();
> diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
> index 26462d0c47..9f6116a224 100644
> --- a/xen/include/asm-arm/psci.h
> +++ b/xen/include/asm-arm/psci.h
> @@ -20,6 +20,7 @@ extern uint32_t psci_ver;
>
> int psci_init(void);
> int call_psci_cpu_on(int cpu);
> +int call_psci_system_suspend(void);
> void call_psci_cpu_off(void);
> void call_psci_system_off(void);
> void call_psci_system_reset(void);
> diff --git a/xen/include/asm-arm/suspend.h b/xen/include/asm-arm/suspend.h
> index de787d296a..7604e2e2e2 100644
> --- a/xen/include/asm-arm/suspend.h
> +++ b/xen/include/asm-arm/suspend.h
> @@ -2,6 +2,7 @@
> #define __ASM_ARM_SUSPEND_H__
>
> int32_t domain_suspend(register_t epoint, register_t cid);
> +void hyp_resume(void);
I think it would be better to separate physical suspend from virtual
suspend, like Julien suggested. As you separate the C implementation,
please also introduce separate header files (for instance vsuspend.h and
suspend.h).
> #endif
>
> --
> 2.13.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129995: regressions - FAIL
flight 129995 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129995/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: ovmf bd224a5dad4d32f5224f5e8ae998b70e4621dcd3 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z8 days Failing since129526 2018-11-06 20:49:26 Z7 days 57 attempts Testing same since 129963 2018-11-13 14:41:56 Z0 days7 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 842 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 10/18] xen/arm: Implement GIC suspend/resume functions (gicv2 only)
On Mon, 12 Nov 2018, Mirela Simonovic wrote:
> System suspend may lead to a state where GIC would be powered down.
> Therefore, Xen should save/restore the context of GIC on suspend/resume.
> Note that the context consists of states of registers which are
> controlled by the hypervisor. Other GIC registers which are accessible
> by guests are saved/restored on context switch.
> Tested on Xilinx Ultrascale+ MPSoC with (and without) powering down
> the GIC.
>
> Signed-off-by: Mirela Simonovic
> Signed-off-by: Saeed Nowshadi
> ---
> xen/arch/arm/gic-v2.c | 147
> ++
> xen/arch/arm/gic.c| 27 +
> xen/include/asm-arm/gic.h | 8 +++
> 3 files changed, 182 insertions(+)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index e7eb01f30a..bb52b64ecb 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -123,6 +123,25 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
> /* Maximum cpu interface per GIC */
> #define NR_GIC_CPU_IF 8
>
> +/* GICv2 registers to be saved/restored on system suspend/resume */
> +struct gicv2_context {
> +/* GICC context */
> +uint32_t gicc_ctlr;
> +uint32_t gicc_pmr;
> +uint32_t gicc_bpr;
> +/* GICD context */
> +uint32_t gicd_ctlr;
> +uint32_t *gicd_isenabler;
> +uint32_t *gicd_isactiver;
> +uint32_t *gicd_ipriorityr;
> +uint32_t *gicd_itargetsr;
> +uint32_t *gicd_icfgr;
> +};
> +
> +static struct gicv2_context gicv2_context;
> +
> +static void gicv2_alloc_context(struct gicv2_context *gc);
> +
> static inline void writeb_gicd(uint8_t val, unsigned int offset)
> {
> writeb_relaxed(val, gicv2.map_dbase + offset);
> @@ -1310,6 +1329,9 @@ static int __init gicv2_init(void)
>
> spin_unlock();
>
> +/* Allocate memory to be used for saving GIC context during the suspend
> */
> +gicv2_alloc_context(_context);
Please check for the return of gicv2_alloc_context and return error
accordingly.
> return 0;
> }
>
> @@ -1319,6 +1341,129 @@ static void gicv2_do_LPI(unsigned int lpi)
> BUG();
> }
>
> +static void gicv2_alloc_context(struct gicv2_context *gc)
> +{
> +uint32_t n = gicv2_info.nr_lines;
> +
> +gc->gicd_isenabler = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32));
> +if ( !gc->gicd_isenabler )
> +return;
I would return error and return error also below for all the other
similar cases.
> +gc->gicd_isactiver = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 32));
> +if ( !gc->gicd_isactiver )
> +goto free_gicd_isenabler;
> +
> +gc->gicd_itargetsr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4));
> +if ( !gc->gicd_itargetsr )
> +goto free_gicd_isactiver;
> +
> +gc->gicd_ipriorityr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 4));
> +if ( !gc->gicd_ipriorityr )
> +goto free_gicd_itargetsr;
> +
> +gc->gicd_icfgr = xzalloc_array(uint32_t, DIV_ROUND_UP(n, 16));
> +if ( gc->gicd_icfgr )
> +return;
> +
> +xfree(gc->gicd_ipriorityr);
> +
> +free_gicd_itargetsr:
You can have just one label that frees everything, as you can rely on
xfree working fine (doing nothing) for NULL pointers.
> +xfree(gc->gicd_itargetsr);
> +
> +free_gicd_isactiver:
> +xfree(gc->gicd_isactiver);
> +
> +free_gicd_isenabler:
> +xfree(gc->gicd_isenabler);
> +gc->gicd_isenabler = NULL;
> +}
> +
> +static int gicv2_suspend(void)
> +{
> +int i;
> +
> +/* Save GICC configuration */
> +gicv2_context.gicc_ctlr = readl_gicc(GICC_CTLR);
> +gicv2_context.gicc_pmr = readl_gicc(GICC_PMR);
> +gicv2_context.gicc_bpr = readl_gicc(GICC_BPR);
> +
> +/* If gicv2_alloc_context() hasn't allocated memory, return */
> +if ( !gicv2_context.gicd_isenabler )
> +return -ENOMEM;
If you are going to check for this, then please check for all the others
as well (gicd_isactiver, gicd_ipriorityr, etc.) But if you follow my
other suggestion to return error if we fail the memory allocation at
init, then this can become an ASSERT. Also, ASSERTS or checks should be
at the very beginning of this function.
> +/* Save GICD configuration */
> +gicv2_context.gicd_ctlr = readl_gicd(GICD_CTLR);
> +
> +for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ )
> +gicv2_context.gicd_isenabler[i] = readl_gicd(GICD_ISENABLER + i * 4);
> +
> +for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 32); i++ )
> +gicv2_context.gicd_isactiver[i] = readl_gicd(GICD_ISACTIVER + i * 4);
> +
> +for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ )
> +gicv2_context.gicd_ipriorityr[i] = readl_gicd(GICD_IPRIORITYR + i *
> 4);
> +
> +for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 4); i++ )
> +gicv2_context.gicd_itargetsr[i] = readl_gicd(GICD_ITARGETSR + i * 4);
> +
> +for ( i = 0; i < DIV_ROUND_UP(gicv2_info.nr_lines, 16); i++ )
> +gicv2_context.gicd_icfgr[i] = readl_gicd(GICD_ICFGR + i * 4);
Re: [Xen-devel] [PATCH] xen/keyhandler: Restore missing parenthesis in dump_domains()
On Tue, Nov 13, 2018 at 06:27:02PM +, Andrew Cooper wrote: > This was accidentially dropped in c/s 889b200cb52 "Change timestamps > representation for keyhandlers". > > 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] [qemu-mainline test] 129773: regressions - FAIL
flight 129773 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/129773/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 6 xen-install fail REGR. vs. 129514 test-armhf-armhf-xl-arndale 7 xen-boot fail REGR. vs. 129514 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 129514 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 129514 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 129514 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 129514 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 129514 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-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: qemuu160e5c22e55b3f775c2003dfc626fa872ee4a7a1 baseline version: qemuu31eac32a8cba966c374b39bc36afdcb2eb255ed6 Last test of basis 129514 2018-11-06 15:39:32 Z7 days Failing since129651 2018-11-08 16:05:29 Z5 days2 attempts Testing same since 129773 2018-11-10 19:09:11 Z3 days1 attempts People who touched revisions under test: Alexander Graf Alistair Francis Clement Deschamps Cédric Le Goater Daniel P. Berrangé David Gibson Dr. David Alan Gilbert Eduardo Habkost Eric Blake Greg Kurz Igor Mammedov Marc-André Lureau Maria Klimushenkova Mark Cave-Ayland Markus Armbruster Palmer Dabbelt Paolo Bonzini Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daudé Prasad J Pandit Richard Henderson Roman Kapl Rudolf Marek Suraj Jitindar Singh Thomas Huth Vitaly Kuznetsov Wolfgang Bumiller jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64
Re: [Xen-devel] Problems building and running Xen on Hikey960
On Tue, 13 Nov 2018 at 02:01, Julien Grall wrote: > On 11/11/18 1:15 AM, Matthew Daley wrote: > > Hi Julien, > > Hi Matthew, > > > On Sat, 10 Nov 2018 at 00:22, Julien Grall wrote: > >>> Firstly, Xen fails to bring up any other CPUs but the one it is booting > >>> on: > >>> > >>> (XEN) Bringing up CPU1 > >>> (XEN) Failed to bring up CPU1 > >>> (XEN) Failed to bring up CPU 1 (error -9) > >>> (XEN) Bringing up CPU2 > >>> (XEN) Failed to bring up CPU2 > >>> (XEN) Failed to bring up CPU 2 (error -9) > >>> (XEN) Bringing up CPU3 > >>> (XEN) Failed to bring up CPU3 > >>> (XEN) Failed to bring up CPU 3 (error -9) > >>> (XEN) Bringing up CPU4 > >>> (XEN) Failed to bring up CPU4 > >>> (XEN) Failed to bring up CPU 4 (error -9) > >>> (XEN) Bringing up CPU5 > >>> (XEN) Failed to bring up CPU5 > >>> (XEN) Failed to bring up CPU 5 (error -9) > >>> (XEN) Bringing up CPU6 > >>> (XEN) Failed to bring up CPU6 > >>> (XEN) Failed to bring up CPU 6 (error -9) > >>> (XEN) Bringing up CPU7 > >>> (XEN) Failed to bring up CPU7 > >>> (XEN) Failed to bring up CPU 7 (error -9) > >>> (XEN) Brought up 1 CPUs > >>> > >>> I have traced this error code -9 being returned by call_psci_cpu_on. > >> > >> A similar error was reported a couple of months on the mailing list. From > >> the > >> report, a regression was introduced between Xen 4.8 and unstable. > >> > >> Unfortunately, I don't have an hikey board to bisect it. May I ask if you > >> can > >> bisect it? If you can point the offending commit, I should be able to > >> provide > >> ideas why it breaks. > > > > I managed to bisect this to commit > > 9f954a5e90414d10632e6c2fef5a33ea8a4a1e4e. Reverting this revert (!) on > > top of current master leads to the CPUs (at least the big cores, as > > expected) being brought online correctly: > Thank you for bisecting Xen, it is actually poin to the commit I > suspected. I have been told that entry point for secondary CPUs on the > Hikey board may require to be below 4GB. > > I am not entirely sure how to address this yet. Would you mind to have a > try at the following patch? > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 80f00286d3..f1fdfa4c91 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -409,13 +409,11 @@ static paddr_t __init get_xen_paddr(void) > if ( !e ) > continue; > > -#ifdef CONFIG_ARM_32 > /* Xen must be under 4GB */ > if ( e > 0x1ULL ) > e = 0x1ULL; > if ( e < bank->start ) > continue; > -#endif > > s = e - min_size; > I gave this a go but unfortunately the same problem occurs (error -9s). Just to check nothing weird is happening I added a printk to check the value of __pa(init_secondary) in call_psci_cpu_on, giving 0xdfe00180. > > ...turns out that these nodes appear to belong to the little cores > > (which were not brought online previously and still aren't with the > > reverted revert), so munging the DT so as to remove these nodes fixes > > this problem too. > > We disable support of big.LITTLE by default because Xen currently > assumes all the CPUs are the same. This is not the case in the > big.LITTLE case. > > You can override that behavior by adding hmp-unsafe on Xen command line. Right. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 09/18] xen/arm: Add rcu_barrier() before enabling non-boot CPUs on resume
On Mon, 12 Nov 2018, Mirela Simonovic wrote: > The rcu_barrier() has to be added to ensure that the per cpu area is > freed before a non-boot CPU tries to initialize it (_free_percpu_area() > has to be called before the init_percpu_area()). This scenario occurs > when non-boot CPUs are hot-unplugged on suspend and hotplugged on resume. > > Signed-off-by: Mirela Simonovic > Signed-off-by: Saeed Nowshadi Reviewed-by: Stefano Stabellini > --- > xen/arch/arm/suspend.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c > index dae1b1f7d6..8e8e531d61 100644 > --- a/xen/arch/arm/suspend.c > +++ b/xen/arch/arm/suspend.c > @@ -133,6 +133,7 @@ static long system_suspend(void *data) > system_state = SYS_STATE_resume; > > resume_nonboot_cpus: > +rcu_barrier(); > enable_nonboot_cpus(); > thaw_domains(); > system_state = SYS_STATE_active; > -- > 2.13.0 > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 06/18] xen/x86: Move freeze/thaw_domains into common files
On Mon, 12 Nov 2018, Mirela Simonovic wrote:
> These functions will be reused by suspend/resume support for ARM.
>
> Signed-off-by: Mirela Simonovic
> Signed-off-by: Saeed Nowshadi
> ---
> xen/arch/x86/acpi/power.c | 28
> xen/common/domain.c | 29 +
> xen/include/xen/sched.h | 3 +++
> 3 files changed, 32 insertions(+), 28 deletions(-)
>
> diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> index 93e967fe8f..794750e45b 100644
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -109,34 +109,6 @@ static void device_power_up(enum dev_power_saved saved)
> }
> }
>
> -static void freeze_domains(void)
> -{
> -struct domain *d;
> -
> -rcu_read_lock(_read_lock);
> -/*
> - * Note that we iterate in order of domain-id. Hence we will pause dom0
> - * first which is required for correctness (as only dom0 can add domains
> to
> - * the domain list). Otherwise we could miss concurrently-created
> domains.
> - */
> -for_each_domain ( d )
> -domain_pause(d);
> -rcu_read_unlock(_read_lock);
> -}
> -
> -static void thaw_domains(void)
> -{
> -struct domain *d;
> -
> -rcu_read_lock(_read_lock);
> -for_each_domain ( d )
> -{
> -restore_vcpu_affinity(d);
> -domain_unpause(d);
> -}
> -rcu_read_unlock(_read_lock);
> -}
> -
> static void acpi_sleep_prepare(u32 state)
> {
> void *wakeup_vector_va;
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index d6650f0656..fdd00dc661 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1666,6 +1666,35 @@ int continue_hypercall_on_cpu(
> return 0;
> }
>
> +
NIT: spurious newline
Aside from that:
Acked-by: Stefano Stabellini
> +void freeze_domains(void)
> +{
> +struct domain *d;
> +
> +rcu_read_lock(_read_lock);
> +/*
> + * Note that we iterate in order of domain-id. Hence we will pause dom0
> + * first which is required for correctness (as only dom0 can add domains
> to
> + * the domain list). Otherwise we could miss concurrently-created
> domains.
> + */
> +for_each_domain ( d )
> +domain_pause(d);
> +rcu_read_unlock(_read_lock);
> +}
> +
> +void thaw_domains(void)
> +{
> +struct domain *d;
> +
> +rcu_read_lock(_read_lock);
> +for_each_domain ( d )
> +{
> +restore_vcpu_affinity(d);
> +domain_unpause(d);
> +}
> +rcu_read_unlock(_read_lock);
> +}
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 366acaf69a..c7a6d9504a 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -821,6 +821,9 @@ static inline int
> domain_pause_by_systemcontroller_nosync(struct domain *d)
> void domain_pause_except_self(struct domain *d);
> void domain_unpause_except_self(struct domain *d);
>
> +void freeze_domains(void);
> +void thaw_domains(void);
> +
> void cpu_init(void);
>
> struct scheduler;
> --
> 2.13.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 08/18] xen/arm: Disable/enable non-boot physical CPUs on suspend/resume
On Mon, 12 Nov 2018, Mirela Simonovic wrote:
> Non-boot CPUs have to be disabled on suspend and enabled on resume
> (hotplug-based mechanism). Disabling non-boot CPUs will lead to PSCI
> CPU_OFF to be called by each non-boot CPU. Depending on the underlying
> platform capabilities, this may lead to the physical powering down of
> CPUs. Tested on Xilinx Zynq Ultrascale+ MPSoC (including power down of
> each non-boot CPU).
>
> Signed-off-by: Mirela Simonovic
> Signed-off-by: Saeed Nowshadi
> ---
> xen/arch/arm/suspend.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/suspend.c b/xen/arch/arm/suspend.c
> index 575afd5eb8..dae1b1f7d6 100644
> --- a/xen/arch/arm/suspend.c
> +++ b/xen/arch/arm/suspend.c
> @@ -1,4 +1,5 @@
> #include
> +#include
> #include
> #include
> #include
> @@ -115,17 +116,29 @@ static void vcpu_suspend(register_t epoint, register_t
> cid)
> /* Xen suspend. Note: data is not used (suspend is the suspend to RAM) */
> static long system_suspend(void *data)
> {
> +int status;
> +
> BUG_ON(system_state != SYS_STATE_active);
>
> system_state = SYS_STATE_suspend;
> freeze_domains();
>
> +status = disable_nonboot_cpus();
> +if ( status )
> +{
> +system_state = SYS_STATE_resume;
> +goto resume_nonboot_cpus;
> +}
> +
> system_state = SYS_STATE_resume;
>
> +resume_nonboot_cpus:
> +enable_nonboot_cpus();
> thaw_domains();
> system_state = SYS_STATE_active;
> +dsb(sy);
>
> -return -ENOSYS;
> +return status;
> }
I think we need a spin_lock to protect system_suspend from concurrent
calls, or (better) we need to make sure that the caller is only allowed
to call system_suspend if there is just one vcpu active in the system,
and that vcpu is blocked on this PSCI system suspend call.
> int32_t domain_suspend(register_t epoint, register_t cid)
> --
> 2.13.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129992: regressions - FAIL
flight 129992 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129992/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: 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 test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf bd224a5dad4d32f5224f5e8ae998b70e4621dcd3 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z8 days Failing since129526 2018-11-06 20:49:26 Z7 days 56 attempts Testing same since 129963 2018-11-13 14:41:56 Z0 days6 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 842 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 15/18] xen/arm: Resume memory management on Xen resume
Hi, On 11/13/18 9:35 PM, Stefano Stabellini wrote: On Tue, 13 Nov 2018, Julien Grall wrote: On 13/11/2018 01:36, Stefano Stabellini wrote: On Mon, 12 Nov 2018, Julien Grall wrote: On 11/12/18 11:30 AM, Mirela Simonovic wrote: We can turn this assembly code into a .macro, so that at least when we get around to it, we just need to fix it one place. In fact, I noticed that the code sequence right before "mmu_resumed" and the one right after are both indentical to the ones head.S, it would be good to avoid the duplication if possible. This does not address my concern. We want to have suspend/resume compliant to the Arm architecture (at least to our best knowledge). Hiding it in a macro/function is not going to make it compliant. Nobody wants its platform randomly crashing on suspend/resume because the Arm Arm was knowingly not followed. This is more critical than the boot one as we are going to call that more often. So what is the action plan to correctly resume memory management in this series? My suggestion does not address your concern, but at least it limits the spreading of errors code-wise. You can't build a great building on a weak foundation. It is only natural for a contributor to start from existing code to write new code. It just happens that the existing code is broken, thus, > the new code is broken too. We can't really expect any different :) I didn't expect anything different. In fact, I explained why the code is wrong and asked what is the plan to fix it. I would have expect you or the contributor to come back with suggestion how to fix this. Instead you suggested to keep wrong code in Xen with no plan to resolve it. If we want the contributor to fix this, given that the change is a difficult modification to delicate assembly code, we need to provide detailed documentation and/or sample code. Otherwise I can't see how it can go well. I don't think it is that difficult at least compare to implementing suspend/resume. There are far more corner case in the latter. The rules are fairly simple here: 1) You cannot switch between TTBR without disabling the MMU and therefore use an ID map 2) We always need to keep an ID map in place to allow turning off the MMU 3) Replacing a valid mapping should follow the break-before make 4) Memory written with MMU/cache off should be precede by clean and followed by invalidate The best example might be KVM boot code yet the page-tables are very simplistic compare to Xen. Linux is not a good example because EL1 supports 2 set of page-tables. I am happy to provide more details if someone is going to look at it. 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] 129982: tolerable all pass - PUSHED
flight 129982 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/129982/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 15410d8fc8d6e63ab138a5c47427f418a43a1c56 baseline version: xen 1bd2b750537b656f3fa90857707be91f5ed8bfd8 Last test of basis 129960 2018-11-13 14:05:09 Z0 days Testing same since 129972 2018-11-13 17:00:31 Z0 days2 attempts People who touched revisions under test: Doug Goldstein Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 1bd2b75053..15410d8fc8 15410d8fc8d6e63ab138a5c47427f418a43a1c56 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 2/2] xen: use SYMBOL when required
On Tue, 13 Nov 2018, Jan Beulich wrote: > >>> On 13.11.18 at 14:17, wrote: > > On 13/11/2018 12:56, Jan Beulich wrote: > > On 13.11.18 at 00:06, wrote: > >>> --- a/xen/arch/x86/alternative.c > >>> +++ b/xen/arch/x86/alternative.c > >>> @@ -194,7 +194,7 @@ void init_or_livepatch apply_alternatives(struct > >>> alt_instr *start, > >>>* So be careful if you want to change the scan order to any other > >>>* order. > >>>*/ > >>> -for ( a = base = start; a < end; a++ ) > >>> +for ( a = base = start; SYMBOL(a) < SYMBOL(end); a++ ) > >> > >> At this point all is fine: end is allowed to point to the end of start[]. > > > > But it can also point to somewhere else. The compiler cannot know it, right? > > Correct. My point is that at this point the compiler cannot use its > knowledge of what is (il)legal to "optimize" generated code. > > >>> @@ -33,8 +33,8 @@ static int init_percpu_area(unsigned int cpu) > >>> if ( (p = alloc_xenheap_pages(PERCPU_ORDER, 0)) == NULL ) > >>> return -ENOMEM; > >>> > >>> -memset(p, 0, __per_cpu_data_end - __per_cpu_start); > >>> -__per_cpu_offset[cpu] = p - __per_cpu_start; > >>> +memset(p, 0, SYMBOL(__per_cpu_data_end) - SYMBOL(__per_cpu_start)); > >>> +__per_cpu_offset[cpu] = (unsigned long)p - SYMBOL(__per_cpu_start); > >> > >> Can't you make SYMBOL() retain the original type, such that casts > >> like this one aren't needed? As soon as the compiler doesn't know > >> anymore that particular globals (or statics) are used, it can't infer > >> anymore that two pointers can't possibly point into the same array. > > > > If SYMBOL() keeps the original type, then you will still substract 2 > > pointers. If the compiler can't infer the cannot possibly point into the > > same array, it also cannot infer they point to the same. So that would > > be undefined, right? > > Undefined behavior results if you _actually_ subtract pointers pointing > into different objects. Subtracting of pointers is not generally undefined. > The compiler can use undefined-ness only if it can prove that both > pointers do point into different objects. Let's remember that we are not trying to work-around the compiler, we are trying to make our code C standard compliant :-) The compiler might not be able to infer anymore that two pointers can't possibly point into the same array, but we would still be not-compliant. It doesn't solve our problem, especially in regards to certifications. I is safer to use unsigned long as return type for SYMBOL and avoid pointers comparisons completely. The code impact is very limited and then we don't have to prove same or different "objectness" at all. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 15/18] xen/arm: Resume memory management on Xen resume
On Tue, 13 Nov 2018, Julien Grall wrote: > Hi, > > On 13/11/2018 01:36, Stefano Stabellini wrote: > > On Mon, 12 Nov 2018, Julien Grall wrote: > > > On 11/12/18 11:30 AM, Mirela Simonovic wrote: > > We can turn this assembly code into a .macro, so that at least when we > > get around to it, we just need to fix it one place. In fact, I noticed > > that the code sequence right before "mmu_resumed" and the one right > > after are both indentical to the ones head.S, it would be good to avoid > > the duplication if possible. > > This does not address my concern. We want to have suspend/resume compliant to > the Arm architecture (at least to our best knowledge). Hiding it in a > macro/function is not going to make it compliant. > > Nobody wants its platform randomly crashing on suspend/resume because the Arm > Arm was knowingly not followed. This is more critical than the boot one as we > are going to call that more often. So what is the action plan to correctly > resume memory management in this series? My suggestion does not address your concern, but at least it limits the spreading of errors code-wise. It is only natural for a contributor to start from existing code to write new code. It just happens that the existing code is broken, thus, the new code is broken too. We can't really expect any different :) If we want the contributor to fix this, given that the change is a difficult modification to delicate assembly code, we need to provide detailed documentation and/or sample code. Otherwise I can't see how it can go well. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129987: regressions - FAIL
flight 129987 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129987/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: build-i386-libvirt1 build-check(1) blocked n/a 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 version targeted for testing: ovmf bd224a5dad4d32f5224f5e8ae998b70e4621dcd3 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z7 days 55 attempts Testing same since 129963 2018-11-13 14:41:56 Z0 days5 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 842 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 03/18] xen/arm: Save GIC and virtual timer context when the domain suspends
On Mon, 12 Nov 2018, Julien Grall wrote: > (+ Andre) > > On 11/12/18 5:42 PM, Mirela Simonovic wrote: > > Hi Julien, > > > > On Mon, Nov 12, 2018 at 6:00 PM Julien Grall wrote: > > > > > > > > > > > > On 11/12/18 4:52 PM, Mirela Simonovic wrote: > > > > Hi Julien, > > > > > > Hi, > > > > > > > Thanks for the feedback. > > > > > > > > On Mon, Nov 12, 2018 at 4:36 PM Julien Grall > > > > wrote: > > > > > > > > > > Hi Mirela, > > > > > > > > > > On 11/12/18 11:30 AM, Mirela Simonovic wrote: > > > > > > GIC and virtual timer context must be saved when the domain > > > > > > suspends. > > > > > > > > > > Please provide the rationale for this. Is it required by the spec? > > > > > > > > > > > > > This is required for GIC because a guest leaves enabled interrupts in > > > > the GIC that could wake it up, and on resume it should be able to > > > > detect which interrupt woke it up. Without saving/restoring the state > > > > of GIC this would not be possible. > > > > > > I am confused. In patch #10, you save the GIC host because the GIC can > > > be powered-down. Linux is also saving the GIC state. So how the > > > interrupt can come up if the GIC is powered down? > > > > > > > After Xen (or Linux in the config without Xen) hands over the control > > to EL3 on suspend (calls system suspend PSCI to EL3), it leaves > > enabled interrupts that are its wake-up sources. Saving a GIC state > > only means that its current configuration will be remembered somewhere > > in data structures, but the configuration is not changed on suspend. > > Everything that happens with interrupt configuration from this point > > on is platform specific. Now there are 2 options: 1) EL3 will never > > allow CPU0 to be powered down and the wake-up interrupt will indeed > > propagate via GIC; > > or 2) CPU0 will be powered down and the GIC may be > > powered down as well, so an external help is needed to deal with > > wake-up and resume (e.g. in order to react to a wake-up interrupt > > while the GIC is down, and power up CPU0). This external help is > > provided by some low-power processor outside of the Cortex-A cluster. > > > > So the platform firmware is responsible for properly configuring a > > wake-up path if GIC goes down. This is commonly handled by EL3 > > communicating with low-power processor. When the GIC power comes up, > > the interrupt triggered by a peripheral is still active and the > > software on Cortex-A cluster should be able to observe it once the GIC > > state is restored, i.e. interrupts get enabled at GIC. > > Thank you for the explanation. Now the question is why can't we reset at > least the GIC CPU interface? > > AFAIU, the guest should restore them in any case. The only things we need to > know is the interrupt was received for a given guest. We can then queue it and > wake-up the domain. > > This seems to fit with the description on top of gic_dist_save() in Linux > GICv2 driver. Can we rely on all PSCI compliant OSes to restore their own GIC again at resume? The PSCI spec is not very clear in that regard (at the the version I am looking at...) I am just asking so that we don't come up with a solution that only works with Linux. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)
On Tue, 13 Nov 2018, Julien Grall wrote: > > > > > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > > > > > > index e594b48d81..7f8105465c 100644 > > > > > > --- a/xen/arch/arm/domain.c > > > > > > +++ b/xen/arch/arm/domain.c > > > > > > @@ -97,6 +97,11 @@ static void ctxt_switch_from(struct vcpu *p) > > > > > >if ( is_idle_vcpu(p) ) > > > > > >return; > > > > > > > > > > > > +/* VCPU's context should not be saved if its domain is > > > > > > suspended */ > > > > > > +if ( p->domain->is_shut_down && > > > > > > +(p->domain->shutdown_code == SHUTDOWN_suspend) ) > > > > > > +return; > > > > > SHUTDOWN_suspend is used in Xen for other purpose (see > > > > > SCHEDOP_shutdown). The other user of that code relies on all the state > > > > > to be saved on suspend. > > > > > > > > > We just need a flag to mark a domain as suspended, and I do believe > > > > SHUTDOWN_suspend is not used anywhere else. > > > > Let's come back on this. > > > > > > SHUTDOWN_suspend is used for migration. > > > > That is true, but it is not only used for migration. It is also used > > for suspending a guest and saving its state to file with the intention > > of resuming it later from file. > > Which is some sort of migration at the end. However, they don't have the same > semantics as suspend/resume regarding the state of the vCPU. Right > > > Grep for it through the Xen > > > tree and you'll find several pieces of documentation, including the > > > description of what this shutdown code means. > > > > > > What you are introducing here is not a shutdown - it is a suspend with > > > the intent to resume executing later. As such, it shouldn't use Xen's > > > shutdown infrastructure, which exists mainly to communicate with the > > > toolstack. > > > > Future work will need toolstack support for suspending/resuming guests. > > SHUTDOWN_suspend is the most natural fit today; we don't want to hijack > > domain pause, because if we do, then we can't normally pause a domain > > anymore. > > Why? suspend/resume is like pausing the domain but will be resumed on event > (e.g interrupts) rather than user request. I meant to say two things. 1) Which domain state should we use for suspended guests? This patch is using SHUTDOWN_suspend. Taken on its own, a regular "pause state" sounds like an option, in fact it is necessary to set the domain as paused otherwise the scheduler will schedule it. But in addition we need to distinguish a normal paused state from a PSCI system suspend state. We need to know that the domain has been system-suspended with PSCI, not just paused. 2) This ties into the discussion of what xl commands we want to use to request a domU to suspend. We don't need to talk about it now, but at some point we'll want something equivalent to "xl save" or "xl trigger sleep" and "xl restore" or "xl trigger s3resume" for this suspended state. If we mark the domU simply as "paused" it will be difficult to implement correctly "xl restore" / "xl trigger s3resume". We should be able to distinguish a domain which is simply not running or paused (as in "xl pause") from one that has been put to sleep. Otherwise we won't be able to use "xl pause" in its original sense anymore. "xl pause" will become effectively "xl trigger sleep" on ARM. Which is something to consider but I don't think that is what we want. The most similar feature is ACPI S3 in x86-land but the current calls are so ACPI/x86 specific that don't make much sense on a ACPI-less ARM implementation. If I am not mistaken, on x86 there is a special struct domain flag for this: d->arch.hvm.is_s3_suspended. Let's leave aside the "which commands should we use" discussion for now because it doesn't related to this patch series. It seems to me that the best option is to introduce a new ARM specific struct domain flag, something akin to d->arch.hvm.is_s3_suspended but ARM PSCI specific.___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 02/18] xen/arm: Implement PSCI system suspend call (virtual interface)
On Mon, 12 Nov 2018, Julien Grall wrote:
> > > However, what is the issue with saving all the registers here?
> > >
> >
> > We need to save arguments that are provided by a guest with system
> > suspend PSCI call. These arguments are the entry point that needs to
> > be saved in program counter and context ID that needs to be saved in
> > x0/r0. We don't have these arguments here. Context switch happens
> > after processing the system suspend PSCI call, so it's too late.
>
> It does not feel right to modify ctxt_switch{from,to} for suspend/resume. If
> you want to reset the vCPU state before blocking the vCPU, then you should
> instead
You missed the end of the suggestion here
> Another way would be to reset the vCPU once you receive the interrupt.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 16/44] x86emul: support AVX512F v{, u}comis{d, s} insns
On 25/09/2018 14:35, Jan Beulich wrote: > Signed-off-by: Jan Beulich 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 v4 15/44] x86emul: support AVX512{F, DQ} FP broadcast insns
On 25/09/2018 14:35, Jan Beulich wrote:
> @@ -7979,6 +7991,42 @@ x86_emulate(
> dst.type = OP_NONE;
> break;
>
> +case X86EMUL_OPC_EVEX_66(0x0f38, 0x18): /* vbroadcastss
> xmm/m32,[xyz]mm{k} */
> +generate_exception_if(evex.w || evex.br, EXC_UD);
> +avx512_broadcast:
> +/*
> + * For the respective code below the main switch() to work we need to
> + * fold op_mask here: A source element gets read whenever any of its
> + * respective destination elements' mask bits is set.
> + */
> +if ( fault_suppression )
> +{
> +n = 1 << ((b & 3) - evex.w);
> +ASSERT(op_bytes == n * elem_bytes);
> +for ( i = n; i < (16 << evex.lr) / elem_bytes; i += n )
As before, we should have a release-build safe check of elem_bytes.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 14/44] x86emul: support AVX512F legacy-equivalent logic insns
On 25/09/2018 14:34, Jan Beulich wrote:
> Plus vpternlog{d,q} as being extensively used by the compiler, in order
> to facilitate test enabling in the harness as soon as possible. Also the
> twobyte_table[] entries for a few more insns get their .d8s field set
> right away, in order to not split and later re-combine the groups.
>
> Signed-off-by: Jan Beulich
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 v4 13/44] x86emul: support AVX512F fused-multiply-add insns
On 25/09/2018 14:33, Jan Beulich wrote: > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129979: regressions - FAIL
flight 129979 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129979/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: 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 test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf bd224a5dad4d32f5224f5e8ae998b70e4621dcd3 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 54 attempts Testing same since 129963 2018-11-13 14:41:56 Z0 days4 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 842 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 12/44] x86emul: support AVX512F misc legacy-equivalent FP insns
On 25/09/2018 14:33, Jan Beulich wrote: > Also correct an AVX counterpart's comment. > > Signed-off-by: Jan Beulich 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 v4 11/44] x86emul: support AVX512F "normal" FP compare insns
What do you consider "normal" here? On 25/09/2018 14:32, Jan Beulich wrote: > Also correct the AVX counterpart's comment. > > Signed-off-by: Jan Beulich The content itself Acked-by: Andrew Cooper , but preferably with a better description. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V5 2/3] x86/mm: allocate logdirty_ranges for altp2ms
On 11/13/18 8:43 PM, Razvan Cojocaru wrote: > On 11/13/18 7:57 PM, George Dunlap wrote: >> On 11/11/18 2:07 PM, Razvan Cojocaru wrote: >> At the moment we essentially have two "init" states: >> * After domain creation; altp2m structures allocated, but no rangesets, & c >> * After being enabled for the first time: rangesets mirroring hostp2m, >> p2m_init_altp2m_ept() initialization done >> >> Is there any particular reason we allocate the p2m structures on domain >> creation, but not logdirty range structures? It seems like allocating >> altp2m structures on-demand, rather than at domain creation time, might >> make a lot of the reasoning here simpler. > > I assume that this question is not addressed to me, since I'm not able > to answer it - I can only assume that having less heap used has been > preferred. Actually I now realize that you're asking why the hostp2m rangeset is created via paging_domain_init() in arch_domain_create() (so immediately on domain creation) while I'm allocating the altp2m rangesets on altp2m init. I'm doing that to save memory, since we can have MAX_ALTP2M altp2ms (which is currently 10), and only two active altp2ms - that means that I would allocate 10 rangesets and only use two. In fact we're currently only using 2 altp2ms and the hostp2m for our #VE work. That saves the space required for 8 rangesets. If that's not much, or if you think that the benefits of allocating them early outweigh the costs we can switch to allocating them on domain creation, like the hostp2m, and perhaps always keeping them in sync. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 10/44] x86emul: support AVX512DQ logic FP insns
On 25/09/2018 14:32, Jan Beulich wrote: > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 129972: regressions - FAIL
flight 129972 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/129972/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 5 host-ping-check-native fail REGR. vs. 129960 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen 15410d8fc8d6e63ab138a5c47427f418a43a1c56 baseline version: xen 1bd2b750537b656f3fa90857707be91f5ed8bfd8 Last test of basis 129960 2018-11-13 14:05:09 Z0 days Testing same since 129972 2018-11-13 17:00:31 Z0 days1 attempts People who touched revisions under test: Doug Goldstein Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail 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 Not pushing. commit 15410d8fc8d6e63ab138a5c47427f418a43a1c56 Author: Wei Liu Date: Wed Nov 7 12:31:49 2018 + automation: lift tools build restriction in build script The restrictions are mostly from Travis CI days when cross-compilation was not feasible. Now we will be building natively on Arm, remove those lines. Signed-off-by: Wei Liu Acked-by: Doug Goldstein commit 4cbc2985700669de420687750eecd295de02b6b7 Author: Wei Liu Date: Tue Nov 13 13:48:00 2018 + automation: add two Arm64 builds to Gitlab CI Add two gcc builds. Clang builds are known to be broken at the moment. Signed-off-by: Wei Liu Acked-by: Doug Goldstein commit 8cf264cba57ae7c2ae188697de8a20efb5b24603 Author: Wei Liu Date: Wed Nov 7 12:31:47 2018 + automation: add debian unstable arm64v8 image Unfortunately sharing dockerfile has proven impossible: 1) the base image is different; 2) Arm doesn't need libc-dev-i386; 3) Arm needs libfdt-dev. Signed-off-by: Wei Liu Acked-by: Doug Goldstein (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 V5 2/3] x86/mm: allocate logdirty_ranges for altp2ms
On 11/13/18 7:57 PM, George Dunlap wrote:
> On 11/11/18 2:07 PM, Razvan Cojocaru wrote:
>> This patch is a pre-requisite for the one fixing VGA logdirty
>> freezes when using altp2m. It only concerns itself with the
>> ranges allocation / deallocation / initialization part. While
>> touching the code, I've switched global_logdirty from bool_t
>> to bool.
>>
>> Signed-off-by: Razvan Cojocaru
>
> I've convinced myself that this patch is probably correct now, and as a
> result I've had a chance to look a bit at the resulting code. Which
> means, unfortunately, that I'm going to be a bit annoying and ask more
> questions that I didn't ask last time.
Thanks for the review, and please ask away. :)
>> ---
>> CC: George Dunlap
>> CC: Jan Beulich
>> CC: Andrew Cooper
>> CC: Wei Liu
>>
>> ---
>> Changes since V4:
>> - Always call p2m_free_logdirty() in p2m_free_one() (previously
>>the call was gated on hap_enabled(p2m->domain) && cpu_has_vmx).
>> ---
>> xen/arch/x86/mm/p2m.c | 74
>> ---
>> xen/include/asm-x86/p2m.h | 2 +-
>> 2 files changed, 58 insertions(+), 18 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 42b9ef4..69536c1 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -59,6 +59,28 @@ static void p2m_nestedp2m_init(struct p2m_domain *p2m)
>> #endif
>> }
>>
>> +static int p2m_init_logdirty(struct p2m_domain *p2m)
>> +{
>> +if ( p2m->logdirty_ranges )
>> +return 0;
>> +
>> +p2m->logdirty_ranges = rangeset_new(p2m->domain, "log-dirty",
>> +RANGESETF_prettyprint_hex);
>> +if ( !p2m->logdirty_ranges )
>> +return -ENOMEM;
>> +
>> +return 0;
>> +}
>> +
>> +static void p2m_free_logdirty(struct p2m_domain *p2m)
>> +{
>> +if ( !p2m->logdirty_ranges )
>> +return;
>> +
>> +rangeset_destroy(p2m->logdirty_ranges);
>> +p2m->logdirty_ranges = NULL;
>> +}
>> +
>> /* Init the datastructures for later use by the p2m code */
>> static int p2m_initialise(struct domain *d, struct p2m_domain *p2m)
>> {
>> @@ -107,6 +129,7 @@ free_p2m:
>>
>> static void p2m_free_one(struct p2m_domain *p2m)
>> {
>> +p2m_free_logdirty(p2m);
>> if ( hap_enabled(p2m->domain) && cpu_has_vmx )
>> ept_p2m_uninit(p2m);
>> free_cpumask_var(p2m->dirty_cpumask);
>> @@ -116,19 +139,19 @@ static void p2m_free_one(struct p2m_domain *p2m)
>> static int p2m_init_hostp2m(struct domain *d)
>> {
>> struct p2m_domain *p2m = p2m_init_one(d);
>> +int rc;
>>
>> -if ( p2m )
>> -{
>> -p2m->logdirty_ranges = rangeset_new(d, "log-dirty",
>> -RANGESETF_prettyprint_hex);
>> -if ( p2m->logdirty_ranges )
>> -{
>> -d->arch.p2m = p2m;
>> -return 0;
>> -}
>> +if ( !p2m )
>> +return -ENOMEM;
>> +
>> +rc = p2m_init_logdirty(p2m);
>> +
>> +if ( !rc )
>> +d->arch.p2m = p2m;
>> +else
>> p2m_free_one(p2m);
>> -}
>> -return -ENOMEM;
>> +
>> +return rc;
>> }
>>
>> static void p2m_teardown_hostp2m(struct domain *d)
>> @@ -138,7 +161,6 @@ static void p2m_teardown_hostp2m(struct domain *d)
>>
>> if ( p2m )
>> {
>> -rangeset_destroy(p2m->logdirty_ranges);
>> p2m_free_one(p2m);
>> d->arch.p2m = NULL;
>> }
>> @@ -2279,6 +2301,18 @@ void p2m_flush_altp2m(struct domain *d)
>> altp2m_list_unlock(d);
>> }
>
> I think everything above here could usefully be in its own patch; it
> would make it easier to verify that there were no functional changes in
> the refactoring.
Right, I'll split this patch then.
>> +static int p2m_init_altp2m_logdirty(struct p2m_domain *p2m)
>> +{
>> +struct p2m_domain *hostp2m = p2m_get_hostp2m(p2m->domain);
>> +int rc = p2m_init_logdirty(p2m);
>> +
>> +if ( rc )
>> +return rc;
>> +
>> +/* The following is really just a rangeset copy. */
>> +return rangeset_merge(p2m->logdirty_ranges, hostp2m->logdirty_ranges);
>> +}
>> +
>> int p2m_init_altp2m_by_id(struct domain *d, unsigned int idx)
>> {
>> int rc = -EINVAL;
>> @@ -2290,8 +2324,9 @@ int p2m_init_altp2m_by_id(struct domain *d, unsigned
>> int idx)
>>
>> if ( d->arch.altp2m_eptp[idx] == mfn_x(INVALID_MFN) )
>> {
>> -p2m_init_altp2m_ept(d, idx);
>> -rc = 0;
>> +rc = p2m_init_altp2m_logdirty(d->arch.altp2m_p2m[idx]);
>> +if ( !rc )
>> +p2m_init_altp2m_ept(d, idx);
>> }
>>
>> altp2m_list_unlock(d);
>> @@ -2310,9 +2345,13 @@ int p2m_init_next_altp2m(struct domain *d, uint16_t
>> *idx)
>> if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) )
>> continue;
>>
>> -p2m_init_altp2m_ept(d, i);
>> -*idx = i;
>> -rc = 0;
>> +rc = p2m_init_altp2m_logdirty(d->arch.altp2m_p2m[i]);
>> +
>> +if ( !rc
[Xen-devel] [PATCH] xen/keyhandler: Restore missing parenthesis in dump_domains()
This was accidentially dropped in c/s 889b200cb52 "Change timestamps
representation for keyhandlers".
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
CC: George Dunlap
CC: Andrii Anisov
---
xen/common/keyhandler.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 60bbeeb..9495601 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -286,8 +286,8 @@ static void dump_domains(unsigned char key)
s_time_t now = NOW();
#define tmpstr keyhandler_scratch
-printk("'%c' pressed -> dumping domain info (now = %"PRI_stime"\n", key,
- now);
+printk("'%c' pressed -> dumping domain info (now = %"PRI_stime")\n",
+ key, now);
rcu_read_lock(_read_lock);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 09/44] x86emul: support AVX512F legacy-equivalent arithmetic FP insns
On 25/09/2018 14:31, Jan Beulich wrote: > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129973: regressions - FAIL
flight 129973 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129973/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: 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-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf bd224a5dad4d32f5224f5e8ae998b70e4621dcd3 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 53 attempts Testing same since 129963 2018-11-13 14:41:56 Z0 days3 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 842 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 08/44] x86emul: use AVX512 logic for emulating V{, P}MASKMOV*
On 25/09/2018 14:30, Jan Beulich wrote: > The more generic AVX512 implementation allows quite a bit of insn- > specific code to be dropped/shared. > > Signed-off-by: Jan Beulich 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 00/18] xen/arm64: Suspend to RAM support for Xen
On Tue, 13 Nov 2018, Julien Grall wrote: > Hi Stefano, > > On 13/11/2018 02:22, Stefano Stabellini wrote: > > On Mon, 12 Nov 2018, Julien Grall wrote: > > > Hi Mirela, > > > > > > Thank you for posting the series. Could you provide a branch with the > > > patch > > > applied? > > > > > > On 11/12/18 11:30 AM, Mirela Simonovic wrote: > > > > > > > > > > > > > > > > The series does not include: > > > > a) UART driver-specific suspend/resume that gets called when console > > > > suspends > > > > > > I feel it will be difficult to test this series without UART driver > > > support. > > > Would it be possible to integrate them in that series? > > > > Actually, you can test this series simply using upstream Linux and > > upstream Xen + this series. You can use echo mem > /sys/power/state in > > dom0 to go into suspend, and for example setup an RTC wakeup event to > > wakeup after a certain amount of time. For instance echo +30 > > > /sys/class/rtc/rtc0/wakealarm. > > I am quite surprised this series is enough given there are a BUG() in the > suspend path for the console. > > So what is your xen command line? No, I made a mistake in rebasing Mirela's branch: I tested a branch which included the two unsent patches that removed exactly the BUG() you are talking about. Without those two patches, Xen is unable to resume correctly on the MPSoC due to the UART. Mirela, it is better to include the two patches in your next version of the series. If you think they are not up to quality for being merged upstream, i.e. they are just hacks for testing, that's OK, tag them with [PATCH DO-NOT-APPLY] to make it clear. It is also useful to post a git branch in your 0 email when the patch series is large. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V5 2/3] x86/mm: allocate logdirty_ranges for altp2ms
On 11/11/18 2:07 PM, Razvan Cojocaru wrote:
> This patch is a pre-requisite for the one fixing VGA logdirty
> freezes when using altp2m. It only concerns itself with the
> ranges allocation / deallocation / initialization part. While
> touching the code, I've switched global_logdirty from bool_t
> to bool.
>
> Signed-off-by: Razvan Cojocaru
I've convinced myself that this patch is probably correct now, and as a
result I've had a chance to look a bit at the resulting code. Which
means, unfortunately, that I'm going to be a bit annoying and ask more
questions that I didn't ask last time.
>
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Andrew Cooper
> CC: Wei Liu
>
> ---
> Changes since V4:
> - Always call p2m_free_logdirty() in p2m_free_one() (previously
>the call was gated on hap_enabled(p2m->domain) && cpu_has_vmx).
> ---
> xen/arch/x86/mm/p2m.c | 74
> ---
> xen/include/asm-x86/p2m.h | 2 +-
> 2 files changed, 58 insertions(+), 18 deletions(-)
>
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 42b9ef4..69536c1 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -59,6 +59,28 @@ static void p2m_nestedp2m_init(struct p2m_domain *p2m)
> #endif
> }
>
> +static int p2m_init_logdirty(struct p2m_domain *p2m)
> +{
> +if ( p2m->logdirty_ranges )
> +return 0;
> +
> +p2m->logdirty_ranges = rangeset_new(p2m->domain, "log-dirty",
> +RANGESETF_prettyprint_hex);
> +if ( !p2m->logdirty_ranges )
> +return -ENOMEM;
> +
> +return 0;
> +}
> +
> +static void p2m_free_logdirty(struct p2m_domain *p2m)
> +{
> +if ( !p2m->logdirty_ranges )
> +return;
> +
> +rangeset_destroy(p2m->logdirty_ranges);
> +p2m->logdirty_ranges = NULL;
> +}
> +
> /* Init the datastructures for later use by the p2m code */
> static int p2m_initialise(struct domain *d, struct p2m_domain *p2m)
> {
> @@ -107,6 +129,7 @@ free_p2m:
>
> static void p2m_free_one(struct p2m_domain *p2m)
> {
> +p2m_free_logdirty(p2m);
> if ( hap_enabled(p2m->domain) && cpu_has_vmx )
> ept_p2m_uninit(p2m);
> free_cpumask_var(p2m->dirty_cpumask);
> @@ -116,19 +139,19 @@ static void p2m_free_one(struct p2m_domain *p2m)
> static int p2m_init_hostp2m(struct domain *d)
> {
> struct p2m_domain *p2m = p2m_init_one(d);
> +int rc;
>
> -if ( p2m )
> -{
> -p2m->logdirty_ranges = rangeset_new(d, "log-dirty",
> -RANGESETF_prettyprint_hex);
> -if ( p2m->logdirty_ranges )
> -{
> -d->arch.p2m = p2m;
> -return 0;
> -}
> +if ( !p2m )
> +return -ENOMEM;
> +
> +rc = p2m_init_logdirty(p2m);
> +
> +if ( !rc )
> +d->arch.p2m = p2m;
> +else
> p2m_free_one(p2m);
> -}
> -return -ENOMEM;
> +
> +return rc;
> }
>
> static void p2m_teardown_hostp2m(struct domain *d)
> @@ -138,7 +161,6 @@ static void p2m_teardown_hostp2m(struct domain *d)
>
> if ( p2m )
> {
> -rangeset_destroy(p2m->logdirty_ranges);
> p2m_free_one(p2m);
> d->arch.p2m = NULL;
> }
> @@ -2279,6 +2301,18 @@ void p2m_flush_altp2m(struct domain *d)
> altp2m_list_unlock(d);
> }
I think everything above here could usefully be in its own patch; it
would make it easier to verify that there were no functional changes in
the refactoring.
> +static int p2m_init_altp2m_logdirty(struct p2m_domain *p2m)
> +{
> +struct p2m_domain *hostp2m = p2m_get_hostp2m(p2m->domain);
> +int rc = p2m_init_logdirty(p2m);
> +
> +if ( rc )
> +return rc;
> +
> +/* The following is really just a rangeset copy. */
> +return rangeset_merge(p2m->logdirty_ranges, hostp2m->logdirty_ranges);
> +}
> +
> int p2m_init_altp2m_by_id(struct domain *d, unsigned int idx)
> {
> int rc = -EINVAL;
> @@ -2290,8 +2324,9 @@ int p2m_init_altp2m_by_id(struct domain *d, unsigned
> int idx)
>
> if ( d->arch.altp2m_eptp[idx] == mfn_x(INVALID_MFN) )
> {
> -p2m_init_altp2m_ept(d, idx);
> -rc = 0;
> +rc = p2m_init_altp2m_logdirty(d->arch.altp2m_p2m[idx]);
> +if ( !rc )
> +p2m_init_altp2m_ept(d, idx);
> }
>
> altp2m_list_unlock(d);
> @@ -2310,9 +2345,13 @@ int p2m_init_next_altp2m(struct domain *d, uint16_t
> *idx)
> if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) )
> continue;
>
> -p2m_init_altp2m_ept(d, i);
> -*idx = i;
> -rc = 0;
> +rc = p2m_init_altp2m_logdirty(d->arch.altp2m_p2m[i]);
> +
> +if ( !rc )
> +{
> +p2m_init_altp2m_ept(d, i);
> +*idx = i;
> +}
It looks like there's a 1-1 correspondence between
p2m_init_altp2m_logdirty() succeeding and calling p2m_inti_altp2m_ept().
Would it make sense to combine them into the same function,
[Xen-devel] [PATCH v7b 08/25] xen/arm: probe domU kernels and initrds
Find addresses, sizes on device tree from kernel_probe.
Find the cmdline from the bootcmdlines array.
Introduce a new boot_module_find_by_addr_and_kind function to match not
just on boot module kind, but also by address so that we can support
multiple domains.
Introduce a boot_cmdline_find_by_name function to find the right struct
cmdline based on the device tree node name of the "xen,domain"
compatible node.
Set command line for dom0 in kernel_probe for consistency.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v6:
- style improvement in comment
- remove redundant cmdline assignment in construct_dom0
Changes in v5:
- constify kernel_probe
- add ASSERT and comment in kernel_probe
- limit variable scope
- fix printk message
- int/unsigned int
- set cmdline for dom0 too
- improve code readability
Changes in v3:
- retrieve cmdline from bootcmdlines array
Changes in v2:
- fix indentation
- unify kernel_probe with kernel_probe_domU
- find cmdline on device_tree from kernel_probe
---
xen/arch/arm/domain_build.c | 4 +--
xen/arch/arm/kernel.c | 64 -
xen/arch/arm/kernel.h | 2 +-
xen/arch/arm/setup.c| 31 ++
xen/include/asm-arm/setup.h | 3 +++
5 files changed, 93 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6b15bc7..59c9f34 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2107,7 +2107,6 @@ static void __init find_gnttab_region(struct domain *d,
int __init construct_dom0(struct domain *d)
{
-const struct bootcmdline *kernel =
boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
struct kernel_info kinfo = {};
struct vcpu *saved_current;
int rc, i, cpu;
@@ -2135,7 +2134,7 @@ int __init construct_dom0(struct domain *d)
kinfo.unassigned_mem = dom0_mem;
kinfo.d = d;
-rc = kernel_probe();
+rc = kernel_probe(, NULL);
if ( rc < 0 )
return rc;
@@ -2153,7 +2152,6 @@ int __init construct_dom0(struct domain *d)
#endif
-kinfo.cmdline = (kernel != NULL) ? >cmdline[0] : NULL;
allocate_memory(d, );
find_gnttab_region(d, );
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index da8410e..ae3673e 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -421,22 +421,72 @@ static int __init kernel_zimage32_probe(struct
kernel_info *info,
return 0;
}
-int __init kernel_probe(struct kernel_info *info)
+int __init kernel_probe(struct kernel_info *info,
+const struct dt_device_node *domain)
{
-struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+struct bootmodule *mod = NULL;
+struct bootcmdline *cmd = NULL;
+struct dt_device_node *node;
+u64 kernel_addr, initrd_addr, size;
int rc;
+/* domain is NULL only for the hardware domain */
+if ( domain == NULL )
+{
+ASSERT(is_hardware_domain(info->d));
+
+mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+
+info->kernel_bootmodule = mod;
+info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+
+cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
+if ( cmd )
+info->cmdline = >cmdline[0];
+}
+else
+{
+const char *name = NULL;
+
+dt_for_each_child_node(domain, node)
+{
+if ( dt_device_is_compatible(node, "multiboot,kernel") )
+{
+u32 len;
+const __be32 *val;
+
+val = dt_get_property(node, "reg", );
+dt_get_range(, node, _addr, );
+mod = boot_module_find_by_addr_and_kind(
+BOOTMOD_KERNEL, kernel_addr);
+info->kernel_bootmodule = mod;
+}
+else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
+{
+u32 len;
+const __be32 *val;
+
+val = dt_get_property(node, "reg", );
+dt_get_range(, node, _addr, );
+info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+BOOTMOD_RAMDISK, initrd_addr);
+}
+else
+continue;
+}
+name = dt_node_name(domain);
+cmd = boot_cmdline_find_by_name(name);
+if ( cmd )
+info->cmdline = >cmdline[0];
+}
if ( !mod || !mod->size )
{
printk(XENLOG_ERR "Missing kernel boot module?\n");
return -ENOENT;
}
-info->kernel_bootmodule = mod;
-
-printk("Loading kernel from boot module @ %"PRIpaddr"\n", mod->start);
-
-info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+printk("Loading Dom%pd kernel from boot module @ %"PRIpaddr"\n",
+ info->d, info->kernel_bootmodule->start);
if ( info->initrd_bootmodule )
printk("Loading ramdisk from
[Xen-devel] [PATCH v7b 20/25] xen/arm: introduce a union in vpl011
Introduce a union in struct vpl011 to contain the console ring members.
A later patch will add another member of the union for the case where
the backend is in Xen.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v4:
- name union "backend"
Changes in v3:
- rename ring field to dom
Changes in v2:
- new patch
---
xen/arch/arm/vpl011.c| 22 --
xen/include/asm-arm/vpl011.h | 8 ++--
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 117e41c..cc9ef20 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -83,7 +83,7 @@ static uint8_t vpl011_read_data(struct domain *d)
unsigned long flags;
uint8_t data = 0;
struct vpl011 *vpl011 = >arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
XENCONS_RING_IDX in_cons, in_prod;
VPL011_LOCK(d, flags);
@@ -146,7 +146,7 @@ static uint8_t vpl011_read_data(struct domain *d)
static void vpl011_update_tx_fifo_status(struct vpl011 *vpl011,
unsigned int fifo_level)
{
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
unsigned int fifo_threshold = sizeof(intf->out) - SBSA_UART_FIFO_LEVEL;
BUILD_BUG_ON(sizeof(intf->out) < SBSA_UART_FIFO_SIZE);
@@ -165,7 +165,7 @@ static void vpl011_write_data(struct domain *d, uint8_t
data)
{
unsigned long flags;
struct vpl011 *vpl011 = >arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
XENCONS_RING_IDX out_cons, out_prod;
VPL011_LOCK(d, flags);
@@ -383,7 +383,7 @@ static void vpl011_data_avail(struct domain *d)
{
unsigned long flags;
struct vpl011 *vpl011 = >arch.vpl011;
-struct xencons_interface *intf = vpl011->ring_buf;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
XENCONS_RING_IDX in_fifo_level, out_fifo_level;
@@ -460,14 +460,14 @@ int domain_vpl011_init(struct domain *d, struct
vpl011_init_info *info)
int rc;
struct vpl011 *vpl011 = >arch.vpl011;
-if ( vpl011->ring_buf )
+if ( vpl011->backend.dom.ring_buf )
return -EINVAL;
/* Map the guest PFN to Xen address space. */
rc = prepare_ring_for_helper(d,
gfn_x(info->gfn),
- >ring_page,
- >ring_buf);
+ >backend.dom.ring_page,
+ >backend.dom.ring_buf);
if ( rc < 0 )
goto out;
@@ -496,7 +496,8 @@ out2:
vgic_free_virq(d, GUEST_VPL011_SPI);
out1:
-destroy_ring_for_helper(>ring_buf, vpl011->ring_page);
+destroy_ring_for_helper(>backend.dom.ring_buf,
+ vpl011->backend.dom.ring_page);
out:
return rc;
@@ -506,11 +507,12 @@ void domain_vpl011_deinit(struct domain *d)
{
struct vpl011 *vpl011 = >arch.vpl011;
-if ( !vpl011->ring_buf )
+if ( !vpl011->backend.dom.ring_buf )
return;
free_xen_event_channel(d, vpl011->evtchn);
-destroy_ring_for_helper(>ring_buf, vpl011->ring_page);
+destroy_ring_for_helper(>backend.dom.ring_buf,
+ vpl011->backend.dom.ring_page);
}
/*
diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
index a82869a..a880bcf 100644
--- a/xen/include/asm-arm/vpl011.h
+++ b/xen/include/asm-arm/vpl011.h
@@ -30,8 +30,12 @@
#define SBSA_UART_FIFO_SIZE 32
struct vpl011 {
-void *ring_buf;
-struct page_info *ring_page;
+union {
+struct {
+void *ring_buf;
+struct page_info *ring_page;
+} dom;
+} backend;
uint32_tuartfr; /* Flag register */
uint32_tuartcr; /* Control register */
uint32_tuartimsc; /* Interrupt mask register*/
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 00/25] dom0less step1: boot multiple domains from device tree
Hi all,
This is first step toward "dom0less" as discussed in the various
certifications related threads and discussions.
The goal of this series is to enable Xen to boot multiple domains in
parallel, in addition to dom0, out of information found on device tree.
The device tree based boot protocol is extended to carry information
about DomUs. Based on that information, Xen creates and starts one or
more DomUs. DomUs created this way don't have access to xenstore for the
moment. This is actually OK, because this is meant for mission critical
applications that typically only access directly assigned devices. They
cannot tolerate interference or increased IRQ latency due to PV
protocols. Device assignment is not actually covered by this series, it
will be added later.
DomUs can print to the Xen serial using the CONSOLEIO hypercalls. A
virtual PL011 is also emulated for them so that they can use their
regular PL011 driver. This allows unmodified guests to run as Xen on ARM
guests -- no Xen support needed at all. Console input also comes from
the Xen serial: the Ctrl-AAA switching mechanism is extended to switch
among domUs, dom0, and Xen.
In this version of the series, I reordered the patches to make sure they
are all bisectable.
Cheers,
Stefano
The following changes since commit 15410d8fc8d6e63ab138a5c47427f418a43a1c56:
automation: lift tools build restriction in build script (2018-11-13 13:48:46
+)
are available in the git repository at:
http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git
dom0less-v7b
for you to fetch changes up to 7e979445513e6bb620c6fc623837da272808363c:
xen/arm: split domain_build.c (2018-11-13 09:49:33 -0800)
Stefano Stabellini (25):
xen: allow console_io hypercalls from certain DomUs
xen/arm: extend device tree based multiboot protocol
xen/arm: document dom0less
xen/arm: increase MAX_MODULES
xen/arm: check for multiboot nodes only under /chosen
xen/arm: introduce bootcmdlines
xen/arm: don't add duplicate boot modules, introduce domU flag
xen/arm: probe domU kernels and initrds
xen/arm: add start to struct bootcmdline
xen/arm: rename get_11_allocation_size to get_allocation_size
xen/arm: rename allocate_memory to allocate_memory_11
xen/arm: introduce allocate_memory
xen/arm: refactor construct_dom0
xen/arm: move unregister_init_virtual_region to init_done
xen/arm: introduce create_domUs
xen/arm: implement construct_domU
xen/arm: generate a simple device tree for domUs
xen/arm: make set_interrupt_ppi able to handle non-PPI
xen/arm: generate vpl011 node on device tree for domU
xen/arm: introduce a union in vpl011
xen/arm: refactor vpl011_data_avail
xen: support console_switching between Dom0 and DomUs on ARM
xen/arm: Allow vpl011 to be used by DomU
xen/arm: move kernel.h to asm-arm/
xen/arm: split domain_build.c
docs/INDEX |1 +
docs/features/dom0less.markdown| 49 ++
docs/misc/arm/device-tree/booting.txt | 107 +++
xen/arch/arm/acpi/Makefile |1 +
xen/arch/arm/acpi/domain_build.c | 591 +++
xen/arch/arm/bootfdt.c | 58 +-
xen/arch/arm/domain_build.c| 1092 +---
xen/arch/arm/kernel.c | 67 +-
xen/arch/arm/setup.c | 112 ++-
xen/arch/arm/vpl011.c | 297 ++--
xen/drivers/char/console.c | 90 ++-
xen/include/asm-arm/domain_build.h | 31 +
xen/{arch/arm => include/asm-arm}/kernel.h |6 +-
xen/include/asm-arm/setup.h| 36 +-
xen/include/asm-arm/vpl011.h | 20 +-
xen/include/asm-x86/setup.h|2 +
xen/include/xen/console.h |2 +
xen/include/xen/sched.h|2 +
xen/include/xsm/dummy.h|2 +
19 files changed, 1861 insertions(+), 705 deletions(-)
create mode 100644 docs/features/dom0less.markdown
create mode 100644 xen/arch/arm/acpi/domain_build.c
create mode 100644 xen/include/asm-arm/domain_build.h
rename xen/{arch/arm => include/asm-arm}/kernel.h (91%)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 09/25] xen/arm: add start to struct bootcmdline
Add a new start address field to struct bootcmdline to easily match a
cmdline to the corresponding bootmodule. This is useful for debugging
(not actually needed for functionalities today, but could be.)
Instead of printing the index in the cmdline array, print the start
address of the corresponding bootmodule for each cmdline in
early_print_info.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/bootfdt.c | 4 ++--
xen/arch/arm/setup.c| 3 ++-
xen/include/asm-arm/setup.h | 3 ++-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index df8c4df..a8a8dbd 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -238,7 +238,7 @@ static void __init process_multiboot_node(const void *fdt,
int node,
if ( !prop )
return;
add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data,
- kind, domU);
+ kind, start, domU);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -335,7 +335,7 @@ static void __init early_print_info(void)
}
printk("\n");
for ( i = 0 ; i < cmds->nr_mods; i++ )
-printk("CMDLINE[%d]:%s %s\n", i,
+printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
cmds->cmdline[i].dt_name,
>cmdline[i].cmdline[0]);
printk("\n");
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e0150ba..b5256d2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -254,7 +254,7 @@ struct bootmodule * __init
boot_module_find_by_kind(bootmodule_kind kind)
}
void __init add_boot_cmdline(const char *name, const char *cmdline,
- bootmodule_kind kind, bool domU)
+ bootmodule_kind kind, paddr_t start, bool domU)
{
struct bootcmdlines *cmds =
struct bootcmdline *cmd;
@@ -268,6 +268,7 @@ void __init add_boot_cmdline(const char *name, const char
*cmdline,
cmd = >cmdline[cmds->nr_mods++];
cmd->kind = kind;
cmd->domU = domU;
+cmd->start = start;
ASSERT(strlen(name) <= DT_MAX_NAME);
safe_strcpy(cmd->dt_name, name);
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index d4c5dda..5418f92 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -49,6 +49,7 @@ struct bootmodule {
struct bootcmdline {
bootmodule_kind kind;
bool domU;
+paddr_t start;
char dt_name[DT_MAX_NAME];
char cmdline[BOOTMOD_MAX_CMDLINE];
};
@@ -104,7 +105,7 @@ struct bootmodule *boot_module_find_by_kind(bootmodule_kind
kind);
struct bootmodule * boot_module_find_by_addr_and_kind(bootmodule_kind kind,
paddr_t start);
void add_boot_cmdline(const char *name, const char *cmdline,
- bootmodule_kind kind, bool domU);
+ bootmodule_kind kind, paddr_t start, bool domU);
struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
struct bootcmdline * boot_cmdline_find_by_name(const char *name);
const char *boot_module_kind_as_string(bootmodule_kind kind);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 06/25] xen/arm: introduce bootcmdlines
Introduce a new array to store the cmdline of each boot module. It is
separate from struct bootmodules. Remove the cmdline field from struct
boot_module. This way, kernels and initrds with the same address in
memory can share struct bootmodule (important because we want them to be
free'd only once), but they can still have their separate bootcmdline
entries.
Add a dt_name field to struct bootcmdline to make it easier to find the
correct entry. Store the name of the "xen,domain" compatible node (for
example "Dom1"). This is a better choice compared to the name of the
"multiboot,kernel" compatible node, because their names are not unique.
For instance there can be more than one "module@0x4c00" in the
system, but there can only be one "/chosen/Dom1".
Add a pointer to struct kernel_info to point to the cmdline for a given
kernel.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v6:
- code style
- add ack
Changes in v5:
- remove leftover DEBUG message
- improve commit message
- use kinfo->cmdline when possible
- move add_bood_cmdline to setup.c
Changes in v4:
- check that the multiboot node is under /chosen
- use cmd and cmds as variable names for struct bootcmdline and struct
bootcmdline*
- fix printk
- use ASSERT instea of panic
- do not add empty cmdline entries
- add more debug printks to early_print_info
- code style fixes
- add comment on DT_MAX_NAME
- increase DT_MAX_NAME to 41
- make nr_mods unsigned int
Changes in v3:
- introduce bootcmdlines
- do not modify boot_fdt_cmdline
- add comments
Changes in v2:
- new patch
---
xen/arch/arm/bootfdt.c | 43 ++---
xen/arch/arm/domain_build.c | 12 ++--
xen/arch/arm/kernel.h | 1 +
xen/arch/arm/setup.c| 47 ++---
xen/include/asm-arm/setup.h | 19 --
5 files changed, 87 insertions(+), 35 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index b94d8c7..0e0b3a5 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -172,11 +172,13 @@ static void __init process_multiboot_node(const void
*fdt, int node,
const __be32 *cell;
bootmodule_kind kind;
paddr_t start, size;
-const char *cmdline;
/* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
int len = 92;
char path[92];
-int ret;
+int parent_node, ret;
+
+parent_node = fdt_parent_offset(fdt, node);
+ASSERT(parent_node >= 0);
/* Check that the node is under "/chosen" (first 7 chars of path) */
ret = fdt_get_path(fdt, node, path, len);
@@ -228,17 +230,12 @@ static void __init process_multiboot_node(const void
*fdt, int node,
kind = BOOTMOD_XSM;
}
-prop = fdt_get_property(fdt, node, "bootargs", );
-if ( prop )
-{
-if ( len > BOOTMOD_MAX_CMDLINE )
-panic("module %s command line too long\n", name);
-cmdline = prop->data;
-}
-else
-cmdline = NULL;
+add_boot_module(kind, start, size);
-add_boot_module(kind, start, size, cmdline);
+prop = fdt_get_property(fdt, node, "bootargs", );
+if ( !prop )
+return;
+add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data, kind);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -284,7 +281,7 @@ static void __init process_chosen_node(const void *fdt, int
node,
printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
-add_boot_module(BOOTMOD_RAMDISK, start, end-start, NULL);
+add_boot_module(BOOTMOD_RAMDISK, start, end-start);
}
static int __init early_scan_node(const void *fdt,
@@ -307,6 +304,7 @@ static void __init early_print_info(void)
{
struct meminfo *mi =
struct bootmodules *mods =
+struct bootcmdlines *cmds =
int i, nr_rsvd;
for ( i = 0; i < mi->nr_banks; i++ )
@@ -315,12 +313,12 @@ static void __init early_print_info(void)
mi->bank[i].start + mi->bank[i].size - 1);
printk("\n");
for ( i = 0 ; i < mods->nr_mods; i++ )
-printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s %s\n",
+printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s\n",
i,
mods->module[i].start,
mods->module[i].start + mods->module[i].size,
- boot_module_kind_as_string(mods->module[i].kind),
- mods->module[i].cmdline);
+ boot_module_kind_as_string(mods->module[i].kind));
+
nr_rsvd = fdt_num_mem_rsv(device_tree_flattened);
for ( i = 0; i < nr_rsvd; i++ )
{
@@ -333,6 +331,11 @@ static void __init early_print_info(void)
i, s, e);
}
printk("\n");
+for ( i = 0 ; i < cmds->nr_mods; i++ )
+printk("CMDLINE[%d]:%s %s\n", i,
+ cmds->cmdline[i].dt_name,
+ >cmdline[i].cmdline[0]);
+printk("\n");
}
/**
@@
[Xen-devel] [PATCH v7b 16/25] xen/arm: implement construct_domU
Similar to construct_dom0, construct_domU creates a barebone DomU guest.
The device tree node passed as argument is compatible "xen,domain", see
docs/misc/arm/device-tree/booting.txt.
Remove #if 0 from allocate_memory as this patch will start using it.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v7:
- turn %lu into %PRIx64 for arm32 compilation
Changes in v5:
- move changes to kernel_probe prototype to previous patch
- improve commit message
- remove superflous allocation of d->vcpu
- use mem * SZ_1K
Changes in v4:
- constify kernel_probe
- change title
- better error messages and printed info
- 64bit memory
Changes in v3:
- move setting type before allocate_memory
- add ifdef around it and a comment
Changes in v2:
- rename mem to memory
- make cpus and memory mandatory
- remove wront comment from commit message
- cpus and memory are read as integers
- read the vpl011 option
---
xen/arch/arm/domain_build.c | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 43c728e..b48dd2b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -369,7 +370,6 @@ static void __init allocate_memory_11(struct domain *d,
}
}
-#if 0
static bool __init allocate_bank_memory(struct domain *d,
struct kernel_info *kinfo,
gfn_t sgfn,
@@ -468,7 +468,6 @@ fail:
" %ldKB unallocated. Fix the VMs configurations.\n",
(unsigned long)kinfo->unassigned_mem >> 10);
}
-#endif
static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
@@ -2310,7 +2309,37 @@ static int __init construct_domain(struct domain *d,
struct kernel_info *kinfo)
static int __init construct_domU(struct domain *d,
const struct dt_device_node *node)
{
-return -ENOSYS;
+struct kernel_info kinfo = {};
+int rc;
+u64 mem;
+
+rc = dt_property_read_u64(node, "memory", );
+if ( !rc )
+{
+printk("Error building DomU: cannot read \"memory\" property\n");
+return -EINVAL;
+}
+kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
+
+printk("*** LOADING DOMU cpus=%u memory=%"PRIx64"KB ***\n", d->max_vcpus,
mem);
+
+if ( vcpu_create(d, 0, 0) == NULL )
+return -ENOMEM;
+d->max_pages = ~0U;
+
+kinfo.d = d;
+
+rc = kernel_probe(, node);
+if ( rc < 0 )
+return rc;
+
+#ifdef CONFIG_ARM_64
+/* type must be set before allocate memory */
+d->arch.type = kinfo.type;
+#endif
+allocate_memory(d, );
+
+return construct_domain(d, );
}
void __init create_domUs(void)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 22/25] xen: support console_switching between Dom0 and DomUs on ARM
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow for switching between Xen, Dom0, and any of the
initial DomU created from Xen alongside Dom0 out of information provided
via device tree.
Rename xen_rx to console_rx to match the new behavior.
Clarify existing comment about "notify the guest", making it clear that
it is only about the hardware domain.
Switching the console input to domUs started from Xen at boot is
#ifdef'ed to 0 in this patch. The code will be enabled when
vpl011_rx_char_xen is introduced. For now it is disabled for
bisectability.
Signed-off-by: Stefano Stabellini
Acked-by: Jan Beulich
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
---
Changes in v6:
- improve in-code comment
- improve commit messahe
- code style
Changes in v5:
- move patch earlier and disable code that calls vpl011_rx_char_xen (not
defined yet)
- improve comments
- replace ifs with a switch
- code style
Changes in v4:
- handle console_rx == 0 in console_input_domain
- use rcu_lock_by_domain instead of get_domain_by_id
- handle the case where the returned domain is NULL
- send_global_virq(VIRQ_CONSOLE) only when chars are for Dom0
- make console_rx unsigned int
- fix comment
- code readability improvement
- fix opt_conswitch[1] == 'x' case
- move console_input_domain to next patch
Changes in v3:
- only call vpl011 functions ifdef CONFIG_SBSA_VUART_CONSOLE
- add blank line and spaces
- remove xen_rx from print messages
- rename xen_rx to console_rx
- keep switch_serial_input() at boot
- add better comments
- fix existing comment
- add warning if no guests console/uart is available
- add console_input_domain function
Changes in v2:
- only call vpl011_rx_char if the vpl011 has been initialized
---
xen/drivers/char/console.c | 82 ++
1 file changed, 68 insertions(+), 14 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 907aa97..414d329 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -31,10 +31,13 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86
#include
#include
+#else
+#include
#endif
/* console: comma-separated list of console outputs. */
@@ -391,31 +394,82 @@ static void dump_console_ring_key(unsigned char key)
free_xenheap_pages(buf, order);
}
-/* CTRL- switches input direction between Xen and DOM0. */
+/*
+ * CTRL- changes input direction, rotating among Xen, Dom0,
+ * and the DomUs started from Xen at boot.
+ */
#define switch_code (opt_conswitch[0]-'a'+1)
-static int __read_mostly xen_rx = 1; /* FALSE => input passed to domain 0. */
+/*
+ * console_rx=0 => input to xen
+ * console_rx=1 => input to dom0
+ * console_rx=N => input to dom(N-1)
+ */
+static unsigned int __read_mostly console_rx = 0;
static void switch_serial_input(void)
{
-static char *input_str[2] = { "DOM0", "Xen" };
-xen_rx = !xen_rx;
-printk("*** Serial input -> %s", input_str[xen_rx]);
+if ( console_rx == max_init_domid + 1 )
+{
+console_rx = 0;
+printk("*** Serial input to Xen");
+}
+else
+{
+console_rx++;
+printk("*** Serial input to DOM%d", console_rx - 1);
+}
+
if ( switch_code )
-printk(" (type 'CTRL-%c' three times to switch input to %s)",
- opt_conswitch[0], input_str[!xen_rx]);
+printk(" (type 'CTRL-%c' three times to switch input)",
+ opt_conswitch[0]);
printk("\n");
}
static void __serial_rx(char c, struct cpu_user_regs *regs)
{
-if ( xen_rx )
+switch ( console_rx )
+{
+case 0:
return handle_keypress(c, regs);
-/* Deliver input to guest buffer, unless it is already full. */
-if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
-serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
-/* Always notify the guest: prevents receive path from getting stuck. */
-send_global_virq(VIRQ_CONSOLE);
+case 1:
+/*
+ * Deliver input to the hardware domain buffer, unless it is
+ * already full.
+ */
+if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE )
+serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
+
+/*
+ * Always notify the hardware domain: prevents receive path from
+ * getting stuck.
+ */
+send_global_virq(VIRQ_CONSOLE);
+break;
+
+#if 0
+default:
+{
+struct domain *d = rcu_lock_domain_by_any_id(console_rx - 1);
+
+/*
+ * If we have a properly initialized vpl011 console for the
+ * domain, without a full PV ring to Dom0 (in that case input
+ * comes from the PV ring), then send the character to it.
+ */
+if ( d != NULL &&
+ !d->arch.vpl011.backend_in_domain
[Xen-devel] [PATCH v7b 02/25] xen/arm: extend device tree based multiboot protocol
Extend the existing device tree based multiboot protocol to include
information regarding multiple domains to boot.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- memory is 64bit
Changes in v3:
- remove "xen,initial-domain" for now
- make vpl011 an empty property
- memory in KBs
Changes in v2:
- lower case kernel
- rename mem to memory
- mandate cpus and memory
- replace domU-kernel with kernel and domU-ramdisk with ramdisk
- rename xen,domU with xen,domain
- add info about dom0
- switch memory and cpus to integers
- remove defaults
- add vpl011
---
docs/misc/arm/device-tree/booting.txt | 107 ++
1 file changed, 107 insertions(+)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index ce2d0dc..317a9e9 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -119,3 +119,110 @@ For those you would hardcode the Xen commandline in the
DTB under
line by writing bootargs (as for native Linux).
A Xen-aware bootloader would set xen,xen-bootargs for Xen, xen,dom0-bootargs
for Dom0 and bootargs for native Linux.
+
+
+Creating Multiple Domains directly from Xen
+===
+
+It is possible to have Xen create other domains, in addition to dom0,
+out of the information provided via device tree. A kernel and initrd
+(optional) need to be specified for each guest.
+
+For each domain to be created there needs to be one node under /chosen
+with the following properties:
+
+- compatible
+
+For domUs: "xen,domain"
+
+- memory
+
+ A 64-bit integer specifying the amount of kilobytes of RAM to
+allocate to the guest.
+
+- cpus
+
+An integer specifying the number of vcpus to allocate to the guest.
+
+- vpl011
+
+An empty property to enable/disable a virtual pl011 for the guest to use.
+
+- #address-cells and #size-cells
+
+Both #address-cells and #size-cells need to be specified because
+both sub-nodes (described shortly) have reg properties.
+
+Under the "xen,domain" compatible node, one or more sub-nodes are present
+for the DomU kernel and ramdisk.
+
+The kernel sub-node has the following properties:
+
+- compatible
+
+"multiboot,kernel"
+
+- reg
+
+Specifies the physical address of the kernel in RAM and its
+length.
+
+- bootargs (optional)
+
+Command line parameters for the guest kernel.
+
+The ramdisk sub-node has the following properties:
+
+- compatible
+
+"multiboot,ramdisk"
+
+- reg
+
+Specifies the physical address of the ramdisk in RAM and its
+length.
+
+
+Example
+===
+
+chosen {
+domU1 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x1>;
+memory = <0 131072>;
+cpus = <2>;
+vpl011;
+
+module@0x4a00 {
+compatible = "multiboot,kernel";
+reg = <0x0 0x4a00 0xff>;
+bootargs = "console=ttyAMA0 init=/bin/sh";
+};
+
+module@0x4b00 {
+compatible = "multiboot,ramdisk";
+reg = <0x0 0x4b00 0xff>;
+};
+};
+
+domU2 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x1>;
+memory = <0 65536>;
+cpus = <1>;
+
+module@0x4c00 {
+compatible = "multiboot,kernel";
+reg = <0x0 0x4c00 0xff>;
+bootargs = "console=ttyAMA0 init=/bin/sh";
+};
+
+module@0x4d00 {
+compatible = "multiboot,ramdisk";
+reg = <0x0 0x4d00 0xff>;
+};
+};
+};
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 01/25] xen: allow console_io hypercalls from certain DomUs
Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.
Signed-off-by: Stefano Stabellini
Acked-by: Daniel De Graaf
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
CC: dgde...@tycho.nsa.gov
---
Changes in v3:
- remove changes to hooks.c
Changes in v2:
- introduce is_console
- remove #ifdefs
---
xen/include/xen/sched.h | 2 ++
xen/include/xsm/dummy.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 3171eab..7e51a39 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -376,6 +376,8 @@ struct domain
bool auto_node_affinity;
/* Is this guest fully privileged (aka dom0)? */
bool is_privileged;
+/* Can this guest access the Xen console? */
+bool is_console;
/* Is this a xenstore domain (not dom0)? */
bool is_xenstore;
/* Domain's VCPUs are pinned 1:1 to physical CPUs? */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ae97182..a29d1ef 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -231,6 +231,8 @@ static XSM_INLINE int
xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain *d, int cmd)
{
XSM_ASSERT_ACTION(XSM_OTHER);
+if ( d->is_console )
+return xsm_default_action(XSM_HOOK, d, NULL);
#ifdef CONFIG_VERBOSE_DEBUG
if ( cmd == CONSOLEIO_write )
return xsm_default_action(XSM_HOOK, d, NULL);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 15/25] xen/arm: introduce create_domUs
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domain" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domain". Call construct_domU for each domain.
Introduce a simple global variable named max_init_domid to keep track of
the initial allocated domids. It holds the max domid among the initial
domains.
Move the discard_initial_modules after DomUs have been built.
First create domUs, then start dom0 -- no point in trying to start dom0
when the cpu is busy.
Signed-off-by: Stefano Stabellini
Acked-by: Jan Beulich
Reviewed-by: Julien Grall
CC: andrew.coop...@citrix.com
CC: jbeul...@suse.com
---
Changes in v7b:
- add XEN_DOMCTL_CDF_hvm_guest flag, now required
Changes in v5:
- use dt_property_read_bool
- improve commit message
- code style
- use dt_find_node_by_path instead of dt_find_node_by_name
- use true with is_console
Changes in v4:
- constify parameters
- nr_spis to 0 or GUEST_VPL011_SPI - 32 + 1 depending on vpl011
- remove pointless initializer
- remove change to domain_create for dom0 (useless)
- make construct_domU return error
Changes in v3:
- move patch earlier and introduce empty construct_domU to fix bisection
builds
- fix max_init_domid to actually hold the max domid among initial
domains (instead of max_domid + 1)
- move domain_unpause_by_systemcontroller(dom0) after creating domUs
Changes in v2:
- coding style
- set nr_spis to 32
- introduce create_domUs
---
xen/arch/arm/domain_build.c | 51 +
xen/arch/arm/setup.c| 5 +
xen/include/asm-arm/setup.h | 3 +++
xen/include/asm-x86/setup.h | 2 ++
4 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4707f42..43c728e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2306,6 +2307,51 @@ static int __init construct_domain(struct domain *d,
struct kernel_info *kinfo)
return 0;
}
+static int __init construct_domU(struct domain *d,
+ const struct dt_device_node *node)
+{
+return -ENOSYS;
+}
+
+void __init create_domUs(void)
+{
+struct dt_device_node *node;
+const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+
+BUG_ON(chosen == NULL);
+dt_for_each_child_node(chosen, node)
+{
+struct domain *d;
+struct xen_domctl_createdomain d_cfg = {
+.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
+.arch.nr_spis = 0,
+.flags = XEN_DOMCTL_CDF_hvm_guest,
+.max_vcpus = 1,
+.max_evtchn_port = -1,
+.max_grant_frames = 64,
+.max_maptrack_frames = 1024,
+};
+
+if ( !dt_device_is_compatible(node, "xen,domain") )
+continue;
+
+if ( dt_property_read_bool(node, "vpl011") )
+d_cfg.arch.nr_spis = GUEST_VPL011_SPI - 32 + 1;
+dt_property_read_u32(node, "cpus", _cfg.max_vcpus);
+
+d = domain_create(++max_init_domid, _cfg, false);
+if ( IS_ERR(d) )
+panic("Error creating domain %s", dt_node_name(node));
+
+d->is_console = true;
+
+if ( construct_domU(d, node) != 0 )
+panic("Could not set up domain %s", dt_node_name(node));
+
+domain_unpause_by_systemcontroller(d);
+}
+}
+
int __init construct_dom0(struct domain *d)
{
struct kernel_info kinfo = {};
@@ -2356,10 +2402,7 @@ int __init construct_dom0(struct domain *d)
if ( rc < 0 )
return rc;
-rc = construct_domain(d, );
-discard_initial_modules();
-
-return rc;
+return construct_domain(d, );
}
/*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f4e403a..e83221a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,11 +64,14 @@ static unsigned long opt_xenheap_megabytes __initdata;
integer_param("xenheap_megabytes", opt_xenheap_megabytes);
#endif
+domid_t __read_mostly max_init_domid;
+
static __used void init_done(void)
{
/* Must be done past setting system_state. */
unregister_init_virtual_region();
+discard_initial_modules();
free_init_memory();
startup_cpu_idle_loop();
}
@@ -964,6 +967,8 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
+create_domUs();
+
domain_unpause_by_systemcontroller(dom0);
/* Switch on to the dynamically allocated stack for the idle vcpu
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 5418f92..48187e1 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -75,6 +75,8 @@ struct bootinfo {
extern struct bootinfo bootinfo;
+extern domid_t max_init_domid;
+
void arch_init_memory(void);
void
[Xen-devel] [PATCH v7b 13/25] xen/arm: refactor construct_dom0
Move generic initializations out of construct_dom0 so that they can be
reused.
Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.
No functional changes in this patch.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- rename __construct_domain to construct_domain
Changes in v4:
- newline and style changes
Changes in v3:
- move setting type before allocate_memory
- add ifdef around it and a comment
Changes in v2:
- move discard_initial_modules() after __construct_domain()
- remove useless blank line
- leave safety BUG_ONs in __construct_domain
- rename prepare_dtb to prepare_dtb_hwdom
---
xen/arch/arm/domain_build.c | 122
1 file changed, 66 insertions(+), 56 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 957572b..4707f42 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1472,7 +1472,7 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
return res;
}
-static int __init prepare_dtb(struct domain *d, struct kernel_info *kinfo)
+static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info
*kinfo)
{
const p2m_type_t default_p2mt = p2m_mmio_direct_c;
const void *fdt;
@@ -2207,73 +2207,29 @@ static void __init find_gnttab_region(struct domain *d,
kinfo->gnttab_start, kinfo->gnttab_start + kinfo->gnttab_size);
}
-int __init construct_dom0(struct domain *d)
+static int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
{
-struct kernel_info kinfo = {};
struct vcpu *saved_current;
-int rc, i, cpu;
-
+int i, cpu;
struct vcpu *v = d->vcpu[0];
struct cpu_user_regs *regs = >arch.cpu_info->guest_cpu_user_regs;
-/* Sanity! */
-BUG_ON(d->domain_id != 0);
BUG_ON(d->vcpu[0] == NULL);
BUG_ON(v->is_initialised);
-printk("*** LOADING DOMAIN 0 ***\n");
-if ( dom0_mem <= 0 )
-{
-warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR
NOW\n");
-dom0_mem = MB(512);
-}
-
-
-iommu_hwdom_init(d);
-
-d->max_pages = ~0U;
-
-kinfo.unassigned_mem = dom0_mem;
-kinfo.d = d;
-
-rc = kernel_probe(, NULL);
-if ( rc < 0 )
-return rc;
-
#ifdef CONFIG_ARM_64
/* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */
-if ( !(cpu_has_el1_32) && kinfo.type == DOMAIN_32BIT )
+if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT )
{
printk("Platform does not support 32-bit domain\n");
return -EINVAL;
}
-d->arch.type = kinfo.type;
if ( is_64bit_domain(d) )
vcpu_switch_to_aarch64_mode(v);
#endif
-allocate_memory_11(d, );
-find_gnttab_region(d, );
-
-/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
-rc = gic_map_hwdom_extra_mappings(d);
-if ( rc < 0 )
-return rc;
-
-rc = platform_specific_mapping(d);
-if ( rc < 0 )
-return rc;
-
-if ( acpi_disabled )
-rc = prepare_dtb(d, );
-else
-rc = prepare_acpi(d, );
-
-if ( rc < 0 )
-return rc;
-
/*
* The following loads use the domain's p2m and require current to
* be a vcpu of the domain, temporarily switch
@@ -2286,20 +2242,18 @@ int __init construct_dom0(struct domain *d)
* kernel_load will determine the placement of the kernel as well
* as the initrd & fdt in RAM, so call it first.
*/
-kernel_load();
+kernel_load(kinfo);
/* initrd_load will fix up the fdt, so call it before dtb_load */
-initrd_load();
-dtb_load();
+initrd_load(kinfo);
+dtb_load(kinfo);
/* Now that we are done restore the original p2m and current. */
set_current(saved_current);
p2m_restore_state(saved_current);
-discard_initial_modules();
-
memset(regs, 0, sizeof(*regs));
-regs->pc = (register_t)kinfo.entry;
+regs->pc = (register_t)kinfo->entry;
if ( is_32bit_domain(d) )
{
@@ -2317,14 +2271,14 @@ int __init construct_dom0(struct domain *d)
*/
regs->r0 = 0; /* SBZ */
regs->r1 = 0x; /* We use DTB therefore no machine id */
-regs->r2 = kinfo.dtb_paddr;
+regs->r2 = kinfo->dtb_paddr;
}
#ifdef CONFIG_ARM_64
else
{
regs->cpsr = PSR_GUEST64_INIT;
/* From linux/Documentation/arm64/booting.txt */
-regs->x0 = kinfo.dtb_paddr;
+regs->x0 = kinfo->dtb_paddr;
regs->x1 = 0; /* Reserved for future use */
regs->x2 = 0; /* Reserved for future use */
regs->x3 = 0; /* Reserved for future use */
@@ -2352,6 +2306,62 @@ int __init construct_dom0(struct domain *d)
return 0;
}
+int __init construct_dom0(struct domain *d)
+{
+struct kernel_info kinfo = {};
+int rc;
+
+/* Sanity! */
+BUG_ON(d->domain_id != 0);
+
+printk("*** LOADING DOMAIN 0 ***\n");
+if (
[Xen-devel] [PATCH v7b 25/25] xen/arm: split domain_build.c
domain_build.c is too large.
Move all the ACPI specific device tree generating functions from
domain_build.c to acpi/domain_build.c.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v7:
- build domain_build.init.o
- remove "static" from prepare_acpi implementation
Changes in v6:
- fix license
Changes in v4:
- rename acpi_dt_build to domain_build.c
- add copyright header
- remove useless #include
- remove acpi_dt_build.h, add domain_build.h
---
xen/arch/arm/acpi/Makefile | 1 +
xen/arch/arm/acpi/domain_build.c | 591 +
xen/arch/arm/domain_build.c| 585 +---
xen/include/asm-arm/domain_build.h | 31 ++
4 files changed, 628 insertions(+), 580 deletions(-)
create mode 100644 xen/arch/arm/acpi/domain_build.c
create mode 100644 xen/include/asm-arm/domain_build.h
diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
index 23963f8..274dc2e 100644
--- a/xen/arch/arm/acpi/Makefile
+++ b/xen/arch/arm/acpi/Makefile
@@ -1,2 +1,3 @@
obj-y += lib.o
+obj-y += domain_build.init.o
obj-y += boot.init.o
diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
new file mode 100644
index 000..5aae32a
--- /dev/null
+++ b/xen/arch/arm/acpi/domain_build.c
@@ -0,0 +1,591 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef virt_to_mfn
+#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+
+#define ACPI_DOM0_FDT_MIN_SIZE 4096
+
+static int __init acpi_iomem_deny_access(struct domain *d)
+{
+acpi_status status;
+struct acpi_table_spcr *spcr = NULL;
+unsigned long mfn;
+int rc;
+
+/* Firstly permit full MMIO capabilities. */
+rc = iomem_permit_access(d, 0UL, ~0UL);
+if ( rc )
+return rc;
+
+/* TODO: Deny MMIO access for SMMU, GIC ITS */
+status = acpi_get_table(ACPI_SIG_SPCR, 0,
+(struct acpi_table_header **));
+
+if ( ACPI_FAILURE(status) )
+{
+printk("Failed to get SPCR table\n");
+return -EINVAL;
+}
+
+mfn = spcr->serial_port.address >> PAGE_SHIFT;
+/* Deny MMIO access for UART */
+rc = iomem_deny_access(d, mfn, mfn + 1);
+if ( rc )
+return rc;
+
+/* Deny MMIO access for GIC regions */
+return gic_iomem_deny_access(d);
+}
+
+static int __init acpi_route_spis(struct domain *d)
+{
+int i, res;
+struct irq_desc *desc;
+
+/*
+ * Route the IRQ to hardware domain and permit the access.
+ * The interrupt type will be set by set by the hardware domain.
+ */
+for( i = NR_LOCAL_IRQS; i < vgic_num_irqs(d); i++ )
+{
+/*
+ * TODO: Exclude the SPIs SMMU uses which should not be routed to
+ * the hardware domain.
+ */
+desc = irq_to_desc(i);
+if ( desc->action != NULL)
+continue;
+
+/* XXX: Shall we use a proper devname? */
+res = map_irq_to_domain(d, i, true, "ACPI");
+if ( res )
+return res;
+}
+
+return 0;
+}
+
+static int __init acpi_make_hypervisor_node(const struct kernel_info *kinfo,
+struct membank tbl_add[])
+{
+const char compat[] =
+"xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
+"xen,xen";
+int res;
+/* Convenience alias */
+void *fdt = kinfo->fdt;
+
+dt_dprintk("Create hypervisor node\n");
+
+/* See linux Documentation/devicetree/bindings/arm/xen.txt */
+res = fdt_begin_node(fdt, "hypervisor");
+if ( res )
+return res;
+
+/* Cannot use fdt_property_string due to embedded nulls */
+res = fdt_property(fdt, "compatible", compat, sizeof(compat));
+if ( res )
+return res;
+
+res = acpi_make_efi_nodes(fdt, tbl_add);
+if ( res )
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+/*
+ * Prepare a minimal DTB for Dom0 which contains bootargs, initrd, memory
+ * information, EFI table.
+ */
+static int __init create_acpi_dtb(struct kernel_info *kinfo,
+ struct membank tbl_add[])
+{
+int new_size;
+int ret;
+
+dt_dprintk("Prepare a min DTB for DOM0\n");
+
+/* Allocate min size for DT */
+new_size = ACPI_DOM0_FDT_MIN_SIZE;
+kinfo->fdt = xmalloc_bytes(new_size);
+
+if ( kinfo->fdt == NULL )
+return
[Xen-devel] [PATCH v7b 11/25] xen/arm: rename allocate_memory to allocate_memory_11
allocate_memory only deals with directly mapped memory. Rename it to
allocate_memory_11.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- add patch
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ca0c4f7..66a258a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -243,7 +243,8 @@ fail:
* (as described above) we allow higher allocations and continue until
* that runs out (or we have allocated sufficient dom0 memory).
*/
-static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+static void __init allocate_memory_11(struct domain *d,
+ struct kernel_info *kinfo)
{
const unsigned int min_low_order =
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
@@ -2152,7 +2153,7 @@ int __init construct_dom0(struct domain *d)
#endif
-allocate_memory(d, );
+allocate_memory_11(d, );
find_gnttab_region(d, );
/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 03/25] xen/arm: document dom0less
Add a new document to provide information on how to use dom0less related
features and their current limitations.
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- convert to markdown
- move to docs/features
- add entry to docs/INDEX
Changes in v4:
- rename to .txt
- improve wording
Changes in v3:
- add patch
---
docs/INDEX | 1 +
docs/features/dom0less.markdown | 49 +
2 files changed, 50 insertions(+)
create mode 100644 docs/features/dom0less.markdown
diff --git a/docs/INDEX b/docs/INDEX
index 868ab1f..e673edd 100644
--- a/docs/INDEX
+++ b/docs/INDEX
@@ -25,3 +25,4 @@ misc/arm/early-printk Enabling early printk on ARM
misc/arm/passthrough Passthrough a device described in the Device
Tree to a guest
misc/arm/device-tree/booting Device tree bindings to boot Xen
misc/arm/device-tree/passthrough Device tree binding to passthrough a
device
+features/dom0less.markdown Boot multiple domains from Xen in parallel
diff --git a/docs/features/dom0less.markdown b/docs/features/dom0less.markdown
new file mode 100644
index 000..4e342b7
--- /dev/null
+++ b/docs/features/dom0less.markdown
@@ -0,0 +1,49 @@
+Dom0less
+
+
+"Dom0less" is a set of Xen features that enable the deployment of a Xen
+system without an control domain (often referred to as "dom0"). Each
+feature can be used independently from the others, unless otherwise
+stated.
+
+Booting Multiple Domains from Device Tree
+-
+
+This feature enables Xen to create a set of DomUs at boot time.
+Information about the DomUs to be created by Xen is passed to the
+hypervisor via Device Tree. Specifically, the existing Device Tree based
+Multiboot specification has been extended to allow for multiple domains
+to be passed to Xen. See docs/misc/arm/device-tree/booting.txt for more
+information about the Multiboot specification and how to use it.
+
+Currently, a control domain ("dom0") is still required, but in the
+future it will become unnecessary when all domains are created
+directly from Xen. Instead of waiting for the control domain to be fully
+booted and the Xen tools to become available, domains created by Xen
+this way are started right away in parallel. Hence, their boot time is
+typically much shorter.
+
+Domains started by Xen at boot time currently have the following
+limitations:
+
+- They cannot be properly shutdown or rebooted using xl. If one of them
+ crashes, the whole platform should be rebooted.
+
+- Some xl operations might not work as expected. xl is meant to be used
+ with domains that have been created by it. Using xl with domains
+ started by Xen at boot might not work as expected.
+
+- The GIC version is the native version. In absence of other
+ information, the GIC version exposed to the domains started by Xen at
+ boot is the same as the native GIC version.
+
+- No PV drivers. There is no support for PV devices at the moment. All
+ devices need to be statically assigned to guests.
+
+- Pinning vCPUs of domains started by Xen at boot can be
+ done from the control domain, using `xl vcpu-pin` as usual. It is not
+ currently possible to configure vCPU pinning without a control domain.
+ However, the NULL scheduler can be selected by passing `sched=null` to
+ the Xen command line. The NULL scheduler automatically assigns and
+ pins vCPUs to pCPUs, but the vCPU-pCPU assignments cannot be
+ configured.
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 04/25] xen/arm: increase MAX_MODULES
Xen boot modules need to account not just for Dom0 but also for a few
potential DomUs, each of them coming with their own kernel and initrd.
Increase MAX_MODULES to 32 to allow for more DomUs.
Signed-off-by: Stefano Stabellini
Reviewed-by: Doug Goldstein
---
xen/include/asm-arm/setup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 11e1b2a..4e501ed 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -8,7 +8,7 @@
#define NR_MEM_BANKS 128
-#define MAX_MODULES 5 /* Current maximum useful modules */
+#define MAX_MODULES 32 /* Current maximum useful modules */
typedef enum {
BOOTMOD_XEN,
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 23/25] xen/arm: Allow vpl011 to be used by DomU
Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.
Call domain_vpl011_init during construct_domU if vpl011 is enabled.
Introduce a new ring struct with only the ring array to avoid a waste of
memory. Introduce separate read_data and write_data functions for
initial domains: vpl011_write_data_xen is very simple and just writes
to the console, while vpl011_read_data_xen is a duplicate of
vpl011_read_data. Although textually almost identical, we are forced to
duplicate the functions because the struct layout is different.
To avoid mixing the output of different domains on the console, buffer
the output chars and print line by line. Unless the domain has input
from the serial, in which case we want to print char by char for a
smooth user experience.
The size of SBSA_UART_OUT_BUF_SIZE is arbitrary, choose the same size
as VUART_BUF_SIZE used in vuart.c.
Export a function named console_input_domain() to allow others to know
which domains has input at a given time.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v7:
- merge patch with "xen/vpl011: buffer out chars when the backend is xen"
(no other changes)
- keep Julien's Acked-by as both patches were Acked by Julien
Changes in v5:
- renable call to vpl011_rx_char_xen from console.c
Changes in v4:
- code style
Changes in v3:
- add in-code comments
- improve existing comments
- remove ifdef around domain_vpl011_init in construct_domU
- add ASSERT
- use SBSA_UART_FIFO_SIZE for in buffer size
- rename ring_enable to backend_in_domain
- rename struct xencons_in to struct vpl011_xen_backend
- rename inring field to xen
- rename helper functions accordingly
- remove unnecessary stub implementation of vpl011_rx_char
- move vpl011_rx_char_xen within the file to avoid the need of a forward
declaration of vpl011_data_avail
- fix small bug in vpl011_rx_char_xen: increment in_prod before using it
to check xencons_queued.
Changes in v2:
- only init if vpl011
- rename vpl011_read_char to vpl011_rx_char
- remove spurious change
- fix coding style
- use different ring struct
- move the write_data changes to their own function
(vpl011_write_data_noring)
- duplicate vpl011_read_data
---
xen/arch/arm/domain_build.c | 9 +-
xen/arch/arm/vpl011.c| 231 ++-
xen/drivers/char/console.c | 10 +-
xen/include/asm-arm/vpl011.h | 12 +++
xen/include/xen/console.h| 2 +
5 files changed, 238 insertions(+), 26 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 579179d..d1024c5 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2631,7 +2631,14 @@ static int __init construct_domU(struct domain *d,
if ( rc < 0 )
return rc;
-return construct_domain(d, );
+rc = construct_domain(d, );
+if ( rc < 0 )
+return rc;
+
+if ( kinfo.vpl011 )
+rc = domain_vpl011_init(d, NULL);
+
+return rc;
}
void __init create_domUs(void)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index e29515a..7bc5eeb 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -78,6 +79,121 @@ static void vpl011_update_interrupt_status(struct domain *d)
#endif
}
+/*
+ * vpl011_write_data_xen writes chars from the vpl011 out buffer to the
+ * console. Only to be used when the backend is Xen.
+ */
+static void vpl011_write_data_xen(struct domain *d, uint8_t data)
+{
+unsigned long flags;
+struct vpl011 *vpl011 = >arch.vpl011;
+struct vpl011_xen_backend *intf = vpl011->backend.xen;
+struct domain *input = console_input_domain();
+
+VPL011_LOCK(d, flags);
+
+intf->out[intf->out_prod++] = data;
+if ( d == input )
+{
+if ( intf->out_prod == 1 )
+{
+printk("%c", data);
+intf->out_prod = 0;
+}
+else
+{
+if ( data != '\n' )
+intf->out[intf->out_prod++] = '\n';
+intf->out[intf->out_prod++] = '\0';
+printk("%s", intf->out);
+intf->out_prod = 0;
+}
+}
+else
+{
+if ( intf->out_prod == SBSA_UART_OUT_BUF_SIZE - 2 ||
+ data == '\n' )
+{
+if ( data != '\n' )
+intf->out[intf->out_prod++] = '\n';
+intf->out[intf->out_prod++] = '\0';
+printk("DOM%u: %s", d->domain_id, intf->out);
+intf->out_prod = 0;
+}
+}
+
+vpl011->uartris |= TXI;
+vpl011->uartfr &= ~TXFE;
+vpl011_update_interrupt_status(d);
+
+VPL011_UNLOCK(d, flags);
+if ( input != NULL )
+rcu_unlock_domain(input);
+}
+
+/*
+ * vpl011_read_data_xen reads data when the backend is xen. Characters
+ * are added to the
[Xen-devel] [PATCH v7b 07/25] xen/arm: don't add duplicate boot modules, introduce domU flag
Don't add duplicate boot modules (same kind and same start address),
they are freed later, we don't want to introduce double-free errors.
Introduce a domU flag in struct bootmodule and struct bootcmdline. Set
it for kernels and ramdisks of "xen,domain" nodes to avoid getting
confused in kernel_probe, where we try to guess which is the dom0 kernel
and initrd to be compatible with all versions of the multiboot spec.
boot_module_find_by_kind and boot_cmdline_find_by_kind automatically
check for !domU entries (they are only used for non-domU modules).
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
Changes in v6:
- update comments
Changes in v5:
- improve commit message
- add in-code comments
Changes in v4:
- use unsigned int
- better commit message
- introduce domU flag and usage
Changes in v2:
- new patch
---
xen/arch/arm/bootfdt.c | 11 +++
xen/arch/arm/setup.c| 34 +-
xen/include/asm-arm/setup.h | 12 ++--
3 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 0e0b3a5..df8c4df 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -176,6 +176,7 @@ static void __init process_multiboot_node(const void *fdt,
int node,
int len = 92;
char path[92];
int parent_node, ret;
+bool domU;
parent_node = fdt_parent_offset(fdt, node);
ASSERT(parent_node >= 0);
@@ -230,12 +231,14 @@ static void __init process_multiboot_node(const void
*fdt, int node,
kind = BOOTMOD_XSM;
}
-add_boot_module(kind, start, size);
+domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
+add_boot_module(kind, start, size, domU);
prop = fdt_get_property(fdt, node, "bootargs", );
if ( !prop )
return;
-add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data, kind);
+add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data,
+ kind, domU);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -281,7 +284,7 @@ static void __init process_chosen_node(const void *fdt, int
node,
printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
-add_boot_module(BOOTMOD_RAMDISK, start, end-start);
+add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
}
static int __init early_scan_node(const void *fdt,
@@ -352,7 +355,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
if ( ret < 0 )
panic("No valid device tree\n");
-add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt));
+add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
early_print_info();
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c07ae42..820d124 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -201,10 +201,12 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
}
struct bootmodule __init *add_boot_module(bootmodule_kind kind,
- paddr_t start, paddr_t size)
+ paddr_t start, paddr_t size,
+ bool domU)
{
struct bootmodules *mods =
struct bootmodule *mod;
+unsigned int i;
if ( mods->nr_mods == MAX_MODULES )
{
@@ -212,15 +214,31 @@ struct bootmodule __init *add_boot_module(bootmodule_kind
kind,
boot_module_kind_as_string(kind), start, start + size);
return NULL;
}
+for ( i = 0 ; i < mods->nr_mods ; i++ )
+{
+mod = >module[i];
+if ( mod->kind == kind && mod->start == start )
+{
+if ( !domU )
+mod->domU = false;
+return mod;
+}
+}
mod = >module[mods->nr_mods++];
mod->kind = kind;
mod->start = start;
mod->size = size;
+mod->domU = domU;
return mod;
}
+/*
+ * boot_module_find_by_kind can only be used to return Xen modules (e.g
+ * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
+ * modules.
+ */
struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
{
struct bootmodules *mods =
@@ -229,14 +247,14 @@ struct bootmodule * __init
boot_module_find_by_kind(bootmodule_kind kind)
for (i = 0 ; i < mods->nr_mods ; i++ )
{
mod = >module[i];
-if ( mod->kind == kind )
+if ( mod->kind == kind && !mod->domU )
return mod;
}
return NULL;
}
void __init add_boot_cmdline(const char *name, const char *cmdline,
- bootmodule_kind kind)
+ bootmodule_kind kind, bool domU)
{
struct bootcmdlines *cmds =
struct bootcmdline *cmd;
@@ -249,6 +267,7 @@ void __init add_boot_cmdline(const char *name, const char
*cmdline,
cmd = >cmdline[cmds->nr_mods++];
[Xen-devel] [PATCH v7b 05/25] xen/arm: check for multiboot nodes only under /chosen
Make sure to only look for multiboot compatible nodes only under
/chosen, not under any other paths (depth <= 3).
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- set path size to 92, treat -FDT_ERR_NOSPACE as erro
Changes in v6:
- do not proceed if fdt_get_path returns error != -FDT_ERR_NOSPACE
- remove sizeof, use hardcoded value
Changes in v5:
- add patch
- add check on return value of fdt_get_path
---
xen/arch/arm/bootfdt.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 44af11c..b94d8c7 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -173,7 +173,15 @@ static void __init process_multiboot_node(const void *fdt,
int node,
bootmodule_kind kind;
paddr_t start, size;
const char *cmdline;
-int len;
+/* sizeof("/chosen/") + DT_MAX_NAME + '/' + DT_MAX_NAME + '/0' => 92 */
+int len = 92;
+char path[92];
+int ret;
+
+/* Check that the node is under "/chosen" (first 7 chars of path) */
+ret = fdt_get_path(fdt, node, path, len);
+if ( ret != 0 || strncmp(path, "/chosen", 7) )
+return;
prop = fdt_get_property(fdt, node, "reg", );
if ( !prop )
@@ -286,8 +294,8 @@ static int __init early_scan_node(const void *fdt,
{
if ( device_tree_node_matches(fdt, node, "memory") )
process_memory_node(fdt, node, name, address_cells, size_cells);
-else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" )
||
- device_tree_node_compatible(fdt, node, "multiboot,module" ))
+else if ( depth <= 3 && (device_tree_node_compatible(fdt, node,
"xen,multiboot-module" ) ||
+ device_tree_node_compatible(fdt, node, "multiboot,module" )))
process_multiboot_node(fdt, node, name, address_cells, size_cells);
else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
process_chosen_node(fdt, node, name, address_cells, size_cells);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 18/25] xen/arm: make set_interrupt_ppi able to handle non-PPI
also rename it to set_interrupt.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/domain_build.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8822915..2d06ada 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -594,19 +594,20 @@ static int __init write_properties(struct domain *d,
struct kernel_info *kinfo,
typedef __be32 gic_interrupt_t[3];
-static void __init set_interrupt_ppi(gic_interrupt_t interrupt,
- unsigned int irq,
- unsigned int cpumask,
- unsigned int level)
+static void __init set_interrupt(gic_interrupt_t interrupt,
+ unsigned int irq,
+ unsigned int cpumask,
+ unsigned int level)
{
__be32 *cells = interrupt;
+bool is_ppi = !!(irq < 32);
BUG_ON(irq < 16);
-BUG_ON(irq >= 32);
+irq -= (is_ppi) ? 16: 32; /* PPIs start at 16, SPIs at 32 */
/* See linux
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
-dt_set_cell(, 1, 1); /* is a PPI */
-dt_set_cell(, 1, irq - 16); /* PPIs start at 16 */
+dt_set_cell(, 1, is_ppi); /* is a PPI? */
+dt_set_cell(, 1, irq);
dt_set_cell(, 1, (cpumask << 8) | level);
}
@@ -729,7 +730,7 @@ static int __init make_hypervisor_node(struct domain *d,
* - All CPUs
* TODO: Handle properly the cpumask;
*/
-set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property_interrupts(fdt, , 1);
if ( res )
return res;
@@ -1006,15 +1007,15 @@ static int __init make_timer_node(const struct domain
*d, void *fdt,
irq = timer_get_irq(TIMER_PHYS_SECURE_PPI);
dt_dprintk(" Secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
irq = timer_get_irq(TIMER_PHYS_NONSECURE_PPI);
dt_dprintk(" Non secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
irq = timer_get_irq(TIMER_VIRT_PPI);
dt_dprintk(" Virt interrupt %u\n", irq);
-set_interrupt_ppi(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property_interrupts(fdt, intrs, 3);
if ( res )
@@ -1603,9 +1604,9 @@ static int __init make_timer_domU_node(const struct
domain *d, void *fdt)
return res;
}
-set_interrupt_ppi(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property(fdt, "interrupts", intrs, sizeof (intrs[0]) * 3);
if ( res )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 19/25] xen/arm: generate vpl011 node on device tree for domU
Introduce vpl011 support to guests started from Xen: it provides a
simple way to print output from a guest, as most guests come with a
pl011 driver. It is also able to provide a working console with
interrupt support.
The UART exposed to the guest is a SBSA compatible UART and not a PL011.
SBSA UART is a subset of PL011 r1p5. A full PL011 implementation in Xen
would just be too difficult, so guests may require some drivers changes.
Enable vpl011 conditionally if the user requested it.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- use dt_property_read_bool
Changes in v4:
- move rename set_interrupt_ppi and making set_interrupt_ppi generic to
a separate patch
- properly name the vpl011 device node name
- code style
- use #define for addrcells and sizecells
Changes in v3:
- use bool
- retain BUG_ON(irq < 16)
- add vpl011 bool to kinfo
- return error of vpl011 is required but CONFIG_SBSA_VUART_CONSOLE is
missing
Changes in v2:
- code style fixes
- make set_interrupt_ppi generic
- rename set_interrupt_ppi to set_interrupt
- only make the vpl011 node if the option was enabled
---
xen/arch/arm/domain_build.c | 60 +
xen/arch/arm/kernel.h | 3 +++
2 files changed, 63 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2d06ada..579179d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1622,6 +1622,54 @@ static int __init make_timer_domU_node(const struct
domain *d, void *fdt)
return res;
}
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+static int __init make_vpl011_uart_node(const struct domain *d, void *fdt)
+{
+int res;
+gic_interrupt_t intr;
+__be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
+__be32 *cells;
+
+res = fdt_begin_node(fdt, "sbsa-uart@"__stringify(GUEST_PL011_BASE));
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,sbsa-uart");
+if ( res )
+return res;
+
+cells = [0];
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS,
+ GUEST_ROOT_SIZE_CELLS, GUEST_PL011_BASE,
+ GUEST_PL011_SIZE);
+if ( res )
+return res;
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if ( res )
+return res;
+
+set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+
+res = fdt_property(fdt, "interrupts", intr, sizeof (intr));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "interrupt-parent",
+GUEST_PHANDLE_GIC);
+if ( res )
+return res;
+
+/* Use a default baud rate of 115200. */
+fdt_property_u32(fdt, "current-speed", 115200);
+
+res = fdt_end_node(fdt);
+if ( res )
+return res;
+
+return 0;
+}
+#endif
+
/*
* The max size for DT is 2MB. However, the generated DT is small, 4KB
* are enough for now, but we might have to increase it in the future.
@@ -1683,6 +1731,16 @@ static int __init prepare_dtb_domU(struct domain *d,
struct kernel_info *kinfo)
if ( ret )
goto err;
+if ( kinfo->vpl011 )
+{
+ret = -EINVAL;
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+ret = make_vpl011_uart_node(d, kinfo->fdt);
+#endif
+if ( ret )
+goto err;
+}
+
ret = fdt_end_node(kinfo->fdt);
if ( ret < 0 )
goto err;
@@ -2551,6 +2609,8 @@ static int __init construct_domU(struct domain *d,
printk("*** LOADING DOMU cpus=%u memory=%"PRIx64"KB ***\n", d->max_vcpus,
mem);
+kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
+
if ( vcpu_create(d, 0, 0) == NULL )
return -ENOMEM;
d->max_pages = ~0U;
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 4320f72..33f3e72 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -33,6 +33,9 @@ struct kernel_info {
paddr_t dtb_paddr;
paddr_t initrd_paddr;
+/* Enable pl011 emulation */
+bool vpl011;
+
/* loader to use for this kernel */
void (*load)(struct kernel_info *info);
/* loader specific state */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 14/25] xen/arm: move unregister_init_virtual_region to init_done
Move unregister_init_virtual_region to init_done. Follow the same path
as x86. It is also useful to move it later so that create_domUs can be
called before that in following patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/setup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index b5256d2..f4e403a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -66,6 +66,9 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);
static __used void init_done(void)
{
+/* Must be done past setting system_state. */
+unregister_init_virtual_region();
+
free_init_memory();
startup_cpu_idle_loop();
}
@@ -961,9 +964,6 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
-/* Must be done past setting system_state. */
-unregister_init_virtual_region();
-
domain_unpause_by_systemcontroller(dom0);
/* Switch on to the dynamically allocated stack for the idle vcpu
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 17/25] xen/arm: generate a simple device tree for domUs
Introduce functions to generate a basic domU device tree, similar to the
existing functions in tools/libxl/libxl_arm.c.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- use d->arch.vgic.version
Changes in v4:
- code style
- two separate functions for gicv2 and gicv3
- remove useless local variables
- fix typos
- do not use host address and size cells for the guest DT
- use #define for addrcells and sizecells
Changes in v3:
- remove CONFIG_ACPI for make_chosen_node
- remove make_hypervisor_node until all Xen related functionalities
(evtchns, grant table, etc.) work correctly
Changes in v2:
- move prepare_dtb rename to previous patch
- use switch for the gic version
- use arm,gic-400 instead of arm,cortex-a15-gic
- add @unit-address in the gic node name
- add comment on DOMU_DTB_SIZE
---
xen/arch/arm/domain_build.c | 235 +++-
1 file changed, 233 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b48dd2b..8822915 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1034,7 +1034,6 @@ static int __init make_timer_node(const struct domain *d,
void *fdt,
return res;
}
-#ifdef CONFIG_ACPI
/*
* This function is used as part of the device tree generation for Dom0
* on ACPI systems, and DomUs started directly from Xen based on device
@@ -1080,7 +1079,6 @@ static int __init make_chosen_node(const struct
kernel_info *kinfo)
return res;
}
-#endif
static int __init map_irq_to_domain(struct domain *d, unsigned int irq,
bool need_mapping, const char *devname)
@@ -1472,6 +1470,235 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
return res;
}
+static int __init make_gicv2_domU_node(const struct domain *d, void *fdt)
+{
+int res = 0;
+__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
+__be32 *cells;
+
+res = fdt_begin_node(fdt,
"interrupt-controller@"__stringify(GUEST_GICD_BASE));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#address-cells", 0);
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-400");
+if ( res )
+return res;
+
+cells = [0];
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICD_BASE, GUEST_GICD_SIZE);
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICC_BASE, GUEST_GICC_SIZE);
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int __init make_gicv3_domU_node(const struct domain *d, void *fdt)
+{
+int res = 0;
+__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
+__be32 *cells;
+
+res = fdt_begin_node(fdt,
"interrupt-controller@"__stringify(GUEST_GICV3_GICD_BASE));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#address-cells", 0);
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-v3");
+if ( res )
+return res;
+
+cells = [0];
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICV3_GICD_BASE, GUEST_GICV3_GICD_SIZE);
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICV3_GICR0_BASE, GUEST_GICV3_GICR0_SIZE);
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int __init make_gic_domU_node(const struct domain *d, void *fdt)
+{
+switch ( d->arch.vgic.version )
+{
+case GIC_V3:
+return make_gicv3_domU_node(d, fdt);
+case GIC_V2:
+return make_gicv2_domU_node(d, fdt);
+default:
+panic("Unsupported GIC version");
+}
+}
+
+static int __init make_timer_domU_node(const struct domain *d, void *fdt)
+{
+int res;
+gic_interrupt_t
[Xen-devel] [PATCH v7b 24/25] xen/arm: move kernel.h to asm-arm/
It will be #included by a file in a xen/arch/arm subdirectory.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/domain_build.c | 2 +-
xen/arch/arm/kernel.c| 3 +-
xen/arch/arm/kernel.h| 86
xen/include/asm-arm/kernel.h | 86
4 files changed, 88 insertions(+), 89 deletions(-)
delete mode 100644 xen/arch/arm/kernel.h
create mode 100644 xen/include/asm-arm/kernel.h
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d1024c5..4fc81e4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,7 +26,6 @@
#include
#include
-#include "kernel.h"
static unsigned int __initdata opt_dom0_max_vcpus;
integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index ae3673e..d04a862 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -16,8 +16,7 @@
#include
#include
-
-#include "kernel.h"
+#include
#define UIMAGE_MAGIC 0x27051956
#define UIMAGE_NMLEN 32
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
deleted file mode 100644
index 33f3e72..000
--- a/xen/arch/arm/kernel.h
+++ /dev/null
@@ -1,86 +0,0 @@
-/*
- * Kernel image loading.
- *
- * Copyright (C) 2011 Citrix Systems, Inc.
- */
-#ifndef __ARCH_ARM_KERNEL_H__
-#define __ARCH_ARM_KERNEL_H__
-
-#include
-#include
-
-struct kernel_info {
-#ifdef CONFIG_ARM_64
-enum domain_type type;
-#endif
-
-struct domain *d;
-
-void *fdt; /* flat device tree */
-paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
-struct meminfo mem;
-
-/* kernel entry point */
-paddr_t entry;
-
-/* grant table region */
-paddr_t gnttab_start;
-paddr_t gnttab_size;
-
-/* boot blob load addresses */
-const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
-const char* cmdline;
-paddr_t dtb_paddr;
-paddr_t initrd_paddr;
-
-/* Enable pl011 emulation */
-bool vpl011;
-
-/* loader to use for this kernel */
-void (*load)(struct kernel_info *info);
-/* loader specific state */
-union {
-struct {
-paddr_t kernel_addr;
-paddr_t len;
-#ifdef CONFIG_ARM_64
-paddr_t text_offset; /* 64-bit Image only */
-#endif
-paddr_t start; /* 32-bit zImage only */
-} zimage;
-};
-};
-
-/*
- * Probe the kernel to detemine its type and select a loader.
- *
- * Sets in info:
- * ->type
- * ->load hook, and sets loader specific variables ->zimage
- */
-int kernel_probe(struct kernel_info *info, const struct dt_device_node
*domain);
-
-/*
- * Loads the kernel into guest RAM.
- *
- * Expects to be set in info when called:
- * ->mem
- * ->fdt
- *
- * Sets in info:
- * ->entry
- * ->dtb_paddr
- * ->initrd_paddr
- */
-void kernel_load(struct kernel_info *info);
-
-#endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-arm/kernel.h b/xen/include/asm-arm/kernel.h
new file mode 100644
index 000..33f3e72
--- /dev/null
+++ b/xen/include/asm-arm/kernel.h
@@ -0,0 +1,86 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __ARCH_ARM_KERNEL_H__
+#define __ARCH_ARM_KERNEL_H__
+
+#include
+#include
+
+struct kernel_info {
+#ifdef CONFIG_ARM_64
+enum domain_type type;
+#endif
+
+struct domain *d;
+
+void *fdt; /* flat device tree */
+paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+struct meminfo mem;
+
+/* kernel entry point */
+paddr_t entry;
+
+/* grant table region */
+paddr_t gnttab_start;
+paddr_t gnttab_size;
+
+/* boot blob load addresses */
+const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
+const char* cmdline;
+paddr_t dtb_paddr;
+paddr_t initrd_paddr;
+
+/* Enable pl011 emulation */
+bool vpl011;
+
+/* loader to use for this kernel */
+void (*load)(struct kernel_info *info);
+/* loader specific state */
+union {
+struct {
+paddr_t kernel_addr;
+paddr_t len;
+#ifdef CONFIG_ARM_64
+paddr_t text_offset; /* 64-bit Image only */
+#endif
+paddr_t start; /* 32-bit zImage only */
+} zimage;
+};
+};
+
+/*
+ * Probe the kernel to detemine its type and select a loader.
+ *
+ * Sets in info:
+ * ->type
+ * ->load hook, and sets loader specific variables ->zimage
+ */
+int kernel_probe(struct kernel_info *info, const struct dt_device_node
*domain);
+
+/*
+ * Loads the kernel into guest RAM.
+ *
+ * Expects to be set in info when called:
+ * ->mem
+ * ->fdt
+ *
+ * Sets in info:
+ * ->entry
+ *
[Xen-devel] [PATCH v7b 10/25] xen/arm: rename get_11_allocation_size to get_allocation_size
No functional changes.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- no change in print messages
- do not remove BUG_ON
Changes in v2:
- new patch
---
xen/arch/arm/domain_build.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 59c9f34..ca0c4f7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -77,7 +77,7 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
return vcpu_create(dom0, 0, 0);
}
-static unsigned int __init get_11_allocation_size(paddr_t size)
+static unsigned int __init get_allocation_size(paddr_t size)
{
/*
* get_order_from_bytes returns the order greater than or equal to
@@ -249,7 +249,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
const unsigned int min_order = get_order_from_bytes(MB(4));
struct page_info *pg;
-unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+unsigned int order = get_allocation_size(kinfo->unassigned_mem);
int i;
bool lowmem = true;
@@ -301,7 +301,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
* If we failed to allocate bank0 under 4GB, continue allocating
* memory from above 4GB and fill in banks.
*/
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
{
pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
@@ -312,7 +312,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
if ( lowmem && order < min_low_order)
{
D11PRINT("Failed at min_low_order, allow high allocations\n");
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
lowmem = false;
continue;
}
@@ -332,7 +332,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
if ( lowmem )
{
D11PRINT("Allocation below bank 0, allow high allocations\n");
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
lowmem = false;
continue;
}
@@ -347,7 +347,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
* Success, next time around try again to get the largest order
* allocation possible.
*/
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
}
if ( kinfo->unassigned_mem )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 21/25] xen/arm: refactor vpl011_data_avail
Move the code to calculate in_fifo_level and out_fifo_level out of
vpl011_data_avail, to the caller.
This change will make it possible to reuse vpl011_data_avail with
different ring structures in a later patch.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- remove forward declaration of vpl011_data_avail
Changes in v2:
- new patch
---
xen/arch/arm/vpl011.c | 64 +--
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index cc9ef20..e29515a 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -379,30 +379,13 @@ static const struct mmio_handler_ops vpl011_mmio_handler
= {
.write = vpl011_mmio_write,
};
-static void vpl011_data_avail(struct domain *d)
+static void vpl011_data_avail(struct domain *d,
+ XENCONS_RING_IDX in_fifo_level,
+ XENCONS_RING_IDX in_size,
+ XENCONS_RING_IDX out_fifo_level,
+ XENCONS_RING_IDX out_size)
{
-unsigned long flags;
struct vpl011 *vpl011 = >arch.vpl011;
-struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
-XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
-XENCONS_RING_IDX in_fifo_level, out_fifo_level;
-
-VPL011_LOCK(d, flags);
-
-in_cons = intf->in_cons;
-in_prod = intf->in_prod;
-out_cons = intf->out_cons;
-out_prod = intf->out_prod;
-
-smp_rmb();
-
-in_fifo_level = xencons_queued(in_prod,
- in_cons,
- sizeof(intf->in));
-
-out_fifo_level = xencons_queued(out_prod,
-out_cons,
-sizeof(intf->out));
/ Update the UART RX state /
@@ -411,11 +394,11 @@ static void vpl011_data_avail(struct domain *d)
vpl011->uartfr &= ~RXFE;
/* Set the FIFO_FULL bit if the Xen buffer is full. */
-if ( in_fifo_level == sizeof(intf->in) )
+if ( in_fifo_level == in_size )
vpl011->uartfr |= RXFF;
/* Assert the RX interrupt if the FIFO is more than half way filled. */
-if ( in_fifo_level >= sizeof(intf->in) - SBSA_UART_FIFO_LEVEL )
+if ( in_fifo_level >= in_size - SBSA_UART_FIFO_LEVEL )
vpl011->uartris |= RXI;
/*
@@ -428,7 +411,7 @@ static void vpl011_data_avail(struct domain *d)
/ Update the UART TX state /
-if ( out_fifo_level != sizeof(intf->out) )
+if ( out_fifo_level != out_size )
{
vpl011->uartfr &= ~TXFF;
@@ -446,13 +429,38 @@ static void vpl011_data_avail(struct domain *d)
if ( out_fifo_level == 0 )
vpl011->uartfr |= TXFE;
-
-VPL011_UNLOCK(d, flags);
}
static void vpl011_notification(struct vcpu *v, unsigned int port)
{
-vpl011_data_avail(v->domain);
+unsigned long flags;
+struct domain *d = v->domain;
+struct vpl011 *vpl011 = >arch.vpl011;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
+XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
+XENCONS_RING_IDX in_fifo_level, out_fifo_level;
+
+VPL011_LOCK(d, flags);
+
+in_cons = intf->in_cons;
+in_prod = intf->in_prod;
+out_cons = intf->out_cons;
+out_prod = intf->out_prod;
+
+smp_rmb();
+
+in_fifo_level = xencons_queued(in_prod,
+ in_cons,
+ sizeof(intf->in));
+
+out_fifo_level = xencons_queued(out_prod,
+out_cons,
+sizeof(intf->out));
+
+vpl011_data_avail(v->domain, in_fifo_level, sizeof(intf->in),
+ out_fifo_level, sizeof(intf->out));
+
+VPL011_UNLOCK(d, flags);
}
int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v7b 12/25] xen/arm: introduce allocate_memory
Introduce an allocate_memory function able to allocate memory for DomUs
and map it at the right guest addresses, according to the guest memory
map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
This is under #if 0 as not used for now.
Signed-off-by: Julien Grall
Signed-off-by: Stefano Stabellini
---
Changes in v7:
- use %pd
- populate bank earlier to remove local variables
Changes in v6:
- turn dprintks into printk
- use panic instead of printk+BUG_ON
- use Julien's implementation of allocate_bank_memory
Changes in v5:
- improve commit message
- code style
- remove unneeded local var
- while loop in allocate_bank_memory to allocate memory so that it
doesn't have to be contiguos
- combile while loops in allocate_memory
Changes in v4:
- move earlier, add #if 0
- introduce allocate_bank_memory, remove insert_bank
- allocate_bank_memory allocate memory and inserts the bank, while
allocate_memory specifies where to do that
Changes in v3:
- new patch
---
xen/arch/arm/domain_build.c | 101
1 file changed, 101 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 66a258a..957572b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -368,6 +368,107 @@ static void __init allocate_memory_11(struct domain *d,
}
}
+#if 0
+static bool __init allocate_bank_memory(struct domain *d,
+ struct kernel_info *kinfo,
+ gfn_t sgfn,
+ unsigned long tot_size)
+{
+int res;
+struct page_info *pg;
+struct membank *bank;
+unsigned int max_order = ~0;
+
+bank = >mem.bank[kinfo->mem.nr_banks];
+bank->start = gfn_to_gaddr(sgfn);
+bank->size = tot_size;
+
+while ( tot_size > 0 )
+{
+unsigned int order = get_allocation_size(tot_size);
+
+order = min(max_order, order);
+
+pg = alloc_domheap_pages(d, order, 0);
+if ( !pg )
+{
+/*
+ * If we can't allocate one page, then it is unlikely to
+ * succeed in the next iteration. So bail out.
+ */
+if ( !order )
+return false;
+
+/*
+ * If we can't allocate memory with order, then it is
+ * unlikely to succeed in the next iteration.
+ * Record the order - 1 to avoid re-trying.
+ */
+max_order = order - 1;
+continue;
+}
+
+res = guest_physmap_add_page(d, sgfn, page_to_mfn(pg), order);
+if ( res )
+{
+dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
+return false;
+}
+
+sgfn = gfn_add(sgfn, 1UL << order);
+tot_size -= (1ULL << (PAGE_SHIFT + order));
+}
+
+kinfo->mem.nr_banks++;
+kinfo->unassigned_mem -= bank->size;
+
+return true;
+}
+
+static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+{
+unsigned int i;
+unsigned long bank_size;
+
+printk(XENLOG_INFO "Allocating mappings totalling %ldMB for %pd:\n",
+ /* Don't want format this as PRIpaddr (16 digit hex) */
+ (unsigned long)(kinfo->unassigned_mem >> 20), d);
+
+kinfo->mem.nr_banks = 0;
+bank_size = MIN(GUEST_RAM0_SIZE, kinfo->unassigned_mem);
+if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
+ bank_size) )
+goto fail;
+
+bank_size = MIN(GUEST_RAM1_SIZE, kinfo->unassigned_mem);
+if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
+ bank_size) )
+goto fail;
+
+if ( kinfo->unassigned_mem )
+goto fail;
+
+for( i = 0; i < kinfo->mem.nr_banks; i++ )
+{
+printk(XENLOG_INFO "%pd BANK[%d] %#"PRIpaddr"-%#"PRIpaddr" (%ldMB)\n",
+ d,
+ i,
+ kinfo->mem.bank[i].start,
+ kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
+ /* Don't want format this as PRIpaddr (16 digit hex) */
+ (unsigned long)(kinfo->mem.bank[i].size >> 20));
+}
+
+return;
+
+fail:
+panic("Failed to allocate requested domain memory."
+ /* Don't want format this as PRIpaddr (16 digit hex) */
+ " %ldKB unallocated. Fix the VMs configurations.\n",
+ (unsigned long)kinfo->unassigned_mem >> 10);
+}
+#endif
+
static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
{
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 05/44] x86emul: support basic AVX512 moves
On 25/09/2018 14:28, Jan Beulich wrote:
> +#define avx512_vlen_check(lig) do { \
> +switch ( evex.lr ) \
> +{ \
> +default: \
> +generate_exception(EXC_UD); \
> +case 2: \
> +break; \
> +case 0: case 1: \
> +if (!(lig)) \
if ( !(lig) )
> +host_and_vcpu_must_have(avx512vl); \
> +break; \
> +} \
> +} while ( false )
> +
> static bool is_aligned(enum x86_segment seg, unsigned long offs,
> unsigned int size, struct x86_emulate_ctxt *ctxt,
> const struct x86_emulate_ops *ops)
> @@ -3272,6 +3387,7 @@ x86_emulate(
> b = ctxt->opcode;
> d = state.desc;
> #define state ()
> +elem_bytes = 4 << evex.w;
evex.w isn't filled by this point, is it? We only fill evex.lr in the
!evex_encoded() case AFAICT.
>
> generate_exception_if(state->not_64bit && mode_64bit(), EXC_UD);
>
> @@ -6348,6 +6521,41 @@ x86_emulate(
> ASSERT(!state->simd_size);
> break;
>
> +case X86EMUL_OPC_EVEX_66(0x0f, 0x6e): /* vmov{d,q} r/m,xmm */
> +case X86EMUL_OPC_EVEX_66(0x0f, 0x7e): /* vmov{d,q} xmm,r/m */
> +generate_exception_if((evex.lr || evex.opmsk || evex.br ||
> + evex.reg != 0xf || !evex.RX),
Are the inner brackets necessary?
> @@ -8819,6 +9070,44 @@ x86_emulate(
>!is_aligned(ea.mem.seg, ea.mem.off,
> op_bytes,
>ctxt, ops),
>EXC_GP, 0);
> +
> +if ( evex.br )
> +{
> +ASSERT((d & DstMask) != DstMem);
> +op_bytes = elem_bytes;
> +}
> +if ( evex.opmsk )
> +{
> +ASSERT(!(op_bytes % elem_bytes));
> +full = ~0ULL >> (64 - op_bytes / elem_bytes);
I think we want a path which checks elem_bytes != 0 which is
release-build safe. This feels like an XSA waiting to happen.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/5] xen/domain: Stricter configuration checking
>>> On 13.11.18 at 15:39, wrote: > On 13/11/2018 14:36, Wei Liu wrote: >> On Tue, Nov 13, 2018 at 07:14:24AM -0700, Jan Beulich wrote: >> On 12.11.18 at 17:16, wrote: Currently, a number of options passed for domain creation are ignored, or have implicit fallback behaviour. This is bad for forwards compatibility, and for end users to be certain that they got the configuration they asked for. With this change: * ARM now strictly requires that XEN_DOMCTL_CDF_hap is passed. Previously, only XEN_DOMCTL_CDF_hvm_guest was checked. * For x86, requesting HAP without HVM is now prohibited, as the combination makes no sense. * For x86, requesting HAP on a non-HAP capable system will fail, rather than silently fall back to Shadow. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Stefano Stabellini CC: Julien Grall CC: Ian Jackson CC: Wei Liu Semi RFC because this may cause a user-visible change in behaviour. However, if the user has gone to the effort of specifying hap=1, silently falling back to shadow is unexpected, and IMO, a bug. >>> My view on this to a fair part depends on whether the tool stack >>> would guard us from actually getting into such a situation in the >>> hypervisor. Getting an unspecific -EINVAL back without further >>> help towards diagnosis by the tool stack would make such a >>> change undesirable imo. >> If you want toolstack to tell you what goes wrong, this sanitisation >> function should be shared with the toolstack, and presumably with some >> if __XEN_TOOLS__ trickeries to return / print out the culprit. > > Some bits of logic could be shared like that, but some can't. > > As a different idea, could we hand back an up-to-128 byte string in the > failure case? There is space for that in the domctl.u because we've got > no other error information we need to propagate backwards. I like the idea in general; I'm not entirely sure if this will scale with future additions, as the caller might legitimately expect an explanatory string to come back in all cases. (Of course absence of an explanation could be signaled via an empty string.) Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129969: regressions - FAIL
flight 129969 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129969/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: 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 test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf bd224a5dad4d32f5224f5e8ae998b70e4621dcd3 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 52 attempts Testing same since 129963 2018-11-13 14:41:56 Z0 days2 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 842 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/5] xen/domain: Stricter configuration checking
>>> On 13.11.18 at 16:07, wrote:
> On 13/11/2018 14:14, Jan Beulich wrote:
> On 12.11.18 at 17:16, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -420,6 +420,46 @@ void arch_vcpu_destroy(struct vcpu *v)
>>>
>>> int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>>> {
>>> +bool hvm;
>>> +
>>> +if ( !IS_ENABLED(CONFIG_PV) && !(config->flags &
>>> XEN_DOMCTL_CDF_hvm_guest) )
>>> +{
>>> +dprintk(XENLOG_INFO, "PV support not available\n");
>>> +return -EINVAL;
>>> +}
>>> +
>>> +if ( !hvm_enabled && (config->flags & XEN_DOMCTL_CDF_hvm_guest) )
>>> +{
>>> +dprintk(XENLOG_INFO, "HVM support not available\n");
>>> +return -EINVAL;
>>> +}
>>> +
>>> +hvm = config->flags & XEN_DOMCTL_CDF_hvm_guest;
>> Would you mind making this the initializer of the variable and using
>> the variable in the two if()-s above? Personally I also think the two
>> if()-s would better be folded, using a conditional expression as its
>> condition.
>
> I can move the initialiser, but how do you propose folding the
> conditionals given their different contents?
if ( hvm ? !hvm_enabled : !IS_ENABLED(CONFIG_PV) )
{
dprintk(XENLOG_INFO, "%s support not available\n", hvm ? "HVM" : "PV");
return -EINVAL;
}
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 bisection] complete test-amd64-i386-xl-raw
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-raw
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.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/stable/linux-stable.git
Bug introduced: 7b8052e19304865477e03a0047062d977309a22f
Bug not present: d255d18a34a8d53ccc4a019dc07e17b6e8cf6bd1
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/129968/
commit 7b8052e19304865477e03a0047062d977309a22f
Author: Jan Beulich
Date: Mon Oct 19 04:23:29 2015 -0600
igb: fix NULL derefs due to skipped SR-IOV enabling
[ Upstream commit be06998f96ecb93938ad2cce46c4289bf7cf45bc ]
The combined effect of commits 6423fc3416 ("igb: do not re-init SR-IOV
during probe") and ceee3450b3 ("igb: make sure SR-IOV init uses the
right number of queues") causes VFs no longer getting set up, leading
to NULL pointer dereferences due to the adapter's ->vf_data being NULL
while ->vfs_allocated_count is non-zero. The first commit not only
neglected the side effect of igb_sriov_reinit() that the second commit
tried to account for, but also that of setting IGB_FLAG_HAS_MSIX,
without which igb_enable_sriov() is effectively a no-op. Calling
igb_{,re}set_interrupt_capability() as done here seems to address this,
but I'm not sure whether this is better than sinply reverting the other
two commits.
Signed-off-by: Jan Beulich
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Signed-off-by: Sasha Levin
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-i386-xl-raw.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.
Running cs-bisection-step
--graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-i386-xl-raw.xen-boot
--summary-out=tmp/129968.bisection-summary --basis-template=128858
--blessings=real,real-bisect linux-3.18 test-amd64-i386-xl-raw xen-boot
Searching for failure / basis pass:
129760 fail [host=debina0] / 128858 [host=baroque0] 128841 ok.
Failure / basis pass flights: 129760 / 128841
(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/stable/linux-stable.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 78e0897dd8b321ba1b4a2137778ab7ae7d400af5
c530a75c1e6a472b0eb9558310b518f0dfcd8860
d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
2cf113891a38cc05434bc9876ffc107a990887be
Basis pass 0d63979c1bc9c85578be4c589768a13dc0a7c5eb
c530a75c1e6a472b0eb9558310b518f0dfcd8860
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149
de5b678ca4dcdfa83e322491d478d66df56c1986
92666fdd6e0afab989b2d89759d9b43f2c645ae7
Generating revisions with ./adhoc-revtuple-generator
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#0d63979c1bc9c85578be4c589768a13dc0a7c5eb-78e0897dd8b321ba1b4a2137778ab7ae7d400af5
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
git://xenbits.xen.org/qemu-xen-traditional.git#9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149-d0d8ad39ecb51cd7497cd524484fe09f50876798
git://xenbits.xen.org/qemu-xen.git#de5b678ca4dcdfa83e322491d478d66df56c1986-de5b678ca4dcdfa83e322491d478d66df56c1986
git://xenbits.xen.org/xen.git#92666fdd6e0afab989b2d89759d9b43f2c645ae7-2cf113891a38cc05434bc9876ffc107a990887be
From git://cache:9419/git://xenbits.xen.org/xen
94bd9df0f7..1bd2b75053 smoke -> origin/smoke
Loaded 3004 nodes in revision graph
Searching for test results:
128691 [host=albana1]
128807 [host=fiano0]
128858 [host=baroque0]
128841 pass 0d63979c1bc9c85578be4c589768a13dc0a7c5eb
c530a75c1e6a472b0eb9558310b518f0dfcd8860
9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149
de5b678ca4dcdfa83e322491d478d66df56c1986
92666fdd6e0afab989b2d89759d9b43f2c645ae7
129760 fail 78e0897dd8b321ba1b4a2137778ab7ae7d400af5
c530a75c1e6a472b0eb9558310b518f0dfcd8860
d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
2cf113891a38cc05434bc9876ffc107a990887be
129945 fail e57bb9912c92b17cc4926a6e00c9505fb38b65d0
c530a75c1e6a472b0eb9558310b518f0dfcd8860
d0d8ad39ecb51cd7497cd524484fe09f50876798
de5b678ca4dcdfa83e322491d478d66df56c1986
2cf113891a38cc05434bc9876ffc107a990887be
129925 fail
[Xen-devel] [xen-unstable-smoke test] 129960: tolerable all pass - PUSHED
flight 129960 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/129960/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 1bd2b750537b656f3fa90857707be91f5ed8bfd8 baseline version: xen 94bd9df0f7efad8038d99ec52ba56ecec4191248 Last test of basis 129852 2018-11-12 16:00:37 Z1 days Failing since129861 2018-11-12 19:00:52 Z0 days9 attempts Testing same since 129960 2018-11-13 14:05:09 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Jan Beulich Roger Pau Monné 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 94bd9df0f7..1bd2b75053 1bd2b750537b656f3fa90857707be91f5ed8bfd8 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6.1 05/11] libxl_qmp: Implementation of libxl__ev_qmp_*
Anthony PERARD writes ("Re: [PATCH v6.1 05/11] libxl_qmp: Implementation of
libxl__ev_qmp_*"):
> On Tue, Nov 13, 2018 at 01:14:30PM +, Ian Jackson wrote:
> > This one is probably an asisstant for transitioning between states so
> > the pre- and post-conditions may not be pure. Whatever it is should
> > be documented...
>
> It's hard to document the state transition of a function that doesn't
> care of the current state when the function is called, and will attempt
> to figure out the current state to find out if a function `writable`
> needs to be called later.
Then write that down rather than just saying nothing!
I think it might be useful to paste in again a thing I wrote on the
15th of October:
Again, I asked for more internal documentation about the legal states
etc. I will have to read it in detail again I'm afraid after that is
done.
The reason I ask for this is that this is a complicated and
substantial pile of code. It's not sensible for anyone to try to hold
it in their head at once - we will make mistakes. And it should be
possbile to modify it without reading all of it.
So, it should be possible for anyone to:
* Look only at the summary internal architecture state machine
comments and so on, and confirm to themselves that this is a
sensible design and that all the possible states are represented
and that the interlocking states of the detailed variables are
both sufficient, and of manageable complexity.
* Read any small fragment of code and see that transforms legal
states into other legal states, by reference to the above.
Right now this is not really possible. I look at things like this:
I want someone who reads one of these functions to be able to see that
it is correct, without having to go and look at its call sites to
understand what it needs to promise. And of course from my own point
of view, I won't want to reverse engineer the intention from the code.
It's OK if it is obvious but in this case I think it is usually
un-obvious.
These kind of explicitly coded state machines are indeed tiresome,
compared to synchronous code where the state is encoded in the program
counter (ie, the progress through the single function). It more easy
to make mistakes where a variable is not set or has the wrong value,
because (compared to a synchronous function) the sequencing is
obscured.
Unfortunately we do not have a workable coroutines system, and
multithreading is even worse for writing bugs. (Nontrivial
multithreaded programs are almost always full of race bugs.) So we
are left with doing it this way, and we have to mitigate the risk of
bugs a different way: in this case, by writing down more explicitly in
comments things that could be easily inferred from reading the code if
the code were a single function.
One way to test to see if you have succeeded is as follows: can you
prove that each function is correct, in isolation, without having to
read the body of any other function ? You are only allowed to rely on
the struct definition, and the formal state definitions, and the doc
comments for your function and everything you call.
That is obviously not possible if there is nothing saying what state
the function is supposed to leave things in. Nor is it possible to
show that the function is correct unless either it tolerates any (even
impure) input state, or there is a comment saying what input states
it is supposed to deal with.
> Are all those comments good enough? Also sometime the internal state
> isn't fully changed in one go, and the transition could happen in
> several functions (I think). Do we needs states like disconnecting,
> connectinging, ... ? with a comment that say that the value of the
> internal variables can be one of before or after the state transition.
This is what I meant by `impure' states below. I don't think you want
to write them in your state table, but you can describe them in
comments as `connected, but with rx_fd not Active' or some such.
`But' and `but maybe' are good phrasings for this.
> But now I realise that `disconnected` would be an illigal state.
>
> What about:
>
> Precondition: !disconnected
> ensure that qmp_ev_callback_writable is been called when needed
That sounds good, but I think you probably want something more like:
On entry: connected/..., but with [the ev_fd] maybe Idle
On return: the same state, but with [the ev_fd] Active iff needed
? Or whatever else is true.
> > > +static int qmp_ev_prepare_cmd(libxl__gc *gc,
> > > + libxl__ev_qmp *ev,
> > > + const char *cmd,
> > > + const libxl__json_object *args)
> > > +{
> > > +char *buf = NULL;
> >
> > Missing state comment.
>
> Maybe:
>
> Precondition: connecting/connected
Does it change the state to a new one ? Are the old and new states
pure states as described in the state table, or are they
Re: [Xen-devel] [Qemu-devel] [PATCH v5 10/24] hw: acpi: Export the PCI host and holes getters
On Mon, 5 Nov 2018 02:40:33 +0100
Samuel Ortiz wrote:
> This is going to be needed by the hardware reduced implementation, so
> let's export it.
> Once the ACPI builder methods and getters will be implemented, the
> acpi_get_pci_host() implementation will become hardware agnostic.
>
> Signed-off-by: Samuel Ortiz
> ---
> include/hw/acpi/aml-build.h | 2 ++
> hw/acpi/aml-build.c | 43 +
> hw/i386/acpi-build.c| 47 ++---
> 3 files changed, 47 insertions(+), 45 deletions(-)
>
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index c27c0935ae..fde2785b9a 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -400,6 +400,8 @@ build_header(BIOSLinker *linker, GArray *table_data,
> const char *oem_id, const char *oem_table_id);
> void *acpi_data_push(GArray *table_data, unsigned size);
> unsigned acpi_data_len(GArray *table);
> +Object *acpi_get_pci_host(void);
> +void acpi_get_pci_holes(Range *hole, Range *hole64);
> /* Align AML blob size to a multiple of 'align' */
> void acpi_align_size(GArray *blob, unsigned align);
> void acpi_add_table(GArray *table_offsets, GArray *table_data);
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index 2b9a636e75..b8e32f15f7 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -1601,6 +1601,49 @@ void acpi_build_tables_cleanup(AcpiBuildTables
> *tables, bool mfre)
> g_array_free(tables->vmgenid, mfre);
> }
> +/*
> + * Because of the PXB hosts we cannot simply query TYPE_PCI_HOST_BRIDGE.
> + */
> +Object *acpi_get_pci_host(void)
> +{
> +PCIHostState *host;
> +
> +host = OBJECT_CHECK(PCIHostState,
> +object_resolve_path("/machine/i440fx", NULL),
> +TYPE_PCI_HOST_BRIDGE);
> +if (!host) {
> +host = OBJECT_CHECK(PCIHostState,
> +object_resolve_path("/machine/q35", NULL),
> +TYPE_PCI_HOST_BRIDGE);
> +}
> +
> +return OBJECT(host);
> +}
in general aml-build.c is a place to put ACPI spec primitives,
so I'd suggest to move it somewhere else.
Considering it's x86 code (so far), maybe move it to something like
hw/i386/acpi-pci.c
Also it might be good to get rid of acpi_get_pci_host() and pass
a pointer to pci_host as acpi_setup() an argument, since it's static
for life of boar we can keep it in AcpiBuildState, and reuse for
mfg/pci_hole/pci bus accesses.
That way we can simplify code a bit and avoid lookup cost of
object_resolve_path() that's called several times unnecessarily.
> +void acpi_get_pci_holes(Range *hole, Range *hole64)
> +{
> +Object *pci_host;
> +
> +pci_host = acpi_get_pci_host();
> +g_assert(pci_host);
> +
> +range_set_bounds1(hole,
> + object_property_get_uint(pci_host,
> + PCI_HOST_PROP_PCI_HOLE_START,
> + NULL),
> + object_property_get_uint(pci_host,
> + PCI_HOST_PROP_PCI_HOLE_END,
> + NULL));
> +range_set_bounds1(hole64,
> + object_property_get_uint(pci_host,
> +
> PCI_HOST_PROP_PCI_HOLE64_START,
> + NULL),
> + object_property_get_uint(pci_host,
> + PCI_HOST_PROP_PCI_HOLE64_END,
> + NULL));
> +}
> +
> static void crs_range_insert(GPtrArray *ranges, uint64_t base, uint64_t
> limit)
> {
> CrsRangeEntry *entry;
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index bd147a6bd2..a5f5f83500 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -232,49 +232,6 @@ static void acpi_get_misc_info(AcpiMiscInfo *info)
> info->applesmc_io_base = applesmc_port();
> }
>
> -/*
> - * Because of the PXB hosts we cannot simply query TYPE_PCI_HOST_BRIDGE.
> - * On i386 arch we only have two pci hosts, so we can look only for them.
> - */
> -static Object *acpi_get_i386_pci_host(void)
> -{
> -PCIHostState *host;
> -
> -host = OBJECT_CHECK(PCIHostState,
> -object_resolve_path("/machine/i440fx", NULL),
> -TYPE_PCI_HOST_BRIDGE);
> -if (!host) {
> -host = OBJECT_CHECK(PCIHostState,
> -object_resolve_path("/machine/q35", NULL),
> -TYPE_PCI_HOST_BRIDGE);
> -}
> -
> -return OBJECT(host);
> -}
> -
> -static void acpi_get_pci_holes(Range *hole, Range *hole64)
> -{
> -Object *pci_host;
> -
> -pci_host = acpi_get_i386_pci_host();
> -g_assert(pci_host);
> -
> -range_set_bounds1(hole,
> -
Re: [Xen-devel] [PATCH v4 07/44] x86emul: also allow running the 32-bit harness on a 64-bit distro
On 13/11/2018 11:42, Jan Beulich wrote: On 12.11.18 at 18:50, wrote: >> On 25/09/18 14:29, Jan Beulich wrote: >>> In order to be able to verify the 32-bit variant builds and runs, >>> introduce a respective target (and the necessary other adjustments). >>> >>> Signed-off-by: Jan Beulich >> I tried this, but got: >> >> make: Entering directory '/local/xen.git/tools/tests/x86_emulator/32' >> gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer >> -fno-strict-aliasing -Wdeclaration-after-statement -m32 >> -I/local/xen.git/tools/tests/x86_emulator/32/../../../../tools/include -I. >> -D__XEN_TOOLS__ -c -g -o x86-emulate.o ../x86-emulate.c >> gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer >> -fno-strict-aliasing -Wdeclaration-after-statement -m32 >> -I/local/xen.git/tools/tests/x86_emulator/32/../../../../tools/include -I. >> -o test_x86_emulator x86-emulate.o ../test_x86_emulator.o ../evex-disp8.o >> ../wrappers.o >> /usr/bin/ld: i386:x86-64 architecture of input file `../test_x86_emulator.o' >> is incompatible with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../evex-disp8.o' is >> incompatible with i386 output >> /usr/bin/ld: i386:x86-64 architecture of input file `../wrappers.o' is >> incompatible with i386 output >> collect2: error: ld returned 1 exit status >> ../Makefile:153: recipe for target 'test_x86_emulator' failed > Hmm, nothing I can reproduce. I don't understand why it tries to use > ../*.o instead of building 32-bit variants in the current directory. > Perhaps a make version difference in how VPATH gets handled? But > I know I've tried with different versions, which will make it rather > hard for me to diagnose the issue. Could you see whether replacing > > VPATH += .. > > by > > vpath %.c .. > > helps in your case? Sadly not. That turns into: make: Entering directory '/local/xen.git/tools/tests/x86_emulator/32' make: *** No rule to make target 'x86-emulate.h', needed by 'x86-emulate.o'. Stop. make: Leaving directory '/local/xen.git/tools/tests/x86_emulator/32' I've noticed another issue. The clean target now rebuilds all the binary fragements before deleting them again. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 06/44] x86emul: test for correct EVEX Disp8 scaling
On 13/11/2018 11:12, Jan Beulich wrote:
On 12.11.18 at 18:42, wrote:
>> On 25/09/18 14:29, Jan Beulich wrote:
>>> Besides the already existing tests (which are going to be extended once
>>> respective ISA extension support is complete), let's also ensure for
>>> every individual insn that their Disp8 scaling (and memory access width)
>>> are correct.
>>>
>>> Signed-off-by: Jan Beulich
>> I can see what you're attempting to do, but you now have two
>> implementations of the EVEX disp8 logic written by yourself. AFAICT,
>> this doesn't actually check that the behaviour of the instruction in
>> hardware matches your model of the instruction - it checks that two of
>> your models are the same.
> Correct, but I've specifically tried to make the two models sufficiently
> different.
>
>> The only way I can think of testing the emulator model against hardware
>> is to start with two memory area poisoned with a non-repeating pattern,
>> and a src/dst register poisoned with a different non-repeating pattern.
>> Then, execute a real instruction stub, emulate the other and memcmp()
>> the two memory regions.
> That's what some of the tests added right in patch 5 do. Did you
> intentionally skip that patch while reviewing?
I intentionally wanted to understand this patch first.
>
>> That way, a systematic error in the two models won't cancel out to "all ok".
> Hence the two different models. I certainly realize the risk you
> name.
>
>>> --- /dev/null
>>> +++ b/tools/tests/x86_emulator/evex-disp8.c
>>> @@ -0,0 +1,452 @@
>>> +#include
>>> +#include
>>> +
>>> +#include "x86-emulate.h"
>> This now needs rearranging to avoid:
>>
>> x86-emulate.h:30:3: error: #error "Must not include before
>> x86-emulate.h"
>> # error "Must not include before x86-emulate.h"
> Yes, I've already re-based over that other change.
>
>>> +enum vl {
>>> +VL_128,
>>> +VL_256,
>>> +VL_512,
>>> +};
>>> +
>>> +enum scale {
>>> +SC_vl,
>>> +SC_el,
>>> +};
>>> +
>>> +enum vsz {
>>> +VSZ_vl,
>>> +VSZ_vl_2, /* VL / 2 */
>>> +VSZ_vl_4, /* VL / 4 */
>>> +VSZ_vl_8, /* VL / 8 */
>>> +/* "no broadcast" implied from here on. */
>>> +VSZ_el,
>>> +VSZ_el_2, /* EL * 2 */
>>> +VSZ_el_4, /* EL * 4 */
>>> +VSZ_el_8, /* EL * 8 */
>>> +};
>>> +
>> These acronyms get increasingly difficult to follow. What is el in this
>> context?
> VL -> vector length
> EL -> element length
Can you at least leave trailing comments after the identifiers for the
benefit of people other than you reading the code?
>
>>> +static const struct test avx512f_all[] = {
>>> +INSN_SFP(mov,0f, 10),
>>> +INSN_SFP(mov,0f, 11),
>>> +INSN_PFP_NB(mova,0f, 28),
>>> +INSN_PFP_NB(mova,0f, 29),
>>> +INSN(movdqa32, 66, 0f, 6f,vl, d_nb, vl),
>>> +INSN(movdqa32, 66, 0f, 7f,vl, d_nb, vl),
>>> +INSN(movdqa64, 66, 0f, 6f,vl, q_nb, vl),
>>> +INSN(movdqa64, 66, 0f, 7f,vl, q_nb, vl),
>>> +INSN(movdqu32, f3, 0f, 6f,vl, d_nb, vl),
>>> +INSN(movdqu32, f3, 0f, 7f,vl, d_nb, vl),
>>> +INSN(movdqu64, f3, 0f, 6f,vl, q_nb, vl),
>>> +INSN(movdqu64, f3, 0f, 7f,vl, q_nb, vl),
>>> +INSN(movntdq, 66, 0f, e7,vl, d_nb, vl),
>>> +INSN(movntdqa, 66, 0f38, 2a,vl, d_nb, vl),
>>> +INSN_PFP_NB(movnt, 0f, 2b),
>>> +INSN_PFP_NB(movu,0f, 10),
>>> +INSN_PFP_NB(movu,0f, 11),
>>> +};
>>> +
>>> +static const struct test avx512f_128[] = {
>>> +INSN(mov, 66, 0f, 6e, el, dq64, el),
>>> +INSN(mov, 66, 0f, 7e, el, dq64, el),
>>> +INSN(movq, f3, 0f, 7e, el,q, el),
>>> +INSN(movq, 66, 0f, d6, el,q, el),
>>> +};
>>> +
>>> +static const struct test avx512bw_all[] = {
>>> +INSN(movdqu8, f2, 0f, 6f,vl,b, vl),
>>> +INSN(movdqu8, f2, 0f, 7f,vl,b, vl),
>>> +INSN(movdqu16,f2, 0f, 6f,vl,w, vl),
>>> +INSN(movdqu16,f2, 0f, 7f,vl,w, vl),
>>> +};
>>> +
>>> +static const unsigned char vl_all[] = { VL_512, VL_128, VL_256 };
>>> +static const unsigned char vl_128[] = { VL_128 };
>> What are these for, and why is vl_all[]'s VL_128 out of order?
> The RUN() macro invocations (further down) reference one them
> each, to indicate what vector lengths to test. The first array
> entry does always get used, while subsequent entries (if any)
> require AVX512VL to be available. See the conditional at the top
> of the inner loop in test_group().
After re-reading the apparently relevant bits of Vol 1, 2 and 3, I'm
still actually none the wiser as to which AVX512 feature bits mean what.
Is there a chapter with an overview that I've overlooked, or if not, can
we see about putting one together?
>
>>> +
>>> +/*
>>> + * This table, indicating the presence of an immediate (byte) for an opcode
>>> + * space 0f major opcode, is indexed by
Re: [Xen-devel] [PATCH v6.1 05/11] libxl_qmp: Implementation of libxl__ev_qmp_*
On Tue, Nov 13, 2018 at 01:14:30PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v6.1 05/11] libxl_qmp: Implementation of
> libxl__ev_qmp_*"):
> ...
>
> I think this was intended to satisfy my request for comments about
> legal states:
>
> > +/* helpers */
> > +
> > +static void qmp_ev_ensure_reading_writing(libxl__gc *gc, libxl__ev_qmp *ev)
> > +{
> > +bool enable = false;
>
> This one is probably an asisstant for transitioning between states so
> the pre- and post-conditions may not be pure. Whatever it is should
> be documented...
It's hard to document the state transition of a function that doesn't
care of the current state when the function is called, and will attempt
to figure out the current state to find out if a function `writable`
needs to be called later.
But now I realise that `disconnected` would be an illigal state.
What about:
Precondition: !disconnected
ensure that qmp_ev_callback_writable is been called when needed
> > +static void qmp_ev_set_state(libxl__gc *gc, libxl__ev_qmp *ev,
> > + libxl__qmp_state new_state)
> > +{
>
> This one at least does not need a comment :-).
>
> > +static int qmp_ev_prepare_cmd(libxl__gc *gc,
> > + libxl__ev_qmp *ev,
> > + const char *cmd,
> > + const libxl__json_object *args)
> > +{
> > +char *buf = NULL;
>
> Missing state comment.
Maybe:
Precondition: connecting/connected
> > +static void qmp_ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev_fd,
> > + int fd, short events, short revents)
> > +{
>
> Missing state comment, although I think the precondition can be easily
> inferred from the state of ev_fd and the postcondition varies, but
> would still be nice to discuss it.
This function is the main loop function, so almost everything happen in
this function. It should not be called directly. So I'm not sure what
kind of comment would be usefull here.
Maybe:
Preconditions:
`ev_fd` is Active
this means that `ev` isn't disconnected
Any allowed internal state transition can happen.
A user callback may be called, when that happen, the function should
return.
> > +static int qmp_ev_callback_writable(libxl__gc *gc,
> > +libxl__ev_qmp *ev, int fd)
> > +/* connected -> waiting_reply
> > + * the state isn't change otherwise. */
> > +{
>
> I don't know what `otherwise' means. Maybe you mean all other states
> are legal and remain unchanged ? But that does not seem to be
> likely. Presumably disconnected is ruled out, at least.
If for some random reason this function is called with the state
disconnected, it would just return. Unless the state is disconnecting
and tx_buf haven't been cleared yet.
`Otherwise` would be the `otherwise` of haskell, or the `default` of a
switch case in C.
So a different comment could be:
Precondition:
!disconnected
State transition
connected -> waiting_reply
* -> state unchange
on error: disconnected
The state of the transmiting buffer will be changed.
> > +static int qmp_ev_callback_readable(libxl__egc *egc,
> > +libxl__ev_qmp *ev, int fd)
> > +/* on error: * -> disconnected */
>
> Precondition ? And on non-error ?
Here is a more complete comment:
Precondition:
!disconnected
State transition:
Only the state of the receiving buffer is change on success
on error: disconnected
> > +static int qmp_ev_get_next_msg(libxl__egc *egc, libxl__ev_qmp *ev,
> > + libxl__json_object **o_r)
> > +/* Find a JSON object and store it in o_r.
> > + * return ERROR_NOTFOUND if no object is found.
> > + * `o_r` is allocated within `egc`.
> > + */
> > +{
>
> Missing state comment.
precondition: !disconnected
state of the receiving buffer can be changed.
> > +static int qmp_ev_parse_error_messages(libxl__egc *egc,
> > + libxl__ev_qmp *ev,
> > + const libxl__json_object *resp)
> > +{
>
> This doesn't touch the state I think. Should perhaps be mentioned in
> a comment.
The only thing that this function use is set by a user (of
libxl__ev_qmp): ev->domid. But I guess that comment would do:
no state change
Are all those comments good enough? Also sometime the internal state
isn't fully changed in one go, and the transition could happen in
several functions (I think). Do we needs states like disconnecting,
connectinging, ... ? with a comment that say that the value of the
internal variables can be one of before or after the state transition.
Next time I'll write one BIG function, and there will be less of those
comments to write :).
Thanks,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
[Xen-devel] [ovmf test] 129963: regressions - FAIL
flight 129963 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129963/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129475 build-amd64 6 xen-buildfail REGR. vs. 129475 build-i386-xsm6 xen-buildfail REGR. vs. 129475 build-i3866 xen-buildfail REGR. vs. 129475 Tests which did not succeed, but are not blocking: build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf bd224a5dad4d32f5224f5e8ae998b70e4621dcd3 baseline version: ovmf 5ae3184d8c59f7bbb84bad482df6b8020ba58188 Last test of basis 129475 2018-11-05 21:13:11 Z7 days Failing since129526 2018-11-06 20:49:26 Z6 days 51 attempts Testing same since 129963 2018-11-13 14:41:56 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Dandan Bi Eric Dong Fu Siyuan Hao Wu Jian J Wang Jiaxin Wu Jiewen Yao Laszlo Ersek Liming Gao Marc Zyngier Ming Huang Ruiyu Ni Star Zeng Wu Jiaxin yuchenlin jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 842 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
