Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers
>>> On 18.03.19 at 18:06, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 18 March 2019 16:56
>> To: Paul Durrant
>> Cc: Julien Grall ; Andrew Cooper
>; George Dunlap
>> ; Ian Jackson ; Roger Pau
> Monne
>> ; Wei Liu ; Stefano Stabellini
> ;
>> xen-devel ; Konrad Rzeszutek Wilk
> ; Tim
>> (Xen.org)
>> Subject: Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of
> synthetic timers
>>
>> >>> On 18.03.19 at 17:26, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 18 March 2019 16:23
>> >>
>> >> >>> On 18.03.19 at 16:46, wrote:
>> >> >> > > +{
>> >> >> > > +expiration = vs->count;
>> >> >> > > +if ( expiration - now <= 0 )
>> >> >> > > +{
>> >> >> > > +vs->expiration = expiration;
>> >> >> > > +stimer_expire(vs);
>> >> >> >
>> >> >> > Aren't you introducing a risk for races by calling the timer function
>> >> >> > directly from here? start_timer(), after all, gets called from quite
>> >> >> > a
>> >> >> > few places.
>> >> >>
>> >> >> In practice I don't think there should be any problematic race, but
>> >> >> I'll
> check again.
>> >> >
>> >> > I think the 'periodic' name might be confusing things... The Xen timers
> are
>> >> > all single-shot, it's just that start_stimer() is re-called after a
>> >> > successful poll if the viridian timer is configured to be periodic. So I
>> >> > don't think there is case where the underlying Xen timer could actually
>> >> > be
>> >> > running when we enter start_stimer().
>> >>
>> >> One of the callers of the function is the WRMSR handler. Why would
>> >> it be guaranteed that the timer isn't active when such a WRMSR
>> >> occurs?
>> >
>> > It's not guaranteed on entry, but the WRMSR handler always calls
>> > stop_stimer() before calling start_stimer() which AFAICT should guarantee
> the
>> > timer is not running when start_stimer() is called.
>>
>> I've looked only briefly, but the stop_timer() -> deactivate_timer() call
>> chain doesn't look to wait for the timer handler to not be active anymore
>> on another CPU before returning.
>
> Oh, it looked to me like the locking would ensure the timer was deactivated
> and would not run... but I guess I may have misunderstood the code.
The lock gets dropped around the call to the handler (in execute_timer()).
> Still
> even if both occurrences make it past the test of config.enabled all they'll
> do is both set the pending bit, as the prior version of the patch did.
> Although I guess there's now a possibility that, for one occurrence, the poll
> could occur before config.enabled is cleared and thus the timer may be
> rescheduled and immediately expire again.
So perhaps config.enabled should get cleared before setting the bit
in stimer_pending? Would seem to also be better for this to happen
before vcpu_kick(), wouldn't it? (Moving the two lines up would again
be easy enough to do while committing, so long as you agree.)
> I'm not sure whether this is really a problem or not.
Neither am I.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 133891: regressions - FAIL
flight 133891 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133891/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine 8 reboot fail REGR. vs. 128858 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 128858 test-amd64-i386-xl7 xen-boot fail REGR. vs. 128858 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 128858 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 128858 test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 128858 test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 128858 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 128858 test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 128858 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 10 debian-install fail in 133539 pass in 133891 test-armhf-armhf-xl 7 xen-boot fail in 133856 pass in 133891 test-amd64-i386-libvirt 7 xen-boot fail pass in 133539 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail pass in 133819 test-armhf-armhf-xl-rtds 5 host-ping-check-native fail pass in 133856 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 128858 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-libvirt 13 migrate-support-check fail in 133539 never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 133819 never pass test-armhf-armhf-xl-rtds13 migrate-support-check fail in 133819 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 133819 never pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 133856 like 128858 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail like 128807 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128858 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128858 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128858 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 128858 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128858 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128858 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail neve
Re: [Xen-devel] [PATCH v1 1/4] xen: add hypercall for getting parameters at runtime
>>> On 19.03.19 at 07:07, wrote: > Why don't we replace the "*get_func()" with a "char *current_val" being > filled at parameter setting time? How current_val is allocated (static > string or dynamic buffer) just has to be known by the custom parameter > parsing function. Could accumulate (over time) to quite a bit of wasted allocations if no-one ever cares about calling the new sysctl. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 1/4] xen: add hypercall for getting parameters at runtime
On 19/03/2019 09:04, Jan Beulich wrote: On 19.03.19 at 07:07, wrote: >> Why don't we replace the "*get_func()" with a "char *current_val" being >> filled at parameter setting time? How current_val is allocated (static >> string or dynamic buffer) just has to be known by the custom parameter >> parsing function. > > Could accumulate (over time) to quite a bit of wasted allocations if > no-one ever cares about calling the new sysctl. In the normal case the needed memory shouldn't be more than that of the boot parameters, maybe plus some bytes in case runtime parameters are set. So I believe we are talking about less than one memory page. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 March 2019 08:03
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Wei Liu ; Stefano Stabellini
> ;
> xen-devel ; Konrad Rzeszutek Wilk
> ; Tim
> (Xen.org)
> Subject: Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of
> synthetic timers
>
> >>> On 18.03.19 at 18:06, wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 18 March 2019 16:56
> >> To: Paul Durrant
> >> Cc: Julien Grall ; Andrew Cooper
> >; George Dunlap
> >> ; Ian Jackson ; Roger Pau
> > Monne
> >> ; Wei Liu ; Stefano Stabellini
> > ;
> >> xen-devel ; Konrad Rzeszutek Wilk
> > ; Tim
> >> (Xen.org)
> >> Subject: Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of
> > synthetic timers
> >>
> >> >>> On 18.03.19 at 17:26, wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: 18 March 2019 16:23
> >> >>
> >> >> >>> On 18.03.19 at 16:46, wrote:
> >> >> >> > > +{
> >> >> >> > > +expiration = vs->count;
> >> >> >> > > +if ( expiration - now <= 0 )
> >> >> >> > > +{
> >> >> >> > > +vs->expiration = expiration;
> >> >> >> > > +stimer_expire(vs);
> >> >> >> >
> >> >> >> > Aren't you introducing a risk for races by calling the timer
> >> >> >> > function
> >> >> >> > directly from here? start_timer(), after all, gets called from
> >> >> >> > quite a
> >> >> >> > few places.
> >> >> >>
> >> >> >> In practice I don't think there should be any problematic race, but
> >> >> >> I'll
> > check again.
> >> >> >
> >> >> > I think the 'periodic' name might be confusing things... The Xen
> >> >> > timers
> > are
> >> >> > all single-shot, it's just that start_stimer() is re-called after a
> >> >> > successful poll if the viridian timer is configured to be periodic.
> >> >> > So I
> >> >> > don't think there is case where the underlying Xen timer could
> >> >> > actually be
> >> >> > running when we enter start_stimer().
> >> >>
> >> >> One of the callers of the function is the WRMSR handler. Why would
> >> >> it be guaranteed that the timer isn't active when such a WRMSR
> >> >> occurs?
> >> >
> >> > It's not guaranteed on entry, but the WRMSR handler always calls
> >> > stop_stimer() before calling start_stimer() which AFAICT should guarantee
> > the
> >> > timer is not running when start_stimer() is called.
> >>
> >> I've looked only briefly, but the stop_timer() -> deactivate_timer() call
> >> chain doesn't look to wait for the timer handler to not be active anymore
> >> on another CPU before returning.
> >
> > Oh, it looked to me like the locking would ensure the timer was deactivated
> > and would not run... but I guess I may have misunderstood the code.
>
> The lock gets dropped around the call to the handler (in execute_timer()).
>
> > Still
> > even if both occurrences make it past the test of config.enabled all they'll
> > do is both set the pending bit, as the prior version of the patch did.
> > Although I guess there's now a possibility that, for one occurrence, the
> > poll
> > could occur before config.enabled is cleared and thus the timer may be
> > rescheduled and immediately expire again.
>
> So perhaps config.enabled should get cleared before setting the bit
> in stimer_pending? Would seem to also be better for this to happen
> before vcpu_kick(), wouldn't it? (Moving the two lines up would again
> be easy enough to do while committing, so long as you agree.)
>
> > I'm not sure whether this is really a problem or not.
>
> Neither am I.
Ok. To err on the safe side it is probably best to only access the timer config
from current context and have timer expiration simply set the pending bit and
kick the vcpu. I'll send a v9.
Paul
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 1/4] xen: add hypercall for getting parameters at runtime
>>> On 19.03.19 at 09:12, wrote: > On 19/03/2019 09:04, Jan Beulich wrote: > On 19.03.19 at 07:07, wrote: >>> Why don't we replace the "*get_func()" with a "char *current_val" being >>> filled at parameter setting time? How current_val is allocated (static >>> string or dynamic buffer) just has to be known by the custom parameter >>> parsing function. >> >> Could accumulate (over time) to quite a bit of wasted allocations if >> no-one ever cares about calling the new sysctl. > > In the normal case the needed memory shouldn't be more than that of the > boot parameters, maybe plus some bytes in case runtime parameters are > set. So I believe we are talking about less than one memory page. Total space needed may (for now) indeed not be very much, but setting this up would still be useless if the sysctl was never invoked, and prone to be forgotten to update when other parts of that command line option's handling get updated. I think there's less risk of returning stale data if the string gets re- constructed on demand. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-4.9-testing test] 133881: regressions - FAIL
>>> On 19.03.19 at 01:39, wrote: > flight 133881 xen-4.9-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/133881/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. > vs. 132889 > test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. > vs. 132889 I've looked into these (and also the corresponding 4.8 one) before, without being able to spot anything that would provide some sort of hint to me as to what's actually going wrong. All I notice is error: Timed out during operation: cannot acquire state change lock But I have a hard time seeing how this can be a result of the changes under test (I assume the state change lock is a tools thing, and there are no pending tools changes). Yet judging from ... > Last test of basis 132889 2019-02-04 22:04:09 Z 42 days > Failing since133147 2019-02-11 13:41:50 Z 35 days 24 attempts > Testing same since 133603 2019-03-05 18:49:35 Z 13 days9 attempts ... this there's probably no hope anymore for this to go away all by itself. Could someone else please also look into these? I wonder if the failures are connected to the tests now running (stickily) on the merlots. The above time line also suggests that the problem started to appear with the version update, which can't possibly have caused a regression on its own. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/AMD: correct certain Fam17 checks
Commit 3157bb4e13 ("Add MSR support for various feature AMD processor
families") converted certain checks for Fam11 to include families all
the way up to Fam17. The commit having no description, it is hard to
tell whether this was a mechanical dec->hex conversion mistake, or
indeed intended. In any event the NB_CFG handling needs to be restricted
to Fam16 and below: Fam17 doesn't have such an MSR anymore.
A non-MMCFG extended config space access mechanism still appears to
exist, but code to deal with it will need to be written down the road,
when it can actually be tested.
Reported-by: Pu Wen
Signed-off-by: Jan Beulich
---
I'm also not sure whether e.g. init_amd()'s C1E disabling is still
applicable to Fam17.
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1288,7 +1288,7 @@ struct hvm_ioreq_server *hvm_select_iore
d->arch.cpuid->x86_vendor == X86_VENDOR_AMD &&
(x86_fam = get_cpu_family(
d->arch.cpuid->basic.raw_fms, NULL, NULL)) > 0x10 &&
- x86_fam <= 0x17 )
+ x86_fam < 0x17 )
{
uint64_t msr_val;
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -195,7 +195,7 @@ static bool pci_cfg_ok(struct domain *cu
/* AMD extended configuration space access? */
if ( CF8_ADDR_HI(currd->arch.pci_cf8) &&
boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
- boot_cpu_data.x86 >= 0x10 && boot_cpu_data.x86 <= 0x17 )
+ boot_cpu_data.x86 >= 0x10 && boot_cpu_data.x86 < 0x17 )
{
uint64_t msr_val;
@@ -1015,7 +1015,7 @@ static int write_msr(unsigned int reg, u
case MSR_AMD64_NB_CFG:
if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
- boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
+ boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 >= 0x17 )
break;
if ( !is_hardware_domain(currd) || !is_pinned_vcpu(curr) )
return X86EMUL_OKAY;
@@ -1028,7 +1028,7 @@ static int write_msr(unsigned int reg, u
case MSR_FAM10H_MMIO_CONF_BASE:
if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
- boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
+ boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 >= 0x17 )
break;
if ( !is_hardware_domain(currd) || !is_pinned_vcpu(curr) )
return X86EMUL_OKAY;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2 02/10] block: avoid to break XEN by multi-page bvec
On 17/03/2019 11:01, Ming Lei wrote: > XEN has special page merge requirement, see xen_biovec_phys_mergeable(). > We can't merge pages into one bvec simply for XEN. > > So move XEN's specific check on page merge into __bio_try_merge_page(), > then abvoid to break XEN by multi-page bvec. > > Cc: ris Ostrovsky > Cc: Juergen Gross > Cc: xen-devel@lists.xenproject.org > Cc: Omar Sandoval > Cc: Christoph Hellwig > Signed-off-by: Ming Lei Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v9 02/11] viridian: separately allocate domain and vcpu structures
Currently the viridian_domain and viridian_vcpu structures are inline in
the hvm_domain and hvm_vcpu structures respectively. Subsequent patches
will need to add sizable extra fields to the viridian structures which
will cause the PAGE_SIZE limit of the overall vcpu structure to be
exceeded. This patch, therefore, uses the new init hooks to separately
allocate the structures and converts the 'viridian' fields in hvm_domain
and hvm_cpu to be pointers to these allocations. These separate allocations
also allow some vcpu and domain pointers to become const.
Ideally, now that they are no longer inline, the allocations of the
viridian structures could be made conditional on whether the toolstack
is going to configure the viridian enlightenments. However the toolstack
is currently unable to convey this information to the domain creation code
so such an enhancement is deferred until that becomes possible.
NOTE: The patch also introduced the 'is_viridian_vcpu' macro to avoid
introducing a second evaluation of 'is_viridian_domain' with an
open-coded 'v->domain' argument. This macro will also be further
used in a subsequent patch.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v4:
- Const-ify some vcpu and domain pointers
v2:
- use XFREE()
- expand commit comment to point out why allocations are unconditional
---
xen/arch/x86/hvm/viridian/private.h | 2 +-
xen/arch/x86/hvm/viridian/synic.c| 46 -
xen/arch/x86/hvm/viridian/time.c | 38 +++---
xen/arch/x86/hvm/viridian/viridian.c | 75 ++--
xen/include/asm-x86/hvm/domain.h | 2 +-
xen/include/asm-x86/hvm/hvm.h| 4 ++
xen/include/asm-x86/hvm/vcpu.h | 2 +-
xen/include/asm-x86/hvm/viridian.h | 10 ++--
8 files changed, 101 insertions(+), 78 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/private.h
b/xen/arch/x86/hvm/viridian/private.h
index 398b22f12d..46174f48cd 100644
--- a/xen/arch/x86/hvm/viridian/private.h
+++ b/xen/arch/x86/hvm/viridian/private.h
@@ -89,7 +89,7 @@ void viridian_time_load_domain_ctxt(
void viridian_dump_guest_page(const struct vcpu *v, const char *name,
const struct viridian_page *vp);
-void viridian_map_guest_page(struct vcpu *v, struct viridian_page *vp);
+void viridian_map_guest_page(const struct vcpu *v, struct viridian_page *vp);
void viridian_unmap_guest_page(struct viridian_page *vp);
#endif /* X86_HVM_VIRIDIAN_PRIVATE_H */
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index a6ebbbc9f5..28eda7798c 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -28,9 +28,9 @@ typedef union _HV_VP_ASSIST_PAGE
uint8_t ReservedZBytePadding[PAGE_SIZE];
} HV_VP_ASSIST_PAGE;
-void viridian_apic_assist_set(struct vcpu *v)
+void viridian_apic_assist_set(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian.vp_assist.ptr;
+HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
if ( !ptr )
return;
@@ -40,40 +40,40 @@ void viridian_apic_assist_set(struct vcpu *v)
* wrong and the VM will most likely hang so force a crash now
* to make the problem clear.
*/
-if ( v->arch.hvm.viridian.apic_assist_pending )
+if ( v->arch.hvm.viridian->apic_assist_pending )
domain_crash(v->domain);
-v->arch.hvm.viridian.apic_assist_pending = true;
+v->arch.hvm.viridian->apic_assist_pending = true;
ptr->ApicAssist.no_eoi = 1;
}
-bool viridian_apic_assist_completed(struct vcpu *v)
+bool viridian_apic_assist_completed(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian.vp_assist.ptr;
+HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
if ( !ptr )
return false;
-if ( v->arch.hvm.viridian.apic_assist_pending &&
+if ( v->arch.hvm.viridian->apic_assist_pending &&
!ptr->ApicAssist.no_eoi )
{
/* An EOI has been avoided */
-v->arch.hvm.viridian.apic_assist_pending = false;
+v->arch.hvm.viridian->apic_assist_pending = false;
return true;
}
return false;
}
-void viridian_apic_assist_clear(struct vcpu *v)
+void viridian_apic_assist_clear(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian.vp_assist.ptr;
+HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
if ( !ptr )
return;
ptr->ApicAssist.no_eoi = 0;
-v->arch.hvm.viridian.apic_assist_pending = false;
+v->arch.hvm.viridian->apic_assist_pending = false;
}
int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
@@ -95,12 +95,12 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
case HV_X64_MSR_VP_ASSIST_PAGE:
/* release any previous mapping */
-viridian_unmap_guest_page(&v->arch.hvm.viridian
[Xen-devel] [PATCH v9 05/11] viridian: extend init/deinit hooks into synic and time modules
This patch simply adds domain and vcpu init/deinit hooks into the synic
and time modules and wires them into viridian_[domain|vcpu]_[init|deinit]().
Only one of the hooks is currently needed (to unmap the 'VP Assist' page)
but subsequent patches will make use of the others.
NOTE: To perform the unmap of the VP Assist page,
viridian_unmap_guest_page() is now directly called in the new
viridian_synic_vcpu_deinit() function (which is safe even if
is_viridian_vcpu() evaluates to false). This replaces the slightly
hacky mechanism of faking a zero write to the
HV_X64_MSR_VP_ASSIST_PAGE MSR in viridian_cpu_deinit().
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
---
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v4:
- Constify vcpu and domain pointers
v2:
- Pay attention to sync and time init hook return values
---
xen/arch/x86/hvm/viridian/private.h | 12 +
xen/arch/x86/hvm/viridian/synic.c| 19 ++
xen/arch/x86/hvm/viridian/time.c | 18 ++
xen/arch/x86/hvm/viridian/viridian.c | 37 ++--
4 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/private.h
b/xen/arch/x86/hvm/viridian/private.h
index 46174f48cd..8c029f62c6 100644
--- a/xen/arch/x86/hvm/viridian/private.h
+++ b/xen/arch/x86/hvm/viridian/private.h
@@ -74,6 +74,12 @@
int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val);
int viridian_synic_rdmsr(const struct vcpu *v, uint32_t idx, uint64_t *val);
+int viridian_synic_vcpu_init(const struct vcpu *v);
+int viridian_synic_domain_init(const struct domain *d);
+
+void viridian_synic_vcpu_deinit(const struct vcpu *v);
+void viridian_synic_domain_deinit(const struct domain *d);
+
void viridian_synic_save_vcpu_ctxt(const struct vcpu *v,
struct hvm_viridian_vcpu_context *ctxt);
void viridian_synic_load_vcpu_ctxt(
@@ -82,6 +88,12 @@ void viridian_synic_load_vcpu_ctxt(
int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val);
int viridian_time_rdmsr(const struct vcpu *v, uint32_t idx, uint64_t *val);
+int viridian_time_vcpu_init(const struct vcpu *v);
+int viridian_time_domain_init(const struct domain *d);
+
+void viridian_time_vcpu_deinit(const struct vcpu *v);
+void viridian_time_domain_deinit(const struct domain *d);
+
void viridian_time_save_domain_ctxt(
const struct domain *d, struct hvm_viridian_domain_context *ctxt);
void viridian_time_load_domain_ctxt(
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index 05d971b365..4b00dbe1b3 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -146,6 +146,25 @@ int viridian_synic_rdmsr(const struct vcpu *v, uint32_t
idx, uint64_t *val)
return X86EMUL_OKAY;
}
+int viridian_synic_vcpu_init(const struct vcpu *v)
+{
+return 0;
+}
+
+int viridian_synic_domain_init(const struct domain *d)
+{
+return 0;
+}
+
+void viridian_synic_vcpu_deinit(const struct vcpu *v)
+{
+viridian_unmap_guest_page(&v->arch.hvm.viridian->vp_assist);
+}
+
+void viridian_synic_domain_deinit(const struct domain *d)
+{
+}
+
void viridian_synic_save_vcpu_ctxt(const struct vcpu *v,
struct hvm_viridian_vcpu_context *ctxt)
{
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 909a3fb9e3..48aca7e0ab 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -215,6 +215,24 @@ int viridian_time_rdmsr(const struct vcpu *v, uint32_t
idx, uint64_t *val)
return X86EMUL_OKAY;
}
+int viridian_time_vcpu_init(const struct vcpu *v)
+{
+return 0;
+}
+
+int viridian_time_domain_init(const struct domain *d)
+{
+return 0;
+}
+
+void viridian_time_vcpu_deinit(const struct vcpu *v)
+{
+}
+
+void viridian_time_domain_deinit(const struct domain *d)
+{
+}
+
void viridian_time_save_domain_ctxt(
const struct domain *d, struct hvm_viridian_domain_context *ctxt)
{
diff --git a/xen/arch/x86/hvm/viridian/viridian.c
b/xen/arch/x86/hvm/viridian/viridian.c
index 1a20d68aaf..f9a509d918 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -418,22 +418,52 @@ int guest_rdmsr_viridian(const struct vcpu *v, uint32_t
idx, uint64_t *val)
int viridian_vcpu_init(struct vcpu *v)
{
+int rc;
+
ASSERT(!v->arch.hvm.viridian);
v->arch.hvm.viridian = xzalloc(struct viridian_vcpu);
if ( !v->arch.hvm.viridian )
return -ENOMEM;
+rc = viridian_synic_vcpu_init(v);
+if ( rc )
+goto fail;
+
+rc = viridian_time_vcpu_init(v);
+if ( rc )
+goto fail;
+
return 0;
+
+ fail:
+viridian_vcpu_deinit(v);
+
+return rc;
}
int viridian_domain_init(struct domain *d)
{
+int rc;
+
ASSERT(!d->arch.hvm.viridian);
d->arch.hvm.viridian = xzalloc(struct viridian_domain);
if ( !d->arch.hv
[Xen-devel] [PATCH v9 01/11] viridian: add init hooks
This patch adds domain and vcpu init hooks for viridian features. The init
hooks do not yet do anything; the functionality will be added to by
subsequent patches.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v5:
- Put the call to viridian_domain_deinit() back into
hvm_domain_relinquish_resources() where it should be
v3:
- Re-instate call from domain deinit to vcpu deinit
- Move deinit calls to avoid introducing new labels
v2:
- Remove call from domain deinit to vcpu deinit
---
xen/arch/x86/hvm/hvm.c | 10 ++
xen/arch/x86/hvm/viridian/viridian.c | 10 ++
xen/include/asm-x86/hvm/viridian.h | 3 +++
3 files changed, 23 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8adbb61b57..11ce21fc08 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -666,6 +666,10 @@ int hvm_domain_initialise(struct domain *d)
if ( hvm_tsc_scaling_supported )
d->arch.hvm.tsc_scaling_ratio = hvm_default_tsc_scaling_ratio;
+rc = viridian_domain_init(d);
+if ( rc )
+goto fail2;
+
rc = hvm_funcs.domain_initialise(d);
if ( rc != 0 )
goto fail2;
@@ -687,6 +691,7 @@ int hvm_domain_initialise(struct domain *d)
hvm_destroy_cacheattr_region_list(d);
destroy_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0);
fail:
+viridian_domain_deinit(d);
return rc;
}
@@ -1526,6 +1531,10 @@ int hvm_vcpu_initialise(struct vcpu *v)
&& (rc = nestedhvm_vcpu_initialise(v)) < 0 ) /* teardown:
nestedhvm_vcpu_destroy */
goto fail5;
+rc = viridian_vcpu_init(v);
+if ( rc )
+goto fail5;
+
rc = hvm_all_ioreq_servers_add_vcpu(d, v);
if ( rc != 0 )
goto fail6;
@@ -1553,6 +1562,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
fail2:
hvm_vcpu_cacheattr_destroy(v);
fail1:
+viridian_vcpu_deinit(v);
return rc;
}
diff --git a/xen/arch/x86/hvm/viridian/viridian.c
b/xen/arch/x86/hvm/viridian/viridian.c
index 425af56856..5b0eb8a8c7 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -417,6 +417,16 @@ int guest_rdmsr_viridian(const struct vcpu *v, uint32_t
idx, uint64_t *val)
return X86EMUL_OKAY;
}
+int viridian_vcpu_init(struct vcpu *v)
+{
+return 0;
+}
+
+int viridian_domain_init(struct domain *d)
+{
+return 0;
+}
+
void viridian_vcpu_deinit(struct vcpu *v)
{
viridian_synic_wrmsr(v, HV_X64_MSR_VP_ASSIST_PAGE, 0);
diff --git a/xen/include/asm-x86/hvm/viridian.h
b/xen/include/asm-x86/hvm/viridian.h
index ec5ef8d3f9..f072838955 100644
--- a/xen/include/asm-x86/hvm/viridian.h
+++ b/xen/include/asm-x86/hvm/viridian.h
@@ -80,6 +80,9 @@ viridian_hypercall(struct cpu_user_regs *regs);
void viridian_time_ref_count_freeze(struct domain *d);
void viridian_time_ref_count_thaw(struct domain *d);
+int viridian_vcpu_init(struct vcpu *v);
+int viridian_domain_init(struct domain *d);
+
void viridian_vcpu_deinit(struct vcpu *v);
void viridian_domain_deinit(struct domain *d);
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v9 08/11] viridian: stop directly calling viridian_time_ref_count_freeze/thaw()...
...from arch_domain_shutdown/pause/unpause().
A subsequent patch will introduce an implementaion of synthetic timers
which will also need freeze/thaw hooks, so make the exported hooks more
generic and call through to (re-named and static) time_ref_count_freeze/thaw
functions.
NOTE: This patch also introduces a new time_ref_count() helper to return
the current counter value. This is currently only used by the MSR
read handler but the synthetic timer code will also need to use it.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
---
xen/arch/x86/domain.c | 12 ++--
xen/arch/x86/hvm/viridian/time.c | 24 +---
xen/include/asm-x86/hvm/viridian.h | 4 ++--
3 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 8d579e2cf9..02afa7518e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -657,20 +657,20 @@ void arch_domain_destroy(struct domain *d)
void arch_domain_shutdown(struct domain *d)
{
-if ( has_viridian_time_ref_count(d) )
-viridian_time_ref_count_freeze(d);
+if ( is_viridian_domain(d) )
+viridian_time_domain_freeze(d);
}
void arch_domain_pause(struct domain *d)
{
-if ( has_viridian_time_ref_count(d) )
-viridian_time_ref_count_freeze(d);
+if ( is_viridian_domain(d) )
+viridian_time_domain_freeze(d);
}
void arch_domain_unpause(struct domain *d)
{
-if ( has_viridian_time_ref_count(d) )
-viridian_time_ref_count_thaw(d);
+if ( is_viridian_domain(d) )
+viridian_time_domain_thaw(d);
}
int arch_domain_soft_reset(struct domain *d)
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 16fe41d411..71291d921c 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -91,7 +91,7 @@ static int64_t raw_trc_val(const struct domain *d)
return scale_delta(tsc, &tsc_to_ns) / 100ul;
}
-void viridian_time_ref_count_freeze(const struct domain *d)
+static void time_ref_count_freeze(const struct domain *d)
{
struct viridian_time_ref_count *trc =
&d->arch.hvm.viridian->time_ref_count;
@@ -100,7 +100,7 @@ void viridian_time_ref_count_freeze(const struct domain *d)
trc->val = raw_trc_val(d) + trc->off;
}
-void viridian_time_ref_count_thaw(const struct domain *d)
+static void time_ref_count_thaw(const struct domain *d)
{
struct viridian_time_ref_count *trc =
&d->arch.hvm.viridian->time_ref_count;
@@ -110,6 +110,24 @@ void viridian_time_ref_count_thaw(const struct domain *d)
trc->off = (int64_t)trc->val - raw_trc_val(d);
}
+static int64_t time_ref_count(const struct domain *d)
+{
+struct viridian_time_ref_count *trc =
+&d->arch.hvm.viridian->time_ref_count;
+
+return raw_trc_val(d) + trc->off;
+}
+
+void viridian_time_domain_freeze(const struct domain *d)
+{
+time_ref_count_freeze(d);
+}
+
+void viridian_time_domain_thaw(const struct domain *d)
+{
+time_ref_count_thaw(d);
+}
+
int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
{
struct domain *d = v->domain;
@@ -179,7 +197,7 @@ int viridian_time_rdmsr(const struct vcpu *v, uint32_t idx,
uint64_t *val)
printk(XENLOG_G_INFO "d%d: VIRIDIAN MSR_TIME_REF_COUNT:
accessed\n",
d->domain_id);
-*val = raw_trc_val(d) + trc->off;
+*val = time_ref_count(d);
break;
}
diff --git a/xen/include/asm-x86/hvm/viridian.h
b/xen/include/asm-x86/hvm/viridian.h
index c65c044191..8146e2fc46 100644
--- a/xen/include/asm-x86/hvm/viridian.h
+++ b/xen/include/asm-x86/hvm/viridian.h
@@ -77,8 +77,8 @@ int guest_rdmsr_viridian(const struct vcpu *v, uint32_t idx,
uint64_t *val);
int
viridian_hypercall(struct cpu_user_regs *regs);
-void viridian_time_ref_count_freeze(const struct domain *d);
-void viridian_time_ref_count_thaw(const struct domain *d);
+void viridian_time_domain_freeze(const struct domain *d);
+void viridian_time_domain_thaw(const struct domain *d);
int viridian_vcpu_init(struct vcpu *v);
int viridian_domain_init(struct domain *d);
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v9 09/11] viridian: add implementation of synthetic interrupt MSRs
This patch introduces an implementation of the SCONTROL, SVERSION, SIEFP,
SIMP, EOM and SINT0-15 SynIC MSRs. No message source is added and, as such,
nothing will yet generate a synthetic interrupt. A subsequent patch will
add an implementation of synthetic timers which will need the infrastructure
added by this patch to deliver expiry messages to the guest.
NOTE: A 'synic' option is added to the toolstack viridian enlightenments
enumeration but is deliberately not documented as enabling these
SynIC registers without a message source is only useful for
debugging.
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
Reviewed-by: Jan Beulich
---
Cc: Ian Jackson
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: "Roger Pau Monné"
v8:
- Squash in
https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg01332.html
v7:
- Fix out label indentation
v6:
- Address further comments from Jan
v4:
- Address comments from Jan
v3:
- Add the 'SintPollingModeAvailable' bit in CPUID leaf 3
---
tools/libxl/libxl.h| 6 +
tools/libxl/libxl_dom.c| 3 +
tools/libxl/libxl_types.idl| 1 +
xen/arch/x86/hvm/viridian/synic.c | 241 -
xen/arch/x86/hvm/viridian/viridian.c | 19 ++
xen/arch/x86/hvm/vlapic.c | 20 +-
xen/include/asm-x86/hvm/hvm.h | 3 +
xen/include/asm-x86/hvm/viridian.h | 26 +++
xen/include/public/arch-x86/hvm/save.h | 2 +
xen/include/public/hvm/params.h| 7 +-
10 files changed, 323 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index a38e5cdba2..a923a380d3 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -318,6 +318,12 @@
*/
#define LIBXL_HAVE_VIRIDIAN_CRASH_CTL 1
+/*
+ * LIBXL_HAVE_VIRIDIAN_SYNIC indicates that the 'synic' value
+ * is present in the viridian enlightenment enumeration.
+ */
+#define LIBXL_HAVE_VIRIDIAN_SYNIC 1
+
/*
* LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE indicates that
* libxl_domain_build_info has the u.hvm.acpi_laptop_slate field.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 6160991af3..fb758d2ac3 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -317,6 +317,9 @@ static int hvm_set_viridian_features(libxl__gc *gc,
uint32_t domid,
if (libxl_bitmap_test(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_CRASH_CTL))
mask |= HVMPV_crash_ctl;
+if (libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_SYNIC))
+mask |= HVMPV_synic;
+
if (mask != 0 &&
xc_hvm_param_set(CTX->xch,
domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b685ac47ac..9860bcaf5f 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -235,6 +235,7 @@ libxl_viridian_enlightenment =
Enumeration("viridian_enlightenment", [
(4, "hcall_remote_tlb_flush"),
(5, "apic_assist"),
(6, "crash_ctl"),
+(7, "synic"),
])
libxl_hdtype = Enumeration("hdtype", [
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index fb560bc162..84ab02694f 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include "private.h"
@@ -28,6 +29,37 @@ typedef union _HV_VP_ASSIST_PAGE
uint8_t ReservedZBytePadding[PAGE_SIZE];
} HV_VP_ASSIST_PAGE;
+typedef enum HV_MESSAGE_TYPE {
+HvMessageTypeNone,
+HvMessageTimerExpired = 0x8010,
+} HV_MESSAGE_TYPE;
+
+typedef struct HV_MESSAGE_FLAGS {
+uint8_t MessagePending:1;
+uint8_t Reserved:7;
+} HV_MESSAGE_FLAGS;
+
+typedef struct HV_MESSAGE_HEADER {
+HV_MESSAGE_TYPE MessageType;
+uint16_t Reserved1;
+HV_MESSAGE_FLAGS MessageFlags;
+uint8_t PayloadSize;
+uint64_t Reserved2;
+} HV_MESSAGE_HEADER;
+
+#define HV_MESSAGE_SIZE 256
+#define HV_MESSAGE_MAX_PAYLOAD_QWORD_COUNT 30
+
+typedef struct HV_MESSAGE {
+HV_MESSAGE_HEADER Header;
+uint64_t Payload[HV_MESSAGE_MAX_PAYLOAD_QWORD_COUNT];
+} HV_MESSAGE;
+
+void __init __maybe_unused build_assertions(void)
+{
+BUILD_BUG_ON(sizeof(HV_MESSAGE) != HV_MESSAGE_SIZE);
+}
+
void viridian_apic_assist_set(const struct vcpu *v)
{
struct viridian_vcpu *vv = v->arch.hvm.viridian;
@@ -83,6 +115,8 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
struct viridian_vcpu *vv = v->arch.hvm.viridian;
struct domain *d = v->domain;
+ASSERT(v == current || !v->is_running);
+
switch ( idx )
{
case HV_X64_MSR_EOI:
@@ -107,6 +141,76 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
viridian_map_guest_page(d, &vv->vp_assist);
break;
+case HV_X64_MSR_SCONTROL:
+if ( !(viridian_feature_mask(d) & HVMPV_synic) )
+
[Xen-devel] [PATCH v9 00/11] viridian: implement more enlightenments
This series adds three new enlightenments: - Synthetic timers, which depends on the... - Synthetic interrupt controller (or SynIC) - Synthetic cluster IPI All these enlightenments are implemented in current versions of QEMU/KVM so this series closes the gap. Paul Durrant (11): viridian: add init hooks viridian: separately allocate domain and vcpu structures viridian: use stack variables for viridian_vcpu and viridian_domain... viridian: make 'fields' struct anonymous... viridian: extend init/deinit hooks into synic and time modules viridian: add missing context save helpers into synic and time modules viridian: use viridian_map/unmap_guest_page() for reference tsc page viridian: stop directly calling viridian_time_ref_count_freeze/thaw()... viridian: add implementation of synthetic interrupt MSRs viridian: add implementation of synthetic timers viridian: add implementation of the HvSendSyntheticClusterIpi hypercall docs/man/xl.cfg.5.pod.in | 18 +- tools/libxl/libxl.h| 18 + tools/libxl/libxl_dom.c| 10 + tools/libxl/libxl_types.idl| 3 + xen/arch/x86/domain.c | 12 +- xen/arch/x86/hvm/hvm.c | 10 + xen/arch/x86/hvm/viridian/private.h| 31 +- xen/arch/x86/hvm/viridian/synic.c | 376 -- xen/arch/x86/hvm/viridian/time.c | 518 ++--- xen/arch/x86/hvm/viridian/viridian.c | 229 +-- xen/arch/x86/hvm/vlapic.c | 20 +- xen/include/asm-x86/hvm/domain.h | 2 +- xen/include/asm-x86/hvm/hvm.h | 7 + xen/include/asm-x86/hvm/vcpu.h | 2 +- xen/include/asm-x86/hvm/viridian.h | 75 +++- xen/include/public/arch-x86/hvm/save.h | 4 + xen/include/public/hvm/params.h| 17 +- 17 files changed, 1212 insertions(+), 140 deletions(-) v8: - Squash in follow-up series v4: - Add two cleanup patches (#3 and #4) and re-order #8 and #9 v3: - Add the synthetic cluster IPI patch (#11) --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: "Roger Pau Monné" Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v9 06/11] viridian: add missing context save helpers into synic and time modules
Currently the time module lacks vcpu context save helpers and the synic
module lacks domain context save helpers. These helpers are not yet
required but subsequent patches will require at least some of them so this
patch completes the set to avoid introducing them in an ad-hoc way.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v3:
- Add missing callers so that they are not added in an ad-hoc way
---
xen/arch/x86/hvm/viridian/private.h | 10 ++
xen/arch/x86/hvm/viridian/synic.c| 10 ++
xen/arch/x86/hvm/viridian/time.c | 10 ++
xen/arch/x86/hvm/viridian/viridian.c | 4
4 files changed, 34 insertions(+)
diff --git a/xen/arch/x86/hvm/viridian/private.h
b/xen/arch/x86/hvm/viridian/private.h
index 8c029f62c6..5078b2d2ab 100644
--- a/xen/arch/x86/hvm/viridian/private.h
+++ b/xen/arch/x86/hvm/viridian/private.h
@@ -85,6 +85,11 @@ void viridian_synic_save_vcpu_ctxt(const struct vcpu *v,
void viridian_synic_load_vcpu_ctxt(
struct vcpu *v, const struct hvm_viridian_vcpu_context *ctxt);
+void viridian_synic_save_domain_ctxt(
+const struct domain *d, struct hvm_viridian_domain_context *ctxt);
+void viridian_synic_load_domain_ctxt(
+struct domain *d, const struct hvm_viridian_domain_context *ctxt);
+
int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val);
int viridian_time_rdmsr(const struct vcpu *v, uint32_t idx, uint64_t *val);
@@ -94,6 +99,11 @@ int viridian_time_domain_init(const struct domain *d);
void viridian_time_vcpu_deinit(const struct vcpu *v);
void viridian_time_domain_deinit(const struct domain *d);
+void viridian_time_save_vcpu_ctxt(
+const struct vcpu *v, struct hvm_viridian_vcpu_context *ctxt);
+void viridian_time_load_vcpu_ctxt(
+struct vcpu *v, const struct hvm_viridian_vcpu_context *ctxt);
+
void viridian_time_save_domain_ctxt(
const struct domain *d, struct hvm_viridian_domain_context *ctxt);
void viridian_time_load_domain_ctxt(
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index 4b00dbe1b3..b8dab4b246 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -186,6 +186,16 @@ void viridian_synic_load_vcpu_ctxt(
vv->apic_assist_pending = ctxt->apic_assist_pending;
}
+void viridian_synic_save_domain_ctxt(
+const struct domain *d, struct hvm_viridian_domain_context *ctxt)
+{
+}
+
+void viridian_synic_load_domain_ctxt(
+struct domain *d, const struct hvm_viridian_domain_context *ctxt)
+{
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 48aca7e0ab..4399e62f54 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -233,6 +233,16 @@ void viridian_time_domain_deinit(const struct domain *d)
{
}
+void viridian_time_save_vcpu_ctxt(
+const struct vcpu *v, struct hvm_viridian_vcpu_context *ctxt)
+{
+}
+
+void viridian_time_load_vcpu_ctxt(
+struct vcpu *v, const struct hvm_viridian_vcpu_context *ctxt)
+{
+}
+
void viridian_time_save_domain_ctxt(
const struct domain *d, struct hvm_viridian_domain_context *ctxt)
{
diff --git a/xen/arch/x86/hvm/viridian/viridian.c
b/xen/arch/x86/hvm/viridian/viridian.c
index f9a509d918..742a988252 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -707,6 +707,7 @@ static int viridian_save_domain_ctxt(struct vcpu *v,
return 0;
viridian_time_save_domain_ctxt(d, &ctxt);
+viridian_synic_save_domain_ctxt(d, &ctxt);
return (hvm_save_entry(VIRIDIAN_DOMAIN, 0, h, &ctxt) != 0);
}
@@ -723,6 +724,7 @@ static int viridian_load_domain_ctxt(struct domain *d,
vd->hypercall_gpa.raw = ctxt.hypercall_gpa;
vd->guest_os_id.raw = ctxt.guest_os_id;
+viridian_synic_load_domain_ctxt(d, &ctxt);
viridian_time_load_domain_ctxt(d, &ctxt);
return 0;
@@ -738,6 +740,7 @@ static int viridian_save_vcpu_ctxt(struct vcpu *v,
hvm_domain_context_t *h)
if ( !is_viridian_vcpu(v) )
return 0;
+viridian_time_save_vcpu_ctxt(v, &ctxt);
viridian_synic_save_vcpu_ctxt(v, &ctxt);
return hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, &ctxt);
@@ -764,6 +767,7 @@ static int viridian_load_vcpu_ctxt(struct domain *d,
return -EINVAL;
viridian_synic_load_vcpu_ctxt(v, &ctxt);
+viridian_time_load_vcpu_ctxt(v, &ctxt);
return 0;
}
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v9 07/11] viridian: use viridian_map/unmap_guest_page() for reference tsc page
Whilst the reference tsc page does not currently need to be kept mapped
after it is initially set up (or updated after migrate), the code can
be simplified by using the common guest page map/unmap and dump functions.
New functionality added by a subsequent patch will also require the page to
kept mapped for the lifetime of the domain.
NOTE: Because the reference tsc page is per-domain rather than per-vcpu
this patch also changes viridian_map_guest_page() to take a domain
pointer rather than a vcpu pointer. The domain pointer cannot be
const, unlike the vcpu pointer.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
---
xen/arch/x86/hvm/viridian/private.h | 2 +-
xen/arch/x86/hvm/viridian/synic.c| 6 ++-
xen/arch/x86/hvm/viridian/time.c | 56 +---
xen/arch/x86/hvm/viridian/viridian.c | 3 +-
xen/include/asm-x86/hvm/viridian.h | 2 +-
5 files changed, 25 insertions(+), 44 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/private.h
b/xen/arch/x86/hvm/viridian/private.h
index 5078b2d2ab..96a784b840 100644
--- a/xen/arch/x86/hvm/viridian/private.h
+++ b/xen/arch/x86/hvm/viridian/private.h
@@ -111,7 +111,7 @@ void viridian_time_load_domain_ctxt(
void viridian_dump_guest_page(const struct vcpu *v, const char *name,
const struct viridian_page *vp);
-void viridian_map_guest_page(const struct vcpu *v, struct viridian_page *vp);
+void viridian_map_guest_page(struct domain *d, struct viridian_page *vp);
void viridian_unmap_guest_page(struct viridian_page *vp);
#endif /* X86_HVM_VIRIDIAN_PRIVATE_H */
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index b8dab4b246..fb560bc162 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -81,6 +81,7 @@ void viridian_apic_assist_clear(const struct vcpu *v)
int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
{
struct viridian_vcpu *vv = v->arch.hvm.viridian;
+struct domain *d = v->domain;
switch ( idx )
{
@@ -103,7 +104,7 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
vv->vp_assist.msr.raw = val;
viridian_dump_guest_page(v, "VP_ASSIST", &vv->vp_assist);
if ( vv->vp_assist.msr.enabled )
-viridian_map_guest_page(v, &vv->vp_assist);
+viridian_map_guest_page(d, &vv->vp_assist);
break;
default:
@@ -178,10 +179,11 @@ void viridian_synic_load_vcpu_ctxt(
struct vcpu *v, const struct hvm_viridian_vcpu_context *ctxt)
{
struct viridian_vcpu *vv = v->arch.hvm.viridian;
+struct domain *d = v->domain;
vv->vp_assist.msr.raw = ctxt->vp_assist_msr;
if ( vv->vp_assist.msr.enabled )
-viridian_map_guest_page(v, &vv->vp_assist);
+viridian_map_guest_page(d, &vv->vp_assist);
vv->apic_assist_pending = ctxt->apic_assist_pending;
}
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 4399e62f54..16fe41d411 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -25,33 +25,10 @@ typedef struct _HV_REFERENCE_TSC_PAGE
uint64_t Reserved2[509];
} HV_REFERENCE_TSC_PAGE, *PHV_REFERENCE_TSC_PAGE;
-static void dump_reference_tsc(const struct domain *d)
-{
-const union viridian_page_msr *rt = &d->arch.hvm.viridian->reference_tsc;
-
-if ( !rt->enabled )
-return;
-
-printk(XENLOG_G_INFO "d%d: VIRIDIAN REFERENCE_TSC: pfn: %lx\n",
- d->domain_id, (unsigned long)rt->pfn);
-}
-
static void update_reference_tsc(struct domain *d, bool initialize)
{
-unsigned long gmfn = d->arch.hvm.viridian->reference_tsc.pfn;
-struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
-HV_REFERENCE_TSC_PAGE *p;
-
-if ( !page || !get_page_type(page, PGT_writable_page) )
-{
-if ( page )
-put_page(page);
-gdprintk(XENLOG_WARNING, "Bad GMFN %#"PRI_gfn" (MFN %#"PRI_mfn")\n",
- gmfn, mfn_x(page ? page_to_mfn(page) : INVALID_MFN));
-return;
-}
-
-p = __map_domain_page(page);
+const struct viridian_page *rt = &d->arch.hvm.viridian->reference_tsc;
+HV_REFERENCE_TSC_PAGE *p = rt->ptr;
if ( initialize )
clear_page(p);
@@ -82,7 +59,7 @@ static void update_reference_tsc(struct domain *d, bool
initialize)
printk(XENLOG_G_INFO "d%d: VIRIDIAN REFERENCE_TSC: invalidated\n",
d->domain_id);
-goto out;
+return;
}
/*
@@ -100,11 +77,6 @@ static void update_reference_tsc(struct domain *d, bool
initialize)
if ( p->TscSequence == 0x ||
p->TscSequence == 0 ) /* Avoid both 'invalid' values */
p->TscSequence = 1;
-
- out:
-unmap_domain_page(p);
-
-put_page_and_type(page);
}
static int64_t raw_trc_val(const struct domain *d)
@@ -149,10 +
[Xen-devel] [PATCH v9 04/11] viridian: make 'fields' struct anonymous...
...inside viridian_page_msr and viridian_guest_os_id_msr unions.
There's no need to name it and the code is shortened by not doing so.
No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
xen/arch/x86/hvm/viridian/synic.c| 4 ++--
xen/arch/x86/hvm/viridian/time.c | 10 +-
xen/arch/x86/hvm/viridian/viridian.c | 20 +---
xen/include/asm-x86/hvm/viridian.h | 4 ++--
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index f3d9f7ae74..05d971b365 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -102,7 +102,7 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
viridian_unmap_guest_page(&vv->vp_assist);
vv->vp_assist.msr.raw = val;
viridian_dump_guest_page(v, "VP_ASSIST", &vv->vp_assist);
-if ( vv->vp_assist.msr.fields.enabled )
+if ( vv->vp_assist.msr.enabled )
viridian_map_guest_page(v, &vv->vp_assist);
break;
@@ -161,7 +161,7 @@ void viridian_synic_load_vcpu_ctxt(
struct viridian_vcpu *vv = v->arch.hvm.viridian;
vv->vp_assist.msr.raw = ctxt->vp_assist_msr;
-if ( vv->vp_assist.msr.fields.enabled )
+if ( vv->vp_assist.msr.enabled )
viridian_map_guest_page(v, &vv->vp_assist);
vv->apic_assist_pending = ctxt->apic_assist_pending;
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 76f9612001..909a3fb9e3 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -29,16 +29,16 @@ static void dump_reference_tsc(const struct domain *d)
{
const union viridian_page_msr *rt = &d->arch.hvm.viridian->reference_tsc;
-if ( !rt->fields.enabled )
+if ( !rt->enabled )
return;
printk(XENLOG_G_INFO "d%d: VIRIDIAN REFERENCE_TSC: pfn: %lx\n",
- d->domain_id, (unsigned long)rt->fields.pfn);
+ d->domain_id, (unsigned long)rt->pfn);
}
static void update_reference_tsc(struct domain *d, bool initialize)
{
-unsigned long gmfn = d->arch.hvm.viridian->reference_tsc.fields.pfn;
+unsigned long gmfn = d->arch.hvm.viridian->reference_tsc.pfn;
struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
HV_REFERENCE_TSC_PAGE *p;
@@ -151,7 +151,7 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
vd->reference_tsc.raw = val;
dump_reference_tsc(d);
-if ( vd->reference_tsc.fields.enabled )
+if ( vd->reference_tsc.enabled )
update_reference_tsc(d, true);
break;
@@ -232,7 +232,7 @@ void viridian_time_load_domain_ctxt(
vd->time_ref_count.val = ctxt->time_ref_count;
vd->reference_tsc.raw = ctxt->reference_tsc;
-if ( vd->reference_tsc.fields.enabled )
+if ( vd->reference_tsc.enabled )
update_reference_tsc(d, false);
}
diff --git a/xen/arch/x86/hvm/viridian/viridian.c
b/xen/arch/x86/hvm/viridian/viridian.c
index 710470fed7..1a20d68aaf 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -192,7 +192,7 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t
leaf,
case 4:
/* Recommended hypercall usage. */
-if ( vd->guest_os_id.raw == 0 || vd->guest_os_id.fields.os < 4 )
+if ( vd->guest_os_id.raw == 0 || vd->guest_os_id.os < 4 )
break;
res->a = CPUID4A_RELAX_TIMER_INT;
if ( viridian_feature_mask(d) & HVMPV_hcall_remote_tlb_flush )
@@ -228,10 +228,8 @@ static void dump_guest_os_id(const struct domain *d)
printk(XENLOG_G_INFO
"d%d: VIRIDIAN GUEST_OS_ID: vendor: %x os: %x major: %x minor: %x
sp: %x build: %x\n",
- d->domain_id,
- goi->fields.vendor, goi->fields.os,
- goi->fields.major, goi->fields.minor,
- goi->fields.service_pack, goi->fields.build_number);
+ d->domain_id, goi->vendor, goi->os, goi->major, goi->minor,
+ goi->service_pack, goi->build_number);
}
static void dump_hypercall(const struct domain *d)
@@ -242,12 +240,12 @@ static void dump_hypercall(const struct domain *d)
printk(XENLOG_G_INFO "d%d: VIRIDIAN HYPERCALL: enabled: %x pfn: %lx\n",
d->domain_id,
- hg->fields.enabled, (unsigned long)hg->fields.pfn);
+ hg->enabled, (unsigned long)hg->pfn);
}
static void enable_hypercall_page(struct domain *d)
{
-unsigned long gmfn = d->arch.hvm.viridian->hypercall_gpa.fields.pfn;
+unsigned long gmfn = d->arch.hvm.viridian->hypercall_gpa.pfn;
struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
uint8_t *p;
@@ -297,7 +295,7 @@ int guest_wrmsr_viridian(struct vcpu *v, uint32_t idx,
uint64_t val)
case HV_X64_MSR_HYPERCALL:
vd->hy
[Xen-devel] [PATCH v9 03/11] viridian: use stack variables for viridian_vcpu and viridian_domain...
...where there is more than one dereference inside a function.
This shortens the code and makes it more readable. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
xen/arch/x86/hvm/viridian/synic.c| 49
xen/arch/x86/hvm/viridian/time.c | 27 ---
xen/arch/x86/hvm/viridian/viridian.c | 47 +-
3 files changed, 69 insertions(+), 54 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index 28eda7798c..f3d9f7ae74 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -30,7 +30,8 @@ typedef union _HV_VP_ASSIST_PAGE
void viridian_apic_assist_set(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
+struct viridian_vcpu *vv = v->arch.hvm.viridian;
+HV_VP_ASSIST_PAGE *ptr = vv->vp_assist.ptr;
if ( !ptr )
return;
@@ -40,25 +41,25 @@ void viridian_apic_assist_set(const struct vcpu *v)
* wrong and the VM will most likely hang so force a crash now
* to make the problem clear.
*/
-if ( v->arch.hvm.viridian->apic_assist_pending )
+if ( vv->apic_assist_pending )
domain_crash(v->domain);
-v->arch.hvm.viridian->apic_assist_pending = true;
+vv->apic_assist_pending = true;
ptr->ApicAssist.no_eoi = 1;
}
bool viridian_apic_assist_completed(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
+struct viridian_vcpu *vv = v->arch.hvm.viridian;
+HV_VP_ASSIST_PAGE *ptr = vv->vp_assist.ptr;
if ( !ptr )
return false;
-if ( v->arch.hvm.viridian->apic_assist_pending &&
- !ptr->ApicAssist.no_eoi )
+if ( vv->apic_assist_pending && !ptr->ApicAssist.no_eoi )
{
/* An EOI has been avoided */
-v->arch.hvm.viridian->apic_assist_pending = false;
+vv->apic_assist_pending = false;
return true;
}
@@ -67,17 +68,20 @@ bool viridian_apic_assist_completed(const struct vcpu *v)
void viridian_apic_assist_clear(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
+struct viridian_vcpu *vv = v->arch.hvm.viridian;
+HV_VP_ASSIST_PAGE *ptr = vv->vp_assist.ptr;
if ( !ptr )
return;
ptr->ApicAssist.no_eoi = 0;
-v->arch.hvm.viridian->apic_assist_pending = false;
+vv->apic_assist_pending = false;
}
int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
{
+struct viridian_vcpu *vv = v->arch.hvm.viridian;
+
switch ( idx )
{
case HV_X64_MSR_EOI:
@@ -95,12 +99,11 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
case HV_X64_MSR_VP_ASSIST_PAGE:
/* release any previous mapping */
-viridian_unmap_guest_page(&v->arch.hvm.viridian->vp_assist);
-v->arch.hvm.viridian->vp_assist.msr.raw = val;
-viridian_dump_guest_page(v, "VP_ASSIST",
- &v->arch.hvm.viridian->vp_assist);
-if ( v->arch.hvm.viridian->vp_assist.msr.fields.enabled )
-viridian_map_guest_page(v, &v->arch.hvm.viridian->vp_assist);
+viridian_unmap_guest_page(&vv->vp_assist);
+vv->vp_assist.msr.raw = val;
+viridian_dump_guest_page(v, "VP_ASSIST", &vv->vp_assist);
+if ( vv->vp_assist.msr.fields.enabled )
+viridian_map_guest_page(v, &vv->vp_assist);
break;
default:
@@ -146,18 +149,22 @@ int viridian_synic_rdmsr(const struct vcpu *v, uint32_t
idx, uint64_t *val)
void viridian_synic_save_vcpu_ctxt(const struct vcpu *v,
struct hvm_viridian_vcpu_context *ctxt)
{
-ctxt->apic_assist_pending = v->arch.hvm.viridian->apic_assist_pending;
-ctxt->vp_assist_msr = v->arch.hvm.viridian->vp_assist.msr.raw;
+const struct viridian_vcpu *vv = v->arch.hvm.viridian;
+
+ctxt->apic_assist_pending = vv->apic_assist_pending;
+ctxt->vp_assist_msr = vv->vp_assist.msr.raw;
}
void viridian_synic_load_vcpu_ctxt(
struct vcpu *v, const struct hvm_viridian_vcpu_context *ctxt)
{
-v->arch.hvm.viridian->vp_assist.msr.raw = ctxt->vp_assist_msr;
-if ( v->arch.hvm.viridian->vp_assist.msr.fields.enabled )
-viridian_map_guest_page(v, &v->arch.hvm.viridian->vp_assist);
+struct viridian_vcpu *vv = v->arch.hvm.viridian;
+
+vv->vp_assist.msr.raw = ctxt->vp_assist_msr;
+if ( vv->vp_assist.msr.fields.enabled )
+viridian_map_guest_page(v, &vv->vp_assist);
-v->arch.hvm.viridian->apic_assist_pending = ctxt->apic_assist_pending;
+vv->apic_assist_pending = ctxt->apic_assist_pending;
}
/*
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index a7e94aadf0..76f9612001 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/
[Xen-devel] [PATCH v9 10/11] viridian: add implementation of synthetic timers
This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs
and hence a the first SynIC message source.
The new (and documented) 'stimer' viridian enlightenment group may be
specified to enable this feature.
While in the neighbourhood, this patch adds a missing check for an
attempt to write the time reference count MSR, which should result in an
exception (but not be reported as an unimplemented MSR).
NOTE: It is necessary for correct operation that timer expiration and
message delivery time-stamping use the same time source as the guest.
The specification is ambiguous but testing with a Windows 10 1803
guest has shown that using the partition reference counter as a
source whilst the guest is using RDTSC and the reference tsc page
does not work correctly. Therefore the time_now() function is used.
This implements the algorithm for acquiring partition reference time
that is documented in the specifiction.
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
---
Cc: Ian Jackson
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: "Roger Pau Monné"
v9:
- Revert some of the changes in v8 to make sure that the timer config
is only touched in current context or when the vcpu is not running
v8:
- Squash in
https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg01333.html
v7:
- Make sure missed count cannot be zero if expiration < now
v6:
- Stop using the reference tsc page in time_now()
- Address further comments from Jan
v5:
- Fix time_now() to read TSC as the guest would see it
v4:
- Address comments from Jan
v3:
- Re-worked missed ticks calculation
---
docs/man/xl.cfg.5.pod.in | 12 +-
tools/libxl/libxl.h| 6 +
tools/libxl/libxl_dom.c| 4 +
tools/libxl/libxl_types.idl| 1 +
xen/arch/x86/hvm/viridian/private.h| 9 +-
xen/arch/x86/hvm/viridian/synic.c | 55 +++-
xen/arch/x86/hvm/viridian/time.c | 389 -
xen/arch/x86/hvm/viridian/viridian.c | 5 +
xen/include/asm-x86/hvm/viridian.h | 32 +-
xen/include/public/arch-x86/hvm/save.h | 2 +
xen/include/public/hvm/params.h| 7 +-
11 files changed, 509 insertions(+), 13 deletions(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index ad81af1ed8..355c654693 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2167,11 +2167,19 @@ This group incorporates the crash control MSRs. These
enlightenments
allow Windows to write crash information such that it can be logged
by Xen.
+=item B
+
+This set incorporates the SynIC and synthetic timer MSRs. Windows will
+use synthetic timers in preference to emulated HPET for a source of
+ticks and hence enabling this group will ensure that ticks will be
+consistent with use of an enlightened time source (B or
+B).
+
=item B
This is a special value that enables the default set of groups, which
-is currently the B, B, B, B
-and B groups.
+is currently the B, B, B, B,
+B and B groups.
=item B
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index a923a380d3..c8f219b0d3 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -324,6 +324,12 @@
*/
#define LIBXL_HAVE_VIRIDIAN_SYNIC 1
+/*
+ * LIBXL_HAVE_VIRIDIAN_STIMER indicates that the 'stimer' value
+ * is present in the viridian enlightenment enumeration.
+ */
+#define LIBXL_HAVE_VIRIDIAN_STIMER 1
+
/*
* LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE indicates that
* libxl_domain_build_info has the u.hvm.acpi_laptop_slate field.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fb758d2ac3..2ee0f82ee7 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -269,6 +269,7 @@ static int hvm_set_viridian_features(libxl__gc *gc,
uint32_t domid,
libxl_bitmap_set(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_TIME_REF_COUNT);
libxl_bitmap_set(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_APIC_ASSIST);
libxl_bitmap_set(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_CRASH_CTL);
+libxl_bitmap_set(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_STIMER);
}
libxl_for_each_set_bit(v, info->u.hvm.viridian_enable) {
@@ -320,6 +321,9 @@ static int hvm_set_viridian_features(libxl__gc *gc,
uint32_t domid,
if (libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_SYNIC))
mask |= HVMPV_synic;
+if (libxl_bitmap_test(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_STIMER))
+mask |= HVMPV_time_ref_count | HVMPV_synic | HVMPV_stimer;
+
if (mask != 0 &&
xc_hvm_param_set(CTX->xch,
domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 9860bcaf5f..1cce249de4 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -236,6 +236,7 @@ libxl_vir
[Xen-devel] [PATCH v9 11/11] viridian: add implementation of the HvSendSyntheticClusterIpi hypercall
This patch adds an implementation of the hypercall as documented in the
specification [1], section 10.5.2. This enlightenment, as with others, is
advertised by CPUID leaf 0x4004 and is under control of a new
'hcall_ipi' option in libxl.
If used, this enlightenment should mean the guest only takes a single VMEXIT
to issue IPIs to multiple vCPUs rather than the multiple VMEXITs that would
result from using the emulated local APIC.
[1]
https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/live/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0C.pdf
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
Reviewed-by: Jan Beulich
---
Cc: Ian Jackson
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: "Roger Pau Monné"
v4:
- Address comments from Jan
v3:
- New in v3
---
docs/man/xl.cfg.5.pod.in | 6 +++
tools/libxl/libxl.h | 6 +++
tools/libxl/libxl_dom.c | 3 ++
tools/libxl/libxl_types.idl | 1 +
xen/arch/x86/hvm/viridian/viridian.c | 63
xen/include/public/hvm/params.h | 7 +++-
6 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 355c654693..c7d70e618b 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2175,6 +2175,12 @@ ticks and hence enabling this group will ensure that
ticks will be
consistent with use of an enlightened time source (B or
B).
+=item B
+
+This set incorporates use of a hypercall for interprocessor interrupts.
+This enlightenment may improve performance of Windows guests with multiple
+virtual CPUs.
+
=item B
This is a special value that enables the default set of groups, which
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c8f219b0d3..482499a6c0 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -330,6 +330,12 @@
*/
#define LIBXL_HAVE_VIRIDIAN_STIMER 1
+/*
+ * LIBXL_HAVE_VIRIDIAN_HCALL_IPI indicates that the 'hcall_ipi' value
+ * is present in the viridian enlightenment enumeration.
+ */
+#define LIBXL_HAVE_VIRIDIAN_HCALL_IPI 1
+
/*
* LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE indicates that
* libxl_domain_build_info has the u.hvm.acpi_laptop_slate field.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2ee0f82ee7..879c806139 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -324,6 +324,9 @@ static int hvm_set_viridian_features(libxl__gc *gc,
uint32_t domid,
if (libxl_bitmap_test(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_STIMER))
mask |= HVMPV_time_ref_count | HVMPV_synic | HVMPV_stimer;
+if (libxl_bitmap_test(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_HCALL_IPI))
+mask |= HVMPV_hcall_ipi;
+
if (mask != 0 &&
xc_hvm_param_set(CTX->xch,
domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 1cce249de4..cb4702fd7a 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -237,6 +237,7 @@ libxl_viridian_enlightenment =
Enumeration("viridian_enlightenment", [
(6, "crash_ctl"),
(7, "synic"),
(8, "stimer"),
+(9, "hcall_ipi"),
])
libxl_hdtype = Enumeration("hdtype", [
diff --git a/xen/arch/x86/hvm/viridian/viridian.c
b/xen/arch/x86/hvm/viridian/viridian.c
index dce648bb4e..4b06b78a27 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -28,6 +28,7 @@
#define HvFlushVirtualAddressSpace 0x0002
#define HvFlushVirtualAddressList 0x0003
#define HvNotifyLongSpinWait 0x0008
+#define HvSendSyntheticClusterIpi 0x000b
#define HvGetPartitionId 0x0046
#define HvExtCallQueryCapabilities 0x8001
@@ -95,6 +96,7 @@ typedef union _HV_CRASH_CTL_REG_CONTENTS
#define CPUID4A_HCALL_REMOTE_TLB_FLUSH (1 << 2)
#define CPUID4A_MSR_BASED_APIC (1 << 3)
#define CPUID4A_RELAX_TIMER_INT(1 << 5)
+#define CPUID4A_SYNTHETIC_CLUSTER_IPI (1 << 10)
/* Viridian CPUID leaf 6: Implementation HW features detected and in use */
#define CPUID6A_APIC_OVERLAY(1 << 0)
@@ -206,6 +208,8 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t
leaf,
res->a |= CPUID4A_HCALL_REMOTE_TLB_FLUSH;
if ( !cpu_has_vmx_apic_reg_virt )
res->a |= CPUID4A_MSR_BASED_APIC;
+if ( viridian_feature_mask(d) & HVMPV_hcall_ipi )
+res->a |= CPUID4A_SYNTHETIC_CLUSTER_IPI;
/*
* This value is the recommended number of attempts to try to
@@ -628,6 +632,65 @@ int viridian_hypercall(struct cpu_user_regs *regs)
break;
}
+case HvSendSyntheticClusterIpi:
+{
+struct vcpu *v;
+uint32_t vector;
+uint64_t vcpu_mask;
+
+status = HV_STATUS_INVALID_PARAMETER;
+
+/* Get input parameters. */
+if ( input.fast )
+{
+
[Xen-devel] [xen-unstable test] 133896: tolerable FAIL
flight 133896 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/133896/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133864 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133864 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 133864 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133864 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 133864 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 133864 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 133864 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133864 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 133864 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 1e780ef5a527661d1d6106ccacf65706e3ed664d baseline version: xen 1e780ef5a527661d1d6106ccacf65706e3ed664d Last test of basis 133896 2019-03-18 08:18:24 Z1 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64
[Xen-devel] Arm boot regression with Xen 4.12
(+ Juergen)
Hi Amit,
On 3/18/19 3:12 PM, Amit Tomer wrote:
>> It will be difficult to help without any log. You probably want to try with
>> Stefano series instead. However ...
>
> If we comment out GPU node(gpu@3800) , we don't see this issue and
> Dom0 kernel is
> loaded into memory but we following crash:
>
> Starting kernel ...
>
> - UART enabled -
> - CPU booting -
> - Current EL 0008 -
> - Xen starting at EL2 -
> - Zero BSS -
> - Setting up control registers -
> - Turning on paging -
> - Ready -
> (XEN) Checking for initrd in /chosen
> (XEN) RAM: 4000 - bfff
> (XEN)
> (XEN) MODULE[0]: be511000 - be51d000 Device Tree
> (XEN) MODULE[1]: 4048 - 4268 Kernel
> (XEN) RESVD[0]: 4300 - 4300c000
> (XEN) RESVD[1]: be511000 - be51d000
[...]
> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
> (XEN) Data Abort Trap. Syndrome=0x6
> (XEN) Walking Hypervisor VA 0x8 on CPU0 via TTBR 0x42114000
> (XEN) 0TH[0x0] = 0x42113f7f
> (XEN) 1ST[0x0] = 0x42110f7f
> (XEN) 2ND[0x0] = 0x
> (XEN) CPU0: Unexpected Trap: Data Abort
> (XEN) [ Xen-4.12.0-rc arm64 debug=y Not tainted ]
> (XEN) CPU:0
> (XEN) PC: 0021c220 page_alloc.c#free_heap_pages+0x3b0/0x58c
[...]
> (XEN) Xen call trace:
> (XEN)[<0021c220>] page_alloc.c#free_heap_pages+0x3b0/0x58c (PC)
> (XEN)[<0021c20c>] page_alloc.c#free_heap_pages+0x39c/0x58c (LR)
> (XEN)[<0021e5f4>] page_alloc.c#init_heap_pages+0x334/0x4ec
> (XEN)[<0021e840>] init_domheap_pages+0x94/0x9c
> (XEN)[<0024e178>] free_init_memory+0xac/0xe0
> (XEN)[<00252580>] setup.c#init_done+0x14/0x20
> (XEN)[<0029daa8>] 0029daa8
> (XEN)
> (XEN)
> (XEN)
> (XEN) Panic on CPU 0:
> (XEN) CPU0: Unexpected Trap: Data Abort
> (XEN)
> (XEN)
> (XEN) Reboot in five seconds...
Could you give a try to the below patch?
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 01ae20..2c34138bbd 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1139,7 +1139,7 @@ void free_init_memory(void)
*(p + i) = insn;
set_pte_flags_on_range(__init_begin, len, mg_clear);
-init_domheap_pages(pa, pa + len);
+dt_unreserved_regions(pa, pa + len, init_domheap_pages, 0);
printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 444857a967..8dbc4f819b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -764,18 +764,18 @@ void __init start_xen(unsigned long boot_phys_offset,
"Please check your bootloader.\n",
fdt_paddr);
-fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
-
-cmdline = boot_fdt_cmdline(device_tree_flattened);
-printk("Command line: %s\n", cmdline);
-cmdline_parse(cmdline);
-
/* Register Xen's load address as a boot module. */
xen_bootmodule = add_boot_module(BOOTMOD_XEN,
(paddr_t)(uintptr_t)(_start + boot_phys_offset),
(paddr_t)(uintptr_t)(_end - _start + 1), false);
BUG_ON(!xen_bootmodule);
+fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
+
+cmdline = boot_fdt_cmdline(device_tree_flattened);
+printk("Command line: %s\n", cmdline);
+cmdline_parse(cmdline);
+
setup_pagetables(boot_phys_offset);
setup_mm(fdt_paddr, fdt_size);
Now the long answer.
Unfortunately, in a recent page, I removed the log telling where
Xen lives in memory, so I am not 100% sure this is your problem.
From my own testing, I think the problem is Xen will try to hand reserved
memory (the old fashion /memreserve/ and not /reserved-regions) to the
allocator. This happen when freeing the init regions (see free_init_memory).
We do handle correctly all the others modules (see discard_initial_modules).
On my setup this does not crash Xen, instead it happily hand the page to
the allocator which is not good. The difference in behavior may be because
on how the PDX is setup (I need to investigate that). So by luck, I have
a struct page_info backing the reserved-memory region. This does not
mean it is better :).
This regression was introduced by commit f60658c6ae "xen/arm: Stop
relocating Xen". Before hand, Xen was always relocated so the original
Xen was left untouched. The relocated version would always live in
non-reserved area.
On my setup, Xen was not in the reserved region area by default. I had
to modify the Device-Tree. I don't know how many platform are putting
Xen in /memreserve/ region. Amit, assuming the patch above works for you,
could you tell who created the /memreserve/?
Cheers,
--
Julien Grall
___
Xen-devel m
Re: [Xen-devel] [PATCH 1/2] x86: decouple xen alignment setting from EFI/non-EFI build
>>> On 18.03.19 at 15:57, wrote: > Introduce a new Kconfig option to pick the alignment for xen binary. > To retain original behaviour, the default pick for EFI build is 2M and > non-EFI build 4K. Is this a worthwhile step to take, considering that we mean to switch to 2M main section boundaries anyway? I realize it's still not necessarily clear how to get there without re-introducing the boot regression with syslinux that was observed back then, but perhaps time would better be spent there than into introducing configurability? (To be honest I don't recall whether it was determined that there was no way out of this dilemma, but it seems to me there would have been a plan.) > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -138,6 +138,32 @@ config TBOOT > > If unsure, say Y. > > +choice > + prompt "Alignment of Xen binary" > + depends on X86 > + default XEN_ALIGN_DEFAULT > + ---help--- > + Specify alignment for Xen binary. > + > + If unsure, choose "default". > + > +config XEN_ALIGN_DEFAULT > + bool "Default alignment" > + ---help--- > + Pick alignment according to build variants. > + > + For EFI build the default alignment is 2M. For non-EFI build > + the default alignment is 4K due to syslinux failing to handle > + 2M alignment. Wasn't it the resulting image size rather than the alignment itself which did cause the problem? Has the issue been fixed in newer syslinux? > +config XEN_ALIGN_4K > + bool "4K alignment" > + > +config XEN_ALIGN_2M > + bool "2M alignment" In patch 2 you only need the latter - is there really much value in allowing explicitly requesting 4k? > @@ -20,13 +19,26 @@ ENTRY(efi_start) > #else /* !EFI */ > > #define FORMAT "elf64-x86-64" > -#define SECTION_ALIGN PAGE_SIZE > #define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START) > > ENTRY(start_pa) > > #endif /* EFI */ > > +#if defined CONFIG_XEN_ALIGN_2M > +#define SECTION_ALIGN MB(2) > +#elif defined CONFIG_XEN_ALIGN_4K > +#define SECTION_ALIGN PAGE_SIZE > +#elif defined CONFIG_XEN_ALIGN_DEFAULT > +#ifdef EFI > +#define SECTION_ALIGN MB(2) > +#else > +#define SECTION_ALIGN PAGE_SIZE > +#endif > +#else > +#error "Section alignment undefined" > +#endif How about converting the last #elif to #else and omitting the #error? Also would you mind using the defined() style (i.e. with parentheses), as we commonly do elsewhere? And please use uniform indentation (or not) of directives. I also find the indentation itself quite unusual - we have almost no examples of it being like this outside of files we've imported from elsewhere. Typically we retain the # in column 1 and indent only the actual directive keyword. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86: decouple xen alignment setting from EFI/non-EFI build
On Tue, Mar 19, 2019 at 04:45:35AM -0600, Jan Beulich wrote: > >>> On 18.03.19 at 15:57, wrote: > > Introduce a new Kconfig option to pick the alignment for xen binary. > > To retain original behaviour, the default pick for EFI build is 2M and > > non-EFI build 4K. > > Is this a worthwhile step to take, considering that we mean to > switch to 2M main section boundaries anyway? I realize it's still not > necessarily clear how to get there without re-introducing the boot > regression with syslinux that was observed back then, but perhaps > time would better be spent there than into introducing configurability? > (To be honest I don't recall whether it was determined that there > was no way out of this dilemma, but it seems to me there would > have been a plan.) I think it would definitely be sensible to fix it there. But we still have older syslinux to deal with. I don't think they're going away any time soon. > > > --- a/xen/arch/x86/Kconfig > > +++ b/xen/arch/x86/Kconfig > > @@ -138,6 +138,32 @@ config TBOOT > > > > If unsure, say Y. > > > > +choice > > + prompt "Alignment of Xen binary" > > + depends on X86 > > + default XEN_ALIGN_DEFAULT > > + ---help--- > > + Specify alignment for Xen binary. > > + > > + If unsure, choose "default". > > + > > +config XEN_ALIGN_DEFAULT > > + bool "Default alignment" > > + ---help--- > > + Pick alignment according to build variants. > > + > > + For EFI build the default alignment is 2M. For non-EFI build > > + the default alignment is 4K due to syslinux failing to handle > > + 2M alignment. > > Wasn't it the resulting image size rather than the alignment itself > which did cause the problem? Has the issue been fixed in newer > syslinux? > Right. I can make this clearer. "due to syslinux failing to handle the image size increment induced by 2M alignment". Also, I think s/binary/image/ in the description would be better. Looking at syslinux.git I don't immediately see patches to fix the issue (if there is such issue in the first place). > > +config XEN_ALIGN_4K > > + bool "4K alignment" > > + > > +config XEN_ALIGN_2M > > + bool "2M alignment" > > In patch 2 you only need the latter - is there really much value in > allowing explicitly requesting 4k? > I thought there would be a case in which users want 4K explicitly? I'm certainly fine with dropping the 4K alignment option. > > @@ -20,13 +19,26 @@ ENTRY(efi_start) > > #else /* !EFI */ > > > > #define FORMAT "elf64-x86-64" > > -#define SECTION_ALIGN PAGE_SIZE > > #define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START) > > > > ENTRY(start_pa) > > > > #endif /* EFI */ > > > > +#if defined CONFIG_XEN_ALIGN_2M > > +#define SECTION_ALIGN MB(2) > > +#elif defined CONFIG_XEN_ALIGN_4K > > +#define SECTION_ALIGN PAGE_SIZE > > +#elif defined CONFIG_XEN_ALIGN_DEFAULT > > +#ifdef EFI > > +#define SECTION_ALIGN MB(2) > > +#else > > +#define SECTION_ALIGN PAGE_SIZE > > +#endif > > +#else > > +#error "Section alignment undefined" > > +#endif > > How about converting the last #elif to #else and omitting the > #error? Also would you mind using the defined() style (i.e. with > parentheses), as we commonly do elsewhere? And please use > uniform indentation (or not) of directives. I also find the > indentation itself quite unusual - we have almost no examples of > it being like this outside of files we've imported from elsewhere. > Typically we retain the # in column 1 and indent only the actual > directive keyword. Will fix (after we determine what to do with 4K option). Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU
On 2019/3/18 16:59, Jan Beulich wrote:
On 16.03.19 at 11:11, wrote:
On 2019/3/15 20:41, Jan Beulich wrote:
On 21.02.19 at 10:50, wrote:
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
switch ( current_cpu_data.x86 )
{
case 0x15:
+case 0x17:
+case 0x18:
num_counters = F15H_NUM_COUNTERS;
counters = AMD_F15H_COUNTERS;
ctrls = AMD_F15H_CTRLS;
Unless you know what AMD Fam18 will look like, you can't do it
like this. Fam18 really needs to be further qualified by a vendor
check at this point in time.
Hygon will negotiate with AMD to make sure that only Hygon should use
Fam18h.
In the success case of which please state this in the description.
Until those negotiations have succeeded I'm afraid I'm going to
insist to see the extra check added.
How to check vendor? Maybe like this:
case 0x15:
case 0x17:
case 0x18:
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
boot_cpu_data.x86 == 0x18)
return -EINVAL;
num_counters = F15H_NUM_COUNTERS;
counters = AMD_F15H_COUNTERS;
ctrls = AMD_F15H_CTRLS;
or just add Hygon support at beginning of amd_vpmu_init():
if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
num_counters = F15H_NUM_COUNTERS;
counters = AMD_F15H_COUNTERS;
ctrls = AMD_F15H_CTRLS;
k7_counters_mirrored = 1;
}
--
Regards,
Pu Wen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 10/11] viridian: add implementation of synthetic timers
>>> On 19.03.19 at 10:21, wrote:
> +static void poll_stimer(struct vcpu *v, unsigned int stimerx)
> +{
> +struct viridian_vcpu *vv = v->arch.hvm.viridian;
> +struct viridian_stimer *vs = &vv->stimer[stimerx];
> +
> +/*
> + * Timer expiry may race with the timer being disabled. If the timer
> + * is disabled make sure the pending bit is cleared to avoid re-
> + * polling.
> + */
> +if ( !vs->config.enabled )
> +{
> +clear_bit(stimerx, &vv->stimer_pending);
> +return;
> +}
It feels a little odd to squash an already pending event like this,
but I think I see why you want/need it this way. Of course the
question is whether an MSR write (turning the enabled bit off)
after the timer has expired should cancel the sending of a
notification message. I could imagine this not even being spelled
out anywhere in the spec...
> +if ( !test_bit(stimerx, &vv->stimer_pending) )
> +return;
> +
> +if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx,
> + stimerx, vs->expiration,
> + time_now(v->domain)) )
> +return;
> +
> +clear_bit(stimerx, &vv->stimer_pending);
> +
> +if ( vs->config.periodic )
> +start_stimer(vs);
> +else
> +vs->config.enabled = 0;
In v8 you started the timer here when config.enabled is true. Was
that with the implicit assumption that the bit would still have been
off from stimer_expire() for non-periodic timers? If so, the above
would indeed be a sufficiently close equivalent, while if not I would
be a little confused by this construct.
Is clearing the enabled bit appropriate here? stimer_expire() and
this function are asynchronous with one another, i.e. there's a
window where the guest may write the MSR again (with the enabled
bit set) after stimer_expire() has run but before we make it here. I
think the overall outcome is fine, but wouldn't start_stimer() better
clear the enabled bit right away after having called stimer_expire()?
Or wait - doing so would conflict with the enabled bit check at the
top of this function. Otoh an MSR read immediately following such
an MSR write should observe the enabled bit clear for a non-periodic
timer that was set in the past, shouldn't it? So perhaps a set
pending bit should result in the RDMSR handling to clear the enabled
bit in the returned value for a non-periodic timer?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-snapshot test] 83751: trouble: blocked/broken
flight 83751 distros-debian-snapshot real [real] http://osstest.xensource.com/osstest/logs/83751/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i386 broken build-amd64-pvopsbroken build-armhf broken build-amd64 broken build-i386-pvops broken build-armhf-pvops 3 syslog-serverrunning build-armhf 3 syslog-serverrunning Tests which did not succeed, but are not blocking: test-amd64-amd64-i386-daily-netboot-pygrub 1 build-check(1) blocked n/a test-armhf-armhf-armhf-daily-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-i386-i386-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-current-netinst-pygrub 1 build-check(1)blocked n/a test-amd64-i386-amd64-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-daily-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-i386-daily-netboot-pvgrub 1 build-check(1)blocked n/a test-amd64-i386-i386-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-daily-netboot-pygrub 1 build-check(1) blocked n/a build-armhf-pvops 4 host-install(4) broken like 83704 build-armhf 4 host-install(4) broken like 83704 build-i3864 host-install(4) broken like 83704 build-i386-pvops 4 host-install(4) broken like 83704 build-amd64-pvops 4 host-install(4) broken like 83704 build-amd64 4 host-install(4) broken like 83704 build-armhf 5 capture-logs broken like 83704 build-armhf-pvops 5 capture-logs broken like 83704 baseline version: flight 83704 jobs: build-amd64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-daily-netboot-pvgrub blocked test-amd64-i386-i386-daily-netboot-pvgrubblocked test-amd64-i386-amd64-daily-netboot-pygrub blocked test-armhf-armhf-armhf-daily-netboot-pygrub blocked test-amd64-amd64-i386-daily-netboot-pygrub blocked test-amd64-amd64-amd64-current-netinst-pygrubblocked test-amd64-i386-amd64-current-netinst-pygrub blocked test-amd64-amd64-i386-current-netinst-pygrub blocked test-amd64-i386-i386-current-netinst-pygrub blocked test-amd64-amd64-amd64-weekly-netinst-pygrub blocked test-amd64-i386-amd64-weekly-netinst-pygrub blocked test-amd64-amd64-i386-weekly-netinst-pygrub blocked test-amd64-i386-i386-weekly-netinst-pygrub blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 01/14] x86/cpu: Create Hygon Dhyana architecture support file
On 2019/3/18 16:55, Jan Beulich wrote: > On 16.03.19 at 10:57, wrote: >> On 2019/3/15 19:18, Jan Beulich wrote: >>> On 15.03.19 at 11:17, wrote: On 2019/3/15 1:11, Jan Beulich wrote: > This is a lot of duplicated code with only minor differences. I think > you would be better off calling into the AMD original functions. These functions and AMD original ones are static. So Hygon cannot directly call into them. Or we can put them into the common cpu code, but I think it's not good for future maintenance. >>> Just make non-static what needs to be, add an amd_ prefix, and >>> call it from your code. >> That's OK. With this method only init_levelling in amd.c should be added >> an amd_ prefix and called by hygon.c. >> But I'm afraid Hygon should have its own init functions and not call the >> AMD ones. The current Hygon init functions have been heavily stripped >> from the original AMD's. > Let me give you this rule of thumb (subject to discussion): If you can > safely re-use any non-trivial current AMD function with at most minor > adjustments (and irrespective of certain code there being unreachable > on Hygon), then I think it would be better to re-use it than to duplicate > it. I tried, but it will add 0x18 to init_amd(). It's strange because AMD does not have family 18h now. So it becomes unwieldy to maintain init_amd() just at this time. The same situation for amd_get_topology(). So I think it's better to carve out init_hygon() and hygon_get_topology() (which also need Hygon's own adjustment for computing phys_proc_id). I think it's time to develop a new patch series for your review. -- Regards, Pu Wen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 10/11] viridian: add implementation of synthetic timers
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 March 2019 12:18
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Roger Pau Monne
> ; Wei Liu ; George Dunlap
> ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel de...@lists.xenproject.org>; Konrad Rzeszutek Wilk ;
> Tim (Xen.org)
>
> Subject: Re: [PATCH v9 10/11] viridian: add implementation of synthetic timers
>
> >>> On 19.03.19 at 10:21, wrote:
> > +static void poll_stimer(struct vcpu *v, unsigned int stimerx)
> > +{
> > +struct viridian_vcpu *vv = v->arch.hvm.viridian;
> > +struct viridian_stimer *vs = &vv->stimer[stimerx];
> > +
> > +/*
> > + * Timer expiry may race with the timer being disabled. If the timer
> > + * is disabled make sure the pending bit is cleared to avoid re-
> > + * polling.
> > + */
> > +if ( !vs->config.enabled )
> > +{
> > +clear_bit(stimerx, &vv->stimer_pending);
> > +return;
> > +}
>
> It feels a little odd to squash an already pending event like this,
> but I think I see why you want/need it this way. Of course the
> question is whether an MSR write (turning the enabled bit off)
> after the timer has expired should cancel the sending of a
> notification message. I could imagine this not even being spelled
> out anywhere in the spec...
No, it's not but it seems like the right thing to do.
>
> > +if ( !test_bit(stimerx, &vv->stimer_pending) )
> > +return;
> > +
> > +if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx,
> > + stimerx, vs->expiration,
> > + time_now(v->domain)) )
> > +return;
> > +
> > +clear_bit(stimerx, &vv->stimer_pending);
> > +
> > +if ( vs->config.periodic )
> > +start_stimer(vs);
> > +else
> > +vs->config.enabled = 0;
>
> In v8 you started the timer here when config.enabled is true. Was
> that with the implicit assumption that the bit would still have been
> off from stimer_expire() for non-periodic timers? If so, the above
> would indeed be a sufficiently close equivalent, while if not I would
> be a little confused by this construct.
This should be a reversion to the v7 construct. The expiration function no
longer updates the config so the poll clears the enable bit for single-shot
timers instead whereas periodic times stay enabled (until an MSR write disables
them) and get re-scheduled.
>
> Is clearing the enabled bit appropriate here? stimer_expire() and
> this function are asynchronous with one another, i.e. there's a
> window where the guest may write the MSR again (with the enabled
> bit set) after stimer_expire() has run but before we make it here.
> I think the overall outcome is fine, but wouldn't start_stimer() better
> clear the enabled bit right away after having called stimer_expire()?
> Or wait - doing so would conflict with the enabled bit check at the
> top of this function. Otoh an MSR read immediately following such
> an MSR write should observe the enabled bit clear for a non-periodic
> timer that was set in the past, shouldn't it?
I'm not sure about that because it's not clear when the timer expires as such.
The spec is not clear whether timer expiry means the point when it times out or
when the message is delivered.
> So perhaps a set
> pending bit should result in the RDMSR handling to clear the enabled
> bit in the returned value for a non-periodic timer?
I get tied in knots every time I think about this and without waiting for a
pending timer to stop when it is disabled I see no way of the race, but I think
doing that would be prohibitively slow because windows seems to flip between
single-shot and periodic timers on quite a frequent basis. At this point I'd
prefer to leave the code as-is and run some tests. We've already had a prior
incarnation running in XenServer automated tests for several weeks with no
discovered problems.
Paul
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86: decouple xen alignment setting from EFI/non-EFI build
>>> On 19.03.19 at 12:24, wrote: > On Tue, Mar 19, 2019 at 04:45:35AM -0600, Jan Beulich wrote: >> >>> On 18.03.19 at 15:57, wrote: >> > --- a/xen/arch/x86/Kconfig >> > +++ b/xen/arch/x86/Kconfig >> > @@ -138,6 +138,32 @@ config TBOOT >> > >> > If unsure, say Y. >> > >> > +choice >> > + prompt "Alignment of Xen binary" >> > + depends on X86 >> > + default XEN_ALIGN_DEFAULT >> > + ---help--- >> > +Specify alignment for Xen binary. >> > + >> > +If unsure, choose "default". >> > + >> > +config XEN_ALIGN_DEFAULT >> > + bool "Default alignment" >> > + ---help--- >> > +Pick alignment according to build variants. >> > + >> > +For EFI build the default alignment is 2M. For non-EFI build >> > +the default alignment is 4K due to syslinux failing to handle >> > +2M alignment. >> >> Wasn't it the resulting image size rather than the alignment itself >> which did cause the problem? Has the issue been fixed in newer >> syslinux? >> > > Right. I can make this clearer. > > "due to syslinux failing to handle the image size increment induced by > 2M alignment". > > Also, I think s/binary/image/ in the description would be better. Agreed. >> > +config XEN_ALIGN_4K >> > + bool "4K alignment" >> > + >> > +config XEN_ALIGN_2M >> > + bool "2M alignment" >> >> In patch 2 you only need the latter - is there really much value in >> allowing explicitly requesting 4k? > > I thought there would be a case in which users want 4K explicitly? I'm > certainly fine with dropping the 4K alignment option. Well, without a specific need or request I'd prefer not to see extra options introduced. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU
>>> On 19.03.19 at 12:32, wrote:
> On 2019/3/18 16:59, Jan Beulich wrote:
> On 16.03.19 at 11:11, wrote:
>>> On 2019/3/15 20:41, Jan Beulich wrote:
>>> On 21.02.19 at 10:50, wrote:
> --- a/xen/arch/x86/cpu/vpmu_amd.c
> +++ b/xen/arch/x86/cpu/vpmu_amd.c
> @@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
>switch ( current_cpu_data.x86 )
>{
>case 0x15:
> +case 0x17:
> +case 0x18:
>num_counters = F15H_NUM_COUNTERS;
>counters = AMD_F15H_COUNTERS;
>ctrls = AMD_F15H_CTRLS;
Unless you know what AMD Fam18 will look like, you can't do it
like this. Fam18 really needs to be further qualified by a vendor
check at this point in time.
>>>
>>> Hygon will negotiate with AMD to make sure that only Hygon should use
>>> Fam18h.
>>
>> In the success case of which please state this in the description.
>> Until those negotiations have succeeded I'm afraid I'm going to
>> insist to see the extra check added.
>
> How to check vendor? Maybe like this:
> case 0x15:
> case 0x17:
> case 0x18:
> if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
> boot_cpu_data.x86 == 0x18)
> return -EINVAL;
>
> num_counters = F15H_NUM_COUNTERS;
> counters = AMD_F15H_COUNTERS;
> ctrls = AMD_F15H_CTRLS;
>
> or just add Hygon support at beginning of amd_vpmu_init():
> if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
> num_counters = F15H_NUM_COUNTERS;
> counters = AMD_F15H_COUNTERS;
> ctrls = AMD_F15H_CTRLS;
> k7_counters_mirrored = 1;
> }
A suitable variant of the latter or
int __init amd_vpmu_init(void)
{
unsigned int i, fam = current_cpu_data.x86
/* */
if ( current_cpu_data.x86_vendor == X86_VENDOR_HYGON && fam == 0x18 )
fam = 0x17;
switch ( fam )
...
or perhaps even better would be two separate switch()-es, one for
AMD and one for Hygon. Possibly even a separate hygon_vpmu_init().
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 01/14] x86/cpu: Create Hygon Dhyana architecture support file
>>> On 19.03.19 at 13:33, wrote: > On 2019/3/18 16:55, Jan Beulich wrote: >> On 16.03.19 at 10:57, wrote: >>> On 2019/3/15 19:18, Jan Beulich wrote: On 15.03.19 at 11:17, wrote: > On 2019/3/15 1:11, Jan Beulich wrote: >> This is a lot of duplicated code with only minor differences. I think >> you would be better off calling into the AMD original functions. > These functions and AMD original ones are static. So Hygon cannot directly > call into them. Or we can put them into the common cpu code, but I think > it's not good for future maintenance. Just make non-static what needs to be, add an amd_ prefix, and call it from your code. >>> That's OK. With this method only init_levelling in amd.c should be added >>> an amd_ prefix and called by hygon.c. >>> But I'm afraid Hygon should have its own init functions and not call the >>> AMD ones. The current Hygon init functions have been heavily stripped >>> from the original AMD's. >> Let me give you this rule of thumb (subject to discussion): If you can >> safely re-use any non-trivial current AMD function with at most minor >> adjustments (and irrespective of certain code there being unreachable >> on Hygon), then I think it would be better to re-use it than to duplicate >> it. > > I tried, but it will add 0x18 to init_amd(). It's strange because AMD > does not have family 18h now. So it becomes unwieldy to maintain > init_amd() just at this time. The same situation for amd_get_topology(). > > So I think it's better to carve out init_hygon() and hygon_get_topology() > (which also need Hygon's own adjustment for computing phys_proc_id). Just to be clear: I've never objected to a separate init_hygon(). For amd_get_topology() it's less clear: It looks to me as if you wouldn't need to add any Hygon conditionals to the function, as long as cpu_has(c, X86_FEATURE_TOPOEXT) is true in your case. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/2] x86: more flexible alignment handling for xen image
Wei Liu (2): x86: decouple xen alignment setting from EFI/ELF build x86/pvshim: use 2M alignment xen/arch/x86/Kconfig | 23 +++ xen/arch/x86/configs/pvshim_defconfig | 1 + xen/arch/x86/xen.lds.S| 12 ++-- 3 files changed, 34 insertions(+), 2 deletions(-) -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/2] x86/pvshim: use 2M alignment
The pvshim is loaded directly by toolstack. Use 2M alignment for potentially better performance. Signed-off-by: Wei Liu --- xen/arch/x86/configs/pvshim_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/configs/pvshim_defconfig b/xen/arch/x86/configs/pvshim_defconfig index a12e3d0465..8e50b60cda 100644 --- a/xen/arch/x86/configs/pvshim_defconfig +++ b/xen/arch/x86/configs/pvshim_defconfig @@ -5,6 +5,7 @@ CONFIG_PVH_GUEST=y CONFIG_PV_SHIM=y CONFIG_PV_SHIM_EXCLUSIVE=y CONFIG_NR_CPUS=32 +CONFIG_XEN_ALIGN_2M=y # Disable features not used by the PV shim # CONFIG_SHADOW_PAGING is not set # CONFIG_BIGMEM is not set -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 1/2] x86: decouple xen alignment setting from EFI/ELF build
Introduce a new Kconfig option to pick the alignment for xen binary. To retain original behaviour, the default pick for EFI build is 2M and ELF build 4K. Signed-off-by: Wei Liu --- xen/arch/x86/Kconfig | 23 +++ xen/arch/x86/xen.lds.S | 12 ++-- 2 files changed, 33 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 5c2d1070b6..1f115c1e40 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -138,6 +138,29 @@ config TBOOT If unsure, say Y. +choice + prompt "Alignment of Xen image" + depends on X86 + default XEN_ALIGN_DEFAULT + ---help--- + Specify alignment for Xen image. + + If unsure, choose "default". + +config XEN_ALIGN_DEFAULT + bool "Default alignment" + ---help--- + Pick alignment according to build variants. + + For EFI build the default alignment is 2M. For ELF build + the default alignment is 4K due to syslinux failing to handle + the increment of image size induced by 2M alignment. + +config XEN_ALIGN_2M + bool "2M alignment" + +endchoice + config XEN_GUEST def_bool n prompt "Xen Guest" diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S index 6e9bda5109..5a0c1004f5 100644 --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -12,7 +12,6 @@ #define FORMAT "pei-x86-64" #undef __XEN_VIRT_START #define __XEN_VIRT_START __image_base__ -#define SECTION_ALIGN MB(2) #define DECL_SECTION(x) x : ENTRY(efi_start) @@ -20,13 +19,22 @@ ENTRY(efi_start) #else /* !EFI */ #define FORMAT "elf64-x86-64" -#define SECTION_ALIGN PAGE_SIZE #define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START) ENTRY(start_pa) #endif /* EFI */ +#ifdef CONFIG_XEN_ALIGN_2M +#define SECTION_ALIGN MB(2) +#else /* Default alignment */ +#ifdef EFI +#define SECTION_ALIGN MB(2) +#else +#define SECTION_ALIGN PAGE_SIZE +#endif +#endif + OUTPUT_FORMAT(FORMAT, FORMAT, FORMAT) OUTPUT_ARCH(i386:x86-64) -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86: decouple xen alignment setting from EFI/ELF build
On 19/03/2019 13:05, Wei Liu wrote: > @@ -20,13 +19,22 @@ ENTRY(efi_start) > #else /* !EFI */ > > #define FORMAT "elf64-x86-64" > -#define SECTION_ALIGN PAGE_SIZE > #define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START) > > ENTRY(start_pa) > > #endif /* EFI */ > > +#ifdef CONFIG_XEN_ALIGN_2M > +#define SECTION_ALIGN MB(2) > +#else /* Default alignment */ > +#ifdef EFI > +#define SECTION_ALIGN MB(2) > +#else > +#define SECTION_ALIGN PAGE_SIZE > +#endif > +#endif As a trivial change, can this please be: #ifdef CONFIG_XEN_ALIGN_2M # define SECTION_ALIGN MB(2) #else /* Default alignment */ # ifdef EFI # define SECTION_ALIGN MB(2) # else # define SECTION_ALIGN PAGE_SIZE # endif #endif To help highlight the nesting levels. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 10/11] viridian: add implementation of synthetic timers
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Paul Durrant
> Sent: 19 March 2019 12:47
> To: 'Jan Beulich'
> Cc: Stefano Stabellini ; Wei Liu
> ; Konrad Rzeszutek Wilk
> ; Andrew Cooper ; Tim
> (Xen.org) ;
> George Dunlap ; Julien Grall
> ; xen-devel de...@lists.xenproject.org>; Ian Jackson ; Roger Pau
> Monne
>
> Subject: Re: [Xen-devel] [PATCH v9 10/11] viridian: add implementation of
> synthetic timers
>
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 19 March 2019 12:18
> > To: Paul Durrant
> > Cc: Julien Grall ; Andrew Cooper
> > ; Roger Pau Monne
> > ; Wei Liu ; George Dunlap
> > ; Ian
> > Jackson ; Stefano Stabellini
> > ; xen-devel > de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> > ; Tim (Xen.org)
> >
> > Subject: Re: [PATCH v9 10/11] viridian: add implementation of synthetic
> > timers
> >
> > >>> On 19.03.19 at 10:21, wrote:
> > > +static void poll_stimer(struct vcpu *v, unsigned int stimerx)
> > > +{
> > > +struct viridian_vcpu *vv = v->arch.hvm.viridian;
> > > +struct viridian_stimer *vs = &vv->stimer[stimerx];
> > > +
> > > +/*
> > > + * Timer expiry may race with the timer being disabled. If the timer
> > > + * is disabled make sure the pending bit is cleared to avoid re-
> > > + * polling.
> > > + */
> > > +if ( !vs->config.enabled )
> > > +{
> > > +clear_bit(stimerx, &vv->stimer_pending);
> > > +return;
> > > +}
> >
> > It feels a little odd to squash an already pending event like this,
> > but I think I see why you want/need it this way. Of course the
> > question is whether an MSR write (turning the enabled bit off)
> > after the timer has expired should cancel the sending of a
> > notification message. I could imagine this not even being spelled
> > out anywhere in the spec...
>
> No, it's not but it seems like the right thing to do.
>
> >
> > > +if ( !test_bit(stimerx, &vv->stimer_pending) )
> > > +return;
> > > +
> > > +if ( !viridian_synic_deliver_timer_msg(v, vs->config.sintx,
> > > + stimerx, vs->expiration,
> > > + time_now(v->domain)) )
> > > +return;
> > > +
> > > +clear_bit(stimerx, &vv->stimer_pending);
> > > +
> > > +if ( vs->config.periodic )
> > > +start_stimer(vs);
> > > +else
> > > +vs->config.enabled = 0;
> >
> > In v8 you started the timer here when config.enabled is true. Was
> > that with the implicit assumption that the bit would still have been
> > off from stimer_expire() for non-periodic timers? If so, the above
> > would indeed be a sufficiently close equivalent, while if not I would
> > be a little confused by this construct.
>
> This should be a reversion to the v7 construct. The expiration function no
> longer updates the config
> so the poll clears the enable bit for single-shot timers instead whereas
> periodic times stay enabled
> (until an MSR write disables them) and get re-scheduled.
>
> >
> > Is clearing the enabled bit appropriate here? stimer_expire() and
> > this function are asynchronous with one another, i.e. there's a
> > window where the guest may write the MSR again (with the enabled
> > bit set) after stimer_expire() has run but before we make it here.
> > I think the overall outcome is fine, but wouldn't start_stimer() better
> > clear the enabled bit right away after having called stimer_expire()?
> > Or wait - doing so would conflict with the enabled bit check at the
> > top of this function. Otoh an MSR read immediately following such
> > an MSR write should observe the enabled bit clear for a non-periodic
> > timer that was set in the past, shouldn't it?
>
> I'm not sure about that because it's not clear when the timer expires as
> such. The spec is not clear
> whether timer expiry means the point when it times out or when the message is
> delivered.
>
> > So perhaps a set
> > pending bit should result in the RDMSR handling to clear the enabled
> > bit in the returned value for a non-periodic timer?
>
> I get tied in knots every time I think about this and without waiting for a
> pending timer to stop when
> it is disabled I see no way of the race, but I think doing that would be
> prohibitively slow because
^ avoiding
> windows seems to flip between single-shot and periodic timers on quite a
> frequent basis. At this point
> I'd prefer to leave the code as-is and run some tests. We've already had a
> prior incarnation running
> in XenServer automated tests for several weeks with no discovered problems.
>
> Paul
>
> >
> > Jan
> >
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen
Re: [Xen-devel] [PATCH v9 10/11] viridian: add implementation of synthetic timers
>>> On 19.03.19 at 13:47, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 19 March 2019 12:18
>>
>> So perhaps a set
>> pending bit should result in the RDMSR handling to clear the enabled
>> bit in the returned value for a non-periodic timer?
>
> I get tied in knots every time I think about this and without waiting for a
> pending timer to stop when it is disabled I see no way of the race, but I
> think doing that would be prohibitively slow because windows seems to flip
> between single-shot and periodic timers on quite a frequent basis.
I'm afraid I don't understand: Why a timer or any other complications.
All I'm thinking about is
case HV_X64_MSR_STIMER0_CONFIG:
case HV_X64_MSR_STIMER1_CONFIG:
case HV_X64_MSR_STIMER2_CONFIG:
case HV_X64_MSR_STIMER3_CONFIG:
{
unsigned int stimerx = (idx - HV_X64_MSR_STIMER0_CONFIG) / 2;
const struct viridian_stimer *vs =
&array_access_nospec(vv->stimer, stimerx);
if ( !(viridian_feature_mask(d) & HVMPV_stimer) )
return X86EMUL_EXCEPTION;
*val = vs->config.raw;
if ( !vs->config.periodic && test_bit(stimerx, vv->stimer_pending) )
*val &= ~1;
break;
}
or a suitable equivalent to avoid the literal 1, plus perhaps a
helpful comment.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-next test] 133897: regressions - FAIL
flight 133897 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/133897/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 10 freebsd-install fail REGR. vs. 133829 Tests which did not succeed, but are not blocking: test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail blocked in 133829 test-armhf-armhf-libvirt 14 saverestore-support-check fail blocked in 133829 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail blocked in 133829 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail like 133829 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133829 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133829 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133829 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 133829 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 133829 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 133829 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133829 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-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-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linuxb9998194591467dc562c23ecefb63af4eff7530b baseline version: linuxf261c4e529dac5608a604d3dd3ae1cd2adf23c89 Last test of basis (not found) Failing since (not found) Testing same since 133897 2019-03-18 09:19:04 Z1 days1 attempts j
Re: [Xen-devel] [PATCH v2 01/14] x86/cpu: Create Hygon Dhyana architecture support file
On 2019/3/19 21:02, Jan Beulich wrote: > On 19.03.19 at 13:33, wrote: >> On 2019/3/18 16:55, Jan Beulich wrote: >>> On 16.03.19 at 10:57, wrote: On 2019/3/15 19:18, Jan Beulich wrote: > On 15.03.19 at 11:17, wrote: >> On 2019/3/15 1:11, Jan Beulich wrote: >>> This is a lot of duplicated code with only minor differences. I think >>> you would be better off calling into the AMD original functions. >> These functions and AMD original ones are static. So Hygon cannot >> directly >> call into them. Or we can put them into the common cpu code, but I think >> it's not good for future maintenance. > Just make non-static what needs to be, add an amd_ prefix, and > call it from your code. That's OK. With this method only init_levelling in amd.c should be added an amd_ prefix and called by hygon.c. But I'm afraid Hygon should have its own init functions and not call the AMD ones. The current Hygon init functions have been heavily stripped from the original AMD's. >>> Let me give you this rule of thumb (subject to discussion): If you can >>> safely re-use any non-trivial current AMD function with at most minor >>> adjustments (and irrespective of certain code there being unreachable >>> on Hygon), then I think it would be better to re-use it than to duplicate >>> it. >> >> I tried, but it will add 0x18 to init_amd(). It's strange because AMD >> does not have family 18h now. So it becomes unwieldy to maintain >> init_amd() just at this time. The same situation for amd_get_topology(). >> >> So I think it's better to carve out init_hygon() and hygon_get_topology() >> (which also need Hygon's own adjustment for computing phys_proc_id). > > Just to be clear: I've never objected to a separate init_hygon(). > For amd_get_topology() it's less clear: It looks to me as if you > wouldn't need to add any Hygon conditionals to the function, as > long as cpu_has(c, X86_FEATURE_TOPOEXT) is true in your case. Yes, it's no need to add Hygon conditional to amd_get_topology() as >=0x17 conditionals are default supported. -- Regards, Pu Wen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86: decouple xen alignment setting from EFI/ELF build
>>> On 19.03.19 at 14:09, wrote: > On 19/03/2019 13:05, Wei Liu wrote: >> @@ -20,13 +19,22 @@ ENTRY(efi_start) >> #else /* !EFI */ >> >> #define FORMAT "elf64-x86-64" >> -#define SECTION_ALIGN PAGE_SIZE >> #define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START) >> >> ENTRY(start_pa) >> >> #endif /* EFI */ >> >> +#ifdef CONFIG_XEN_ALIGN_2M >> +#define SECTION_ALIGN MB(2) >> +#else /* Default alignment */ >> +#ifdef EFI >> +#define SECTION_ALIGN MB(2) >> +#else >> +#define SECTION_ALIGN PAGE_SIZE >> +#endif >> +#endif > > As a trivial change, can this please be: > > #ifdef CONFIG_XEN_ALIGN_2M > # define SECTION_ALIGN MB(2) > #else /* Default alignment */ > # ifdef EFI > # define SECTION_ALIGN MB(2) > # else > # define SECTION_ALIGN PAGE_SIZE > # endif > #endif > > To help highlight the nesting levels. #if defined(CONFIG_XEN_ALIGN_2M) || defined(EFI) # define SECTION_ALIGN MB(2) #else # define SECTION_ALIGN PAGE_SIZE #endif ? Then Reviewed-by: Jan Beulich (but I can live with Andrew's variant too, if need be) Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/pvshim: use 2M alignment
>>> On 19.03.19 at 14:05, wrote: > --- a/xen/arch/x86/configs/pvshim_defconfig > +++ b/xen/arch/x86/configs/pvshim_defconfig > @@ -5,6 +5,7 @@ CONFIG_PVH_GUEST=y > CONFIG_PV_SHIM=y > CONFIG_PV_SHIM_EXCLUSIVE=y > CONFIG_NR_CPUS=32 > +CONFIG_XEN_ALIGN_2M=y > # Disable features not used by the PV shim > # CONFIG_SHADOW_PAGING is not set > # CONFIG_BIGMEM is not set Instead of this, why not add default XEN_ALIGN_2M if PV_SHIM_EXCLUSIVE to the config option itself, ahead of the default patch 1 establishes? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86: decouple xen alignment setting from EFI/ELF build
>>> On 19.03.19 at 14:05, wrote: > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -138,6 +138,29 @@ config TBOOT > > If unsure, say Y. > > +choice > + prompt "Alignment of Xen image" > + depends on X86 Sorry, noticed only while looking at patch 2 again: This line seems unnecessary, considering the file we're in. I notice TBOOT has a similar pointless dependency. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86: decouple xen alignment setting from EFI/ELF build
On Tue, Mar 19, 2019 at 01:09:35PM +, Andrew Cooper wrote: > On 19/03/2019 13:05, Wei Liu wrote: > > @@ -20,13 +19,22 @@ ENTRY(efi_start) > > #else /* !EFI */ > > > > #define FORMAT "elf64-x86-64" > > -#define SECTION_ALIGN PAGE_SIZE > > #define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START) > > > > ENTRY(start_pa) > > > > #endif /* EFI */ > > > > +#ifdef CONFIG_XEN_ALIGN_2M > > +#define SECTION_ALIGN MB(2) > > +#else /* Default alignment */ > > +#ifdef EFI > > +#define SECTION_ALIGN MB(2) > > +#else > > +#define SECTION_ALIGN PAGE_SIZE > > +#endif > > +#endif > > As a trivial change, can this please be: > > #ifdef CONFIG_XEN_ALIGN_2M > # define SECTION_ALIGN MB(2) > #else /* Default alignment */ > # ifdef EFI > # define SECTION_ALIGN MB(2) > # else > # define SECTION_ALIGN PAGE_SIZE > # endif > #endif > > To help highlight the nesting levels. Sure. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/pvshim: use 2M alignment
On Tue, Mar 19, 2019 at 07:42:56AM -0600, Jan Beulich wrote: > >>> On 19.03.19 at 14:05, wrote: > > --- a/xen/arch/x86/configs/pvshim_defconfig > > +++ b/xen/arch/x86/configs/pvshim_defconfig > > @@ -5,6 +5,7 @@ CONFIG_PVH_GUEST=y > > CONFIG_PV_SHIM=y > > CONFIG_PV_SHIM_EXCLUSIVE=y > > CONFIG_NR_CPUS=32 > > +CONFIG_XEN_ALIGN_2M=y > > # Disable features not used by the PV shim > > # CONFIG_SHADOW_PAGING is not set > > # CONFIG_BIGMEM is not set > > Instead of this, why not add > > default XEN_ALIGN_2M if PV_SHIM_EXCLUSIVE > > to the config option itself, ahead of the default patch 1 establishes? This seems to work -- I didn't know you can have two default's for the same option. Wei. > > Jan > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v9 10/11] viridian: add implementation of synthetic timers
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 March 2019 13:32
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Wei Liu ; Stefano Stabellini
> ;
> xen-devel ; Konrad Rzeszutek Wilk
> ; Tim
> (Xen.org)
> Subject: RE: [PATCH v9 10/11] viridian: add implementation of synthetic timers
>
> >>> On 19.03.19 at 13:47, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 19 March 2019 12:18
> >>
> >> So perhaps a set
> >> pending bit should result in the RDMSR handling to clear the enabled
> >> bit in the returned value for a non-periodic timer?
> >
> > I get tied in knots every time I think about this and without waiting for a
> > pending timer to stop when it is disabled I see no way of the race, but I
> > think doing that would be prohibitively slow because windows seems to flip
> > between single-shot and periodic timers on quite a frequent basis.
>
> I'm afraid I don't understand: Why a timer or any other complications.
> All I'm thinking about is
>
> case HV_X64_MSR_STIMER0_CONFIG:
> case HV_X64_MSR_STIMER1_CONFIG:
> case HV_X64_MSR_STIMER2_CONFIG:
> case HV_X64_MSR_STIMER3_CONFIG:
> {
> unsigned int stimerx = (idx - HV_X64_MSR_STIMER0_CONFIG) / 2;
> const struct viridian_stimer *vs =
> &array_access_nospec(vv->stimer, stimerx);
>
> if ( !(viridian_feature_mask(d) & HVMPV_stimer) )
> return X86EMUL_EXCEPTION;
>
> *val = vs->config.raw;
> if ( !vs->config.periodic && test_bit(stimerx, vv->stimer_pending) )
> *val &= ~1;
> break;
> }
>
> or a suitable equivalent to avoid the literal 1, plus perhaps a
> helpful comment.
Ok. That shouldn't hurt. I'll avoid the literal 1 as you suggest and test an
equivalent.
Paul
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU
On 2019/3/19 20:58, Jan Beulich wrote:
> On 19.03.19 at 12:32, wrote:
>> On 2019/3/18 16:59, Jan Beulich wrote:
>>> On 16.03.19 at 11:11, wrote:
On 2019/3/15 20:41, Jan Beulich wrote:
> On 21.02.19 at 10:50, wrote:
>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>> @@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
>> switch ( current_cpu_data.x86 )
>> {
>> case 0x15:
>> +case 0x17:
>> +case 0x18:
>> num_counters = F15H_NUM_COUNTERS;
>> counters = AMD_F15H_COUNTERS;
>> ctrls = AMD_F15H_CTRLS;
>
> Unless you know what AMD Fam18 will look like, you can't do it
> like this. Fam18 really needs to be further qualified by a vendor
> check at this point in time.
Hygon will negotiate with AMD to make sure that only Hygon should use
Fam18h.
>>>
>>> In the success case of which please state this in the description.
>>> Until those negotiations have succeeded I'm afraid I'm going to
>>> insist to see the extra check added.
>>
>> How to check vendor? Maybe like this:
>> case 0x15:
>> case 0x17:
>> case 0x18:
>> if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
>> boot_cpu_data.x86 == 0x18)
>> return -EINVAL;
>>
>> num_counters = F15H_NUM_COUNTERS;
>> counters = AMD_F15H_COUNTERS;
>> ctrls = AMD_F15H_CTRLS;
>>
>> or just add Hygon support at beginning of amd_vpmu_init():
>> if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
>> num_counters = F15H_NUM_COUNTERS;
>> counters = AMD_F15H_COUNTERS;
>> ctrls = AMD_F15H_CTRLS;
>> k7_counters_mirrored = 1;
>> }
>
> A suitable variant of the latter or
>
> int __init amd_vpmu_init(void)
> {
> unsigned int i, fam = current_cpu_data.x86
>
> /* */
> if ( current_cpu_data.x86_vendor == X86_VENDOR_HYGON && fam == 0x18 )
> fam = 0x17;
This is the minimum change, I think it's better.
>
> switch ( fam )
> ...
>
> or perhaps even better would be two separate switch()-es, one for
> AMD and one for Hygon. Possibly even a separate hygon_vpmu_init().
A separate hygon_vpmu_init() is also fine except that the last part of
the function can be shared.
--
Regards,
Pu Wen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86: decouple xen alignment setting from EFI/ELF build
On Tue, Mar 19, 2019 at 07:44:33AM -0600, Jan Beulich wrote: > >>> On 19.03.19 at 14:05, wrote: > > --- a/xen/arch/x86/Kconfig > > +++ b/xen/arch/x86/Kconfig > > @@ -138,6 +138,29 @@ config TBOOT > > > > If unsure, say Y. > > > > +choice > > + prompt "Alignment of Xen image" > > + depends on X86 > > Sorry, noticed only while looking at patch 2 again: This line seems > unnecessary, considering the file we're in. I notice TBOOT has a > similar pointless dependency. Will fix -- I added this dep after looking at TBOOT. :p Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3] x86: decouple xen alignment setting from EFI/ELF build
Introduce a new Kconfig option to pick the alignment for xen binary. To retain original behaviour, the default pick for EFI build is 2M and ELF build 4K. Make the PVHSHIM build use 2M alignment for potentially better performance. Signed-off-by: Wei Liu --- xen/arch/x86/Kconfig | 23 +++ xen/arch/x86/xen.lds.S | 8 ++-- 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 5c2d1070b6..cb068faa6a 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -138,6 +138,29 @@ config TBOOT If unsure, say Y. +choice + prompt "Alignment of Xen image" + default XEN_ALIGN_2M if PV_SHIM_EXCLUSIVE + default XEN_ALIGN_DEFAULT + ---help--- + Specify alignment for Xen image. + + If unsure, choose "default". + +config XEN_ALIGN_DEFAULT + bool "Default alignment" + ---help--- + Pick alignment according to build variants. + + For EFI build the default alignment is 2M. For ELF build + the default alignment is 4K due to syslinux failing to handle + the increment of image size induced by 2M alignment. + +config XEN_ALIGN_2M + bool "2M alignment" + +endchoice + config XEN_GUEST def_bool n prompt "Xen Guest" diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S index 6e9bda5109..cb42dc8fda 100644 --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -12,7 +12,6 @@ #define FORMAT "pei-x86-64" #undef __XEN_VIRT_START #define __XEN_VIRT_START __image_base__ -#define SECTION_ALIGN MB(2) #define DECL_SECTION(x) x : ENTRY(efi_start) @@ -20,13 +19,18 @@ ENTRY(efi_start) #else /* !EFI */ #define FORMAT "elf64-x86-64" -#define SECTION_ALIGN PAGE_SIZE #define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START) ENTRY(start_pa) #endif /* EFI */ +#if defined(CONFIG_XEN_ALIGN_2M) || defined(EFI) +# define SECTION_ALIGN MB(2) +#else +# define SECTION_ALIGN PAGE_SIZE +#endif + OUTPUT_FORMAT(FORMAT, FORMAT, FORMAT) OUTPUT_ARCH(i386:x86-64) -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/pvshim: use 2M alignment
>>> On 19.03.19 at 14:50, wrote: > On Tue, Mar 19, 2019 at 07:42:56AM -0600, Jan Beulich wrote: >> >>> On 19.03.19 at 14:05, wrote: >> > --- a/xen/arch/x86/configs/pvshim_defconfig >> > +++ b/xen/arch/x86/configs/pvshim_defconfig >> > @@ -5,6 +5,7 @@ CONFIG_PVH_GUEST=y >> > CONFIG_PV_SHIM=y >> > CONFIG_PV_SHIM_EXCLUSIVE=y >> > CONFIG_NR_CPUS=32 >> > +CONFIG_XEN_ALIGN_2M=y >> > # Disable features not used by the PV shim >> > # CONFIG_SHADOW_PAGING is not set >> > # CONFIG_BIGMEM is not set >> >> Instead of this, why not add >> >> default XEN_ALIGN_2M if PV_SHIM_EXCLUSIVE >> >> to the config option itself, ahead of the default patch 1 establishes? > > This seems to work -- I didn't know you can have two default's for the > same option. The order is important, but beyond that you can have any number of them. The first one the "if" of which matches gets used. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU
>>> On 19.03.19 at 14:47, wrote:
> On 2019/3/19 20:58, Jan Beulich wrote:
>> On 19.03.19 at 12:32, wrote:
>>> On 2019/3/18 16:59, Jan Beulich wrote:
On 16.03.19 at 11:11, wrote:
> On 2019/3/15 20:41, Jan Beulich wrote:
>> On 21.02.19 at 10:50, wrote:
>>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>>> @@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
>>> switch ( current_cpu_data.x86 )
>>> {
>>> case 0x15:
>>> +case 0x17:
>>> +case 0x18:
>>> num_counters = F15H_NUM_COUNTERS;
>>> counters = AMD_F15H_COUNTERS;
>>> ctrls = AMD_F15H_CTRLS;
>>
>> Unless you know what AMD Fam18 will look like, you can't do it
>> like this. Fam18 really needs to be further qualified by a vendor
>> check at this point in time.
>
> Hygon will negotiate with AMD to make sure that only Hygon should use
> Fam18h.
In the success case of which please state this in the description.
Until those negotiations have succeeded I'm afraid I'm going to
insist to see the extra check added.
>>>
>>> How to check vendor? Maybe like this:
>>> case 0x15:
>>> case 0x17:
>>> case 0x18:
>>> if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
>>> boot_cpu_data.x86 == 0x18)
>>> return -EINVAL;
>>>
>>> num_counters = F15H_NUM_COUNTERS;
>>> counters = AMD_F15H_COUNTERS;
>>> ctrls = AMD_F15H_CTRLS;
>>>
>>> or just add Hygon support at beginning of amd_vpmu_init():
>>> if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
>>> num_counters = F15H_NUM_COUNTERS;
>>> counters = AMD_F15H_COUNTERS;
>>> ctrls = AMD_F15H_CTRLS;
>>> k7_counters_mirrored = 1;
>>> }
>>
>> A suitable variant of the latter or
>>
>> int __init amd_vpmu_init(void)
>> {
>> unsigned int i, fam = current_cpu_data.x86
>>
>> /* */
>> if ( current_cpu_data.x86_vendor == X86_VENDOR_HYGON && fam == 0x18 )
>> fam = 0x17;
>
> This is the minimum change, I think it's better.
>
>>
>> switch ( fam )
>> ...
>>
>> or perhaps even better would be two separate switch()-es, one for
>> AMD and one for Hygon. Possibly even a separate hygon_vpmu_init().
>
> A separate hygon_vpmu_init() is also fine except that the last part of
> the function can be shared.
So perhaps split that part out into a static _vpmu_init() or common_init()?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86: drop "depends on X86" for TBOOT Kconfig option
Given that this file already resides under arch/x86, there is no need to have the dependency. Signed-off-by: Wei Liu --- xen/arch/x86/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 5c2d1070b6..76393fd23a 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -130,7 +130,6 @@ config HVM_FEP config TBOOT def_bool y prompt "Xen tboot support" if EXPERT = "y" - depends on X86 select CRYPTO ---help--- Allows support for Trusted Boot using the Intel(R) Trusted Execution -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] x86: decouple xen alignment setting from EFI/ELF build
>>> On 19.03.19 at 14:57, wrote: > Introduce a new Kconfig option to pick the alignment for xen binary. > To retain original behaviour, the default pick for EFI build is 2M and > ELF build 4K. > > Make the PVHSHIM build use 2M alignment for potentially better > performance. > > Signed-off-by: Wei Liu Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Arm boot regression with Xen 4.12
Hi,
> Could you give a try to the below patch?
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 01ae20..2c34138bbd 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1139,7 +1139,7 @@ void free_init_memory(void)
> *(p + i) = insn;
>
> set_pte_flags_on_range(__init_begin, len, mg_clear);
> -init_domheap_pages(pa, pa + len);
> +dt_unreserved_regions(pa, pa + len, init_domheap_pages, 0);
> printk("Freed %ldkB init memory.\n",
> (long)(__init_end-__init_begin)>>10);
> }
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 444857a967..8dbc4f819b 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -764,18 +764,18 @@ void __init start_xen(unsigned long boot_phys_offset,
>"Please check your bootloader.\n",
>fdt_paddr);
>
> -fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
> -
> -cmdline = boot_fdt_cmdline(device_tree_flattened);
> -printk("Command line: %s\n", cmdline);
> -cmdline_parse(cmdline);
> -
> /* Register Xen's load address as a boot module. */
> xen_bootmodule = add_boot_module(BOOTMOD_XEN,
> (paddr_t)(uintptr_t)(_start + boot_phys_offset),
> (paddr_t)(uintptr_t)(_end - _start + 1), false);
> BUG_ON(!xen_bootmodule);
>
> +fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
> +
> +cmdline = boot_fdt_cmdline(device_tree_flattened);
> +printk("Command line: %s\n", cmdline);
> +cmdline_parse(cmdline);
> +
> setup_pagetables(boot_phys_offset);
>
> setup_mm(fdt_paddr, fdt_size);
>
I tried the above patch but still see the same crash:
tarting kernel ...
- UART enabled -
- CPU booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - bfff
(XEN)
(XEN) MODULE[0]: 4200 - 42120d81 Xen
(XEN) MODULE[1]: be51 - be51d000 Device Tree
(XEN) MODULE[2]: 4048 - 4268 Kernel
(XEN) RESVD[0]: 4300 - 4300d000
(XEN) RESVD[1]: be51 - be51d000
(XEN)
(XEN)
(XEN) Command line: console=dtuart dom0_mem=1024M
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "/serial@3086", options ""
(XEN) Unable to initialize dtuart: -9
(XEN) Bad console= option 'dtuart'
Xen 4.13-unstable
(XEN) Xen version 4.13-unstable (atomar@) (aarch64-linux-gnu-gcc
(Linaro GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y Tue Mar 19 19:14:9
(XEN) Latest ChangeSet: Tue Feb 12 18:33:30 2019 + git:1e780ef-dirty
(XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
(XEN) 64-bit Execution:
(XEN) Processor Features: 0100
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg
(XEN) Debug Features: 10305106
(XEN) Auxiliary Features:
(XEN) Memory Model Features: 1122
(XEN) ISA Features: 00011120
(XEN) 32-bit Execution:
(XEN) Processor Features: 0131:10011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 03010066
(XEN) Auxiliary Features:
(XEN) Memory Model Features: 10201105 4000 0126 02102211
(XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.0
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 4 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv3 initialization:
(XEN) gic_dist_addr=0x003880
(XEN) gic_maintenance_irq=25
(XEN) gic_rdist_stride=0
(XEN) gic_rdist_regions=1
(XEN) redistributor regions:
(XEN) - region 0: 0x003888 - 0x003894
(XEN) GICv3: 160 lines, (IID 0001143b).
(XEN) GICv3: CPU0: Found redistributor in region 0 @4001a000
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN) load_precision_shift: 18
(XEN) load_window_shift: 30
(XEN) underload_balance_tolerance: 0
(XEN) overload_balance_tolerance: -3
(XEN) runqueues arrangement: socket
(XEN) cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN) First cpu on runqueue, activating
(XEN) Allocated console ring of 32 KiB.
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on pagin
Re: [Xen-devel] [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture
On Thu, Mar 14, 2019 at 07:45:56PM +, Igor Druzhinin wrote: > On 14/03/2019 17:41, Anthony PERARD wrote: > > Hi, > > > > On Wed, Mar 06, 2019 at 12:40:54PM +, Igor Druzhinin wrote: > >> This aperture doesn't exist in OVMF and trying to use it causes > > > > I'm trying to understand what you mean by writing "doesn't exist in > > OVMF". Are prefetchable BAR not handled by ScanForRootBridges() ? > > Or is it the emulation of the config space that isn't correct? > > Maybe QEMU should lies about a BAR been prefetchable? > > The problem here is: hvmloader places BARs initially disregarding > prefetchable bit in an arbitrary order because essentially there is only > 1 aperture for the host bridge in emulated system under Xen (and KVM as > well). In PcatPciRootBridgeParseBars() we construct apertures for high > level OVMF code by reading the BAR placement information after > hvmloader. It often appears that there are prefetchable and > non-prefetchable BARs coexist with each other and make prefetchable and > non-prefetchable apertures overlap. This eventually triggers an > assertion in high level OVMF code because that shouldn't happen. Thanks for the explanation. Could you add it to the patch description? > OVMF for KVM is not using prefetchable BAR at all - see > PciHostBridgeGetRootBridges() in which it passes mNonExistAperture dummy > object to high level code. I think it's wrong to construct a > prefetchable aperture for Xen and this code should be removed as it's > done for QEMU-KVM. Do you think this patch needs to do that? It would be nice to remove the code that isn't useful so feel free to do it and/or keep the current patch with the description updated. Thanks, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored
On Mon, Mar 18, 2019 at 10:43:12PM +0100, Marek Marczykowski-Górecki wrote: > On Mon, Mar 18, 2019 at 06:37:31PM +0100, Roger Pau Monne wrote: > > Or if it's not possible to honor the hinted address an error is returned > > instead. > > Just to be sure: MAP_FIXED will cause to map at specified address, even > if something is mapped there already. From mmap(2): That should be fine. We do want to replace an exiting mapping (which is munmap before the mmap call), but it would have been nice to know when something is already mapped, to detect programming error. > If the memory region specified by addr and len overlaps pages of any > existing mapping(s), then the overlapped part of the existing map‐ > ping(s) will be discarded. If the specified address cannot be used, > mmap() will fail. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v13] tolerate jitter in cpu_khz calculation to avoid TSC emulation
Am Thu, 14 Mar 2019 15:41:55 +0100 schrieb Olaf Hering : > So before I spam you guys with any more variants, I better ask if any further > attempt would fly anyway. So, should I spend any more time to fix this bug? Olaf pgpxD61zDeHs3.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: drop "depends on X86" for TBOOT Kconfig option
>>> On 19.03.19 at 14:59, wrote: > Given that this file already resides under arch/x86, there is no need > to have the dependency. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.19 test] 133899: regressions - FAIL
flight 133899 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133899/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 133868 REGR. vs. 129313 Tests which are failing intermittently (not blocking): test-arm64-arm64-examine 8 reboot fail in 133868 pass in 133899 test-armhf-armhf-xl 6 xen-install fail in 133868 pass in 133899 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail pass in 133868 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail pass in 133868 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-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-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-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-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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-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-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-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: linuxce194fa2b267e2018f42442347d90df01c4071d6 baseline version: linux84df9525b0c27f3ebc2ebb1864fa
Re: [Xen-devel] Arm boot regression with Xen 4.12
On 19/03/2019 14:01, Amit Tomer wrote: I tried the above patch but still see the same crash: [..] On the other hand, it didn't come on 4.11. That's good to know. Can you bisect Xen and see if you can pin point a specific commit? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored
On Mon, Mar 18, 2019 at 06:37:31PM +0100, Roger Pau Monne wrote: > Or if it's not possible to honor the hinted address an error is returned > instead. This makes it easier to spot the actual failure, instead of > failing later on when the caller of xen_remap_bucket realizes the > mapping has not been created at the requested address. > > Also note that at least on FreeBSD using MAP_FIXED will cause mmap to > try harder to honor the passed address. > > Signed-off-by: Roger Pau Monné > Reviewed-by: Paul Durrant Acked-by: Anthony PERARD -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v10 00/11] viridian: implement more enlightenments
This series adds three new enlightenments: - Synthetic timers, which depends on the... - Synthetic interrupt controller (or SynIC) - Synthetic cluster IPI All these enlightenments are implemented in current versions of QEMU/KVM so this series closes the gap. Paul Durrant (11): viridian: add init hooks viridian: separately allocate domain and vcpu structures viridian: use stack variables for viridian_vcpu and viridian_domain... viridian: make 'fields' struct anonymous... viridian: extend init/deinit hooks into synic and time modules viridian: add missing context save helpers into synic and time modules viridian: use viridian_map/unmap_guest_page() for reference tsc page viridian: stop directly calling viridian_time_ref_count_freeze/thaw()... viridian: add implementation of synthetic interrupt MSRs viridian: add implementation of synthetic timers viridian: add implementation of the HvSendSyntheticClusterIpi hypercall docs/man/xl.cfg.5.pod.in | 18 +- tools/libxl/libxl.h| 18 + tools/libxl/libxl_dom.c| 10 + tools/libxl/libxl_types.idl| 3 + xen/arch/x86/domain.c | 12 +- xen/arch/x86/hvm/hvm.c | 10 + xen/arch/x86/hvm/viridian/private.h| 31 +- xen/arch/x86/hvm/viridian/synic.c | 376 -- xen/arch/x86/hvm/viridian/time.c | 526 ++--- xen/arch/x86/hvm/viridian/viridian.c | 229 +-- xen/arch/x86/hvm/vlapic.c | 20 +- xen/include/asm-x86/hvm/domain.h | 2 +- xen/include/asm-x86/hvm/hvm.h | 7 + xen/include/asm-x86/hvm/vcpu.h | 2 +- xen/include/asm-x86/hvm/viridian.h | 75 +++- xen/include/public/arch-x86/hvm/save.h | 4 + xen/include/public/hvm/params.h| 17 +- 17 files changed, 1220 insertions(+), 140 deletions(-) v8: - Squash in follow-up series v4: - Add two cleanup patches (#3 and #4) and re-order #8 and #9 v3: - Add the synthetic cluster IPI patch (#11) --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: "Roger Pau Monné" Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu -- 2.20.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v10 07/11] viridian: use viridian_map/unmap_guest_page() for reference tsc page
Whilst the reference tsc page does not currently need to be kept mapped
after it is initially set up (or updated after migrate), the code can
be simplified by using the common guest page map/unmap and dump functions.
New functionality added by a subsequent patch will also require the page to
kept mapped for the lifetime of the domain.
NOTE: Because the reference tsc page is per-domain rather than per-vcpu
this patch also changes viridian_map_guest_page() to take a domain
pointer rather than a vcpu pointer. The domain pointer cannot be
const, unlike the vcpu pointer.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
---
xen/arch/x86/hvm/viridian/private.h | 2 +-
xen/arch/x86/hvm/viridian/synic.c| 6 ++-
xen/arch/x86/hvm/viridian/time.c | 56 +---
xen/arch/x86/hvm/viridian/viridian.c | 3 +-
xen/include/asm-x86/hvm/viridian.h | 2 +-
5 files changed, 25 insertions(+), 44 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/private.h
b/xen/arch/x86/hvm/viridian/private.h
index 5078b2d2ab..96a784b840 100644
--- a/xen/arch/x86/hvm/viridian/private.h
+++ b/xen/arch/x86/hvm/viridian/private.h
@@ -111,7 +111,7 @@ void viridian_time_load_domain_ctxt(
void viridian_dump_guest_page(const struct vcpu *v, const char *name,
const struct viridian_page *vp);
-void viridian_map_guest_page(const struct vcpu *v, struct viridian_page *vp);
+void viridian_map_guest_page(struct domain *d, struct viridian_page *vp);
void viridian_unmap_guest_page(struct viridian_page *vp);
#endif /* X86_HVM_VIRIDIAN_PRIVATE_H */
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index b8dab4b246..fb560bc162 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -81,6 +81,7 @@ void viridian_apic_assist_clear(const struct vcpu *v)
int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
{
struct viridian_vcpu *vv = v->arch.hvm.viridian;
+struct domain *d = v->domain;
switch ( idx )
{
@@ -103,7 +104,7 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
vv->vp_assist.msr.raw = val;
viridian_dump_guest_page(v, "VP_ASSIST", &vv->vp_assist);
if ( vv->vp_assist.msr.enabled )
-viridian_map_guest_page(v, &vv->vp_assist);
+viridian_map_guest_page(d, &vv->vp_assist);
break;
default:
@@ -178,10 +179,11 @@ void viridian_synic_load_vcpu_ctxt(
struct vcpu *v, const struct hvm_viridian_vcpu_context *ctxt)
{
struct viridian_vcpu *vv = v->arch.hvm.viridian;
+struct domain *d = v->domain;
vv->vp_assist.msr.raw = ctxt->vp_assist_msr;
if ( vv->vp_assist.msr.enabled )
-viridian_map_guest_page(v, &vv->vp_assist);
+viridian_map_guest_page(d, &vv->vp_assist);
vv->apic_assist_pending = ctxt->apic_assist_pending;
}
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 4399e62f54..16fe41d411 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -25,33 +25,10 @@ typedef struct _HV_REFERENCE_TSC_PAGE
uint64_t Reserved2[509];
} HV_REFERENCE_TSC_PAGE, *PHV_REFERENCE_TSC_PAGE;
-static void dump_reference_tsc(const struct domain *d)
-{
-const union viridian_page_msr *rt = &d->arch.hvm.viridian->reference_tsc;
-
-if ( !rt->enabled )
-return;
-
-printk(XENLOG_G_INFO "d%d: VIRIDIAN REFERENCE_TSC: pfn: %lx\n",
- d->domain_id, (unsigned long)rt->pfn);
-}
-
static void update_reference_tsc(struct domain *d, bool initialize)
{
-unsigned long gmfn = d->arch.hvm.viridian->reference_tsc.pfn;
-struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
-HV_REFERENCE_TSC_PAGE *p;
-
-if ( !page || !get_page_type(page, PGT_writable_page) )
-{
-if ( page )
-put_page(page);
-gdprintk(XENLOG_WARNING, "Bad GMFN %#"PRI_gfn" (MFN %#"PRI_mfn")\n",
- gmfn, mfn_x(page ? page_to_mfn(page) : INVALID_MFN));
-return;
-}
-
-p = __map_domain_page(page);
+const struct viridian_page *rt = &d->arch.hvm.viridian->reference_tsc;
+HV_REFERENCE_TSC_PAGE *p = rt->ptr;
if ( initialize )
clear_page(p);
@@ -82,7 +59,7 @@ static void update_reference_tsc(struct domain *d, bool
initialize)
printk(XENLOG_G_INFO "d%d: VIRIDIAN REFERENCE_TSC: invalidated\n",
d->domain_id);
-goto out;
+return;
}
/*
@@ -100,11 +77,6 @@ static void update_reference_tsc(struct domain *d, bool
initialize)
if ( p->TscSequence == 0x ||
p->TscSequence == 0 ) /* Avoid both 'invalid' values */
p->TscSequence = 1;
-
- out:
-unmap_domain_page(p);
-
-put_page_and_type(page);
}
static int64_t raw_trc_val(const struct domain *d)
@@ -149,10 +
[Xen-devel] [PATCH v10 06/11] viridian: add missing context save helpers into synic and time modules
Currently the time module lacks vcpu context save helpers and the synic
module lacks domain context save helpers. These helpers are not yet
required but subsequent patches will require at least some of them so this
patch completes the set to avoid introducing them in an ad-hoc way.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v3:
- Add missing callers so that they are not added in an ad-hoc way
---
xen/arch/x86/hvm/viridian/private.h | 10 ++
xen/arch/x86/hvm/viridian/synic.c| 10 ++
xen/arch/x86/hvm/viridian/time.c | 10 ++
xen/arch/x86/hvm/viridian/viridian.c | 4
4 files changed, 34 insertions(+)
diff --git a/xen/arch/x86/hvm/viridian/private.h
b/xen/arch/x86/hvm/viridian/private.h
index 8c029f62c6..5078b2d2ab 100644
--- a/xen/arch/x86/hvm/viridian/private.h
+++ b/xen/arch/x86/hvm/viridian/private.h
@@ -85,6 +85,11 @@ void viridian_synic_save_vcpu_ctxt(const struct vcpu *v,
void viridian_synic_load_vcpu_ctxt(
struct vcpu *v, const struct hvm_viridian_vcpu_context *ctxt);
+void viridian_synic_save_domain_ctxt(
+const struct domain *d, struct hvm_viridian_domain_context *ctxt);
+void viridian_synic_load_domain_ctxt(
+struct domain *d, const struct hvm_viridian_domain_context *ctxt);
+
int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val);
int viridian_time_rdmsr(const struct vcpu *v, uint32_t idx, uint64_t *val);
@@ -94,6 +99,11 @@ int viridian_time_domain_init(const struct domain *d);
void viridian_time_vcpu_deinit(const struct vcpu *v);
void viridian_time_domain_deinit(const struct domain *d);
+void viridian_time_save_vcpu_ctxt(
+const struct vcpu *v, struct hvm_viridian_vcpu_context *ctxt);
+void viridian_time_load_vcpu_ctxt(
+struct vcpu *v, const struct hvm_viridian_vcpu_context *ctxt);
+
void viridian_time_save_domain_ctxt(
const struct domain *d, struct hvm_viridian_domain_context *ctxt);
void viridian_time_load_domain_ctxt(
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index 4b00dbe1b3..b8dab4b246 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -186,6 +186,16 @@ void viridian_synic_load_vcpu_ctxt(
vv->apic_assist_pending = ctxt->apic_assist_pending;
}
+void viridian_synic_save_domain_ctxt(
+const struct domain *d, struct hvm_viridian_domain_context *ctxt)
+{
+}
+
+void viridian_synic_load_domain_ctxt(
+struct domain *d, const struct hvm_viridian_domain_context *ctxt)
+{
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 48aca7e0ab..4399e62f54 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -233,6 +233,16 @@ void viridian_time_domain_deinit(const struct domain *d)
{
}
+void viridian_time_save_vcpu_ctxt(
+const struct vcpu *v, struct hvm_viridian_vcpu_context *ctxt)
+{
+}
+
+void viridian_time_load_vcpu_ctxt(
+struct vcpu *v, const struct hvm_viridian_vcpu_context *ctxt)
+{
+}
+
void viridian_time_save_domain_ctxt(
const struct domain *d, struct hvm_viridian_domain_context *ctxt)
{
diff --git a/xen/arch/x86/hvm/viridian/viridian.c
b/xen/arch/x86/hvm/viridian/viridian.c
index f9a509d918..742a988252 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -707,6 +707,7 @@ static int viridian_save_domain_ctxt(struct vcpu *v,
return 0;
viridian_time_save_domain_ctxt(d, &ctxt);
+viridian_synic_save_domain_ctxt(d, &ctxt);
return (hvm_save_entry(VIRIDIAN_DOMAIN, 0, h, &ctxt) != 0);
}
@@ -723,6 +724,7 @@ static int viridian_load_domain_ctxt(struct domain *d,
vd->hypercall_gpa.raw = ctxt.hypercall_gpa;
vd->guest_os_id.raw = ctxt.guest_os_id;
+viridian_synic_load_domain_ctxt(d, &ctxt);
viridian_time_load_domain_ctxt(d, &ctxt);
return 0;
@@ -738,6 +740,7 @@ static int viridian_save_vcpu_ctxt(struct vcpu *v,
hvm_domain_context_t *h)
if ( !is_viridian_vcpu(v) )
return 0;
+viridian_time_save_vcpu_ctxt(v, &ctxt);
viridian_synic_save_vcpu_ctxt(v, &ctxt);
return hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, &ctxt);
@@ -764,6 +767,7 @@ static int viridian_load_vcpu_ctxt(struct domain *d,
return -EINVAL;
viridian_synic_load_vcpu_ctxt(v, &ctxt);
+viridian_time_load_vcpu_ctxt(v, &ctxt);
return 0;
}
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v10 03/11] viridian: use stack variables for viridian_vcpu and viridian_domain...
...where there is more than one dereference inside a function.
This shortens the code and makes it more readable. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
xen/arch/x86/hvm/viridian/synic.c| 49
xen/arch/x86/hvm/viridian/time.c | 27 ---
xen/arch/x86/hvm/viridian/viridian.c | 47 +-
3 files changed, 69 insertions(+), 54 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index 28eda7798c..f3d9f7ae74 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -30,7 +30,8 @@ typedef union _HV_VP_ASSIST_PAGE
void viridian_apic_assist_set(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
+struct viridian_vcpu *vv = v->arch.hvm.viridian;
+HV_VP_ASSIST_PAGE *ptr = vv->vp_assist.ptr;
if ( !ptr )
return;
@@ -40,25 +41,25 @@ void viridian_apic_assist_set(const struct vcpu *v)
* wrong and the VM will most likely hang so force a crash now
* to make the problem clear.
*/
-if ( v->arch.hvm.viridian->apic_assist_pending )
+if ( vv->apic_assist_pending )
domain_crash(v->domain);
-v->arch.hvm.viridian->apic_assist_pending = true;
+vv->apic_assist_pending = true;
ptr->ApicAssist.no_eoi = 1;
}
bool viridian_apic_assist_completed(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
+struct viridian_vcpu *vv = v->arch.hvm.viridian;
+HV_VP_ASSIST_PAGE *ptr = vv->vp_assist.ptr;
if ( !ptr )
return false;
-if ( v->arch.hvm.viridian->apic_assist_pending &&
- !ptr->ApicAssist.no_eoi )
+if ( vv->apic_assist_pending && !ptr->ApicAssist.no_eoi )
{
/* An EOI has been avoided */
-v->arch.hvm.viridian->apic_assist_pending = false;
+vv->apic_assist_pending = false;
return true;
}
@@ -67,17 +68,20 @@ bool viridian_apic_assist_completed(const struct vcpu *v)
void viridian_apic_assist_clear(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
+struct viridian_vcpu *vv = v->arch.hvm.viridian;
+HV_VP_ASSIST_PAGE *ptr = vv->vp_assist.ptr;
if ( !ptr )
return;
ptr->ApicAssist.no_eoi = 0;
-v->arch.hvm.viridian->apic_assist_pending = false;
+vv->apic_assist_pending = false;
}
int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
{
+struct viridian_vcpu *vv = v->arch.hvm.viridian;
+
switch ( idx )
{
case HV_X64_MSR_EOI:
@@ -95,12 +99,11 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
case HV_X64_MSR_VP_ASSIST_PAGE:
/* release any previous mapping */
-viridian_unmap_guest_page(&v->arch.hvm.viridian->vp_assist);
-v->arch.hvm.viridian->vp_assist.msr.raw = val;
-viridian_dump_guest_page(v, "VP_ASSIST",
- &v->arch.hvm.viridian->vp_assist);
-if ( v->arch.hvm.viridian->vp_assist.msr.fields.enabled )
-viridian_map_guest_page(v, &v->arch.hvm.viridian->vp_assist);
+viridian_unmap_guest_page(&vv->vp_assist);
+vv->vp_assist.msr.raw = val;
+viridian_dump_guest_page(v, "VP_ASSIST", &vv->vp_assist);
+if ( vv->vp_assist.msr.fields.enabled )
+viridian_map_guest_page(v, &vv->vp_assist);
break;
default:
@@ -146,18 +149,22 @@ int viridian_synic_rdmsr(const struct vcpu *v, uint32_t
idx, uint64_t *val)
void viridian_synic_save_vcpu_ctxt(const struct vcpu *v,
struct hvm_viridian_vcpu_context *ctxt)
{
-ctxt->apic_assist_pending = v->arch.hvm.viridian->apic_assist_pending;
-ctxt->vp_assist_msr = v->arch.hvm.viridian->vp_assist.msr.raw;
+const struct viridian_vcpu *vv = v->arch.hvm.viridian;
+
+ctxt->apic_assist_pending = vv->apic_assist_pending;
+ctxt->vp_assist_msr = vv->vp_assist.msr.raw;
}
void viridian_synic_load_vcpu_ctxt(
struct vcpu *v, const struct hvm_viridian_vcpu_context *ctxt)
{
-v->arch.hvm.viridian->vp_assist.msr.raw = ctxt->vp_assist_msr;
-if ( v->arch.hvm.viridian->vp_assist.msr.fields.enabled )
-viridian_map_guest_page(v, &v->arch.hvm.viridian->vp_assist);
+struct viridian_vcpu *vv = v->arch.hvm.viridian;
+
+vv->vp_assist.msr.raw = ctxt->vp_assist_msr;
+if ( vv->vp_assist.msr.fields.enabled )
+viridian_map_guest_page(v, &vv->vp_assist);
-v->arch.hvm.viridian->apic_assist_pending = ctxt->apic_assist_pending;
+vv->apic_assist_pending = ctxt->apic_assist_pending;
}
/*
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index a7e94aadf0..76f9612001 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/
[Xen-devel] [PATCH v10 02/11] viridian: separately allocate domain and vcpu structures
Currently the viridian_domain and viridian_vcpu structures are inline in
the hvm_domain and hvm_vcpu structures respectively. Subsequent patches
will need to add sizable extra fields to the viridian structures which
will cause the PAGE_SIZE limit of the overall vcpu structure to be
exceeded. This patch, therefore, uses the new init hooks to separately
allocate the structures and converts the 'viridian' fields in hvm_domain
and hvm_cpu to be pointers to these allocations. These separate allocations
also allow some vcpu and domain pointers to become const.
Ideally, now that they are no longer inline, the allocations of the
viridian structures could be made conditional on whether the toolstack
is going to configure the viridian enlightenments. However the toolstack
is currently unable to convey this information to the domain creation code
so such an enhancement is deferred until that becomes possible.
NOTE: The patch also introduced the 'is_viridian_vcpu' macro to avoid
introducing a second evaluation of 'is_viridian_domain' with an
open-coded 'v->domain' argument. This macro will also be further
used in a subsequent patch.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v4:
- Const-ify some vcpu and domain pointers
v2:
- use XFREE()
- expand commit comment to point out why allocations are unconditional
---
xen/arch/x86/hvm/viridian/private.h | 2 +-
xen/arch/x86/hvm/viridian/synic.c| 46 -
xen/arch/x86/hvm/viridian/time.c | 38 +++---
xen/arch/x86/hvm/viridian/viridian.c | 75 ++--
xen/include/asm-x86/hvm/domain.h | 2 +-
xen/include/asm-x86/hvm/hvm.h| 4 ++
xen/include/asm-x86/hvm/vcpu.h | 2 +-
xen/include/asm-x86/hvm/viridian.h | 10 ++--
8 files changed, 101 insertions(+), 78 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/private.h
b/xen/arch/x86/hvm/viridian/private.h
index 398b22f12d..46174f48cd 100644
--- a/xen/arch/x86/hvm/viridian/private.h
+++ b/xen/arch/x86/hvm/viridian/private.h
@@ -89,7 +89,7 @@ void viridian_time_load_domain_ctxt(
void viridian_dump_guest_page(const struct vcpu *v, const char *name,
const struct viridian_page *vp);
-void viridian_map_guest_page(struct vcpu *v, struct viridian_page *vp);
+void viridian_map_guest_page(const struct vcpu *v, struct viridian_page *vp);
void viridian_unmap_guest_page(struct viridian_page *vp);
#endif /* X86_HVM_VIRIDIAN_PRIVATE_H */
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index a6ebbbc9f5..28eda7798c 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -28,9 +28,9 @@ typedef union _HV_VP_ASSIST_PAGE
uint8_t ReservedZBytePadding[PAGE_SIZE];
} HV_VP_ASSIST_PAGE;
-void viridian_apic_assist_set(struct vcpu *v)
+void viridian_apic_assist_set(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian.vp_assist.ptr;
+HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
if ( !ptr )
return;
@@ -40,40 +40,40 @@ void viridian_apic_assist_set(struct vcpu *v)
* wrong and the VM will most likely hang so force a crash now
* to make the problem clear.
*/
-if ( v->arch.hvm.viridian.apic_assist_pending )
+if ( v->arch.hvm.viridian->apic_assist_pending )
domain_crash(v->domain);
-v->arch.hvm.viridian.apic_assist_pending = true;
+v->arch.hvm.viridian->apic_assist_pending = true;
ptr->ApicAssist.no_eoi = 1;
}
-bool viridian_apic_assist_completed(struct vcpu *v)
+bool viridian_apic_assist_completed(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian.vp_assist.ptr;
+HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
if ( !ptr )
return false;
-if ( v->arch.hvm.viridian.apic_assist_pending &&
+if ( v->arch.hvm.viridian->apic_assist_pending &&
!ptr->ApicAssist.no_eoi )
{
/* An EOI has been avoided */
-v->arch.hvm.viridian.apic_assist_pending = false;
+v->arch.hvm.viridian->apic_assist_pending = false;
return true;
}
return false;
}
-void viridian_apic_assist_clear(struct vcpu *v)
+void viridian_apic_assist_clear(const struct vcpu *v)
{
-HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian.vp_assist.ptr;
+HV_VP_ASSIST_PAGE *ptr = v->arch.hvm.viridian->vp_assist.ptr;
if ( !ptr )
return;
ptr->ApicAssist.no_eoi = 0;
-v->arch.hvm.viridian.apic_assist_pending = false;
+v->arch.hvm.viridian->apic_assist_pending = false;
}
int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
@@ -95,12 +95,12 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
case HV_X64_MSR_VP_ASSIST_PAGE:
/* release any previous mapping */
-viridian_unmap_guest_page(&v->arch.hvm.viridian
[Xen-devel] [PATCH v10 05/11] viridian: extend init/deinit hooks into synic and time modules
This patch simply adds domain and vcpu init/deinit hooks into the synic
and time modules and wires them into viridian_[domain|vcpu]_[init|deinit]().
Only one of the hooks is currently needed (to unmap the 'VP Assist' page)
but subsequent patches will make use of the others.
NOTE: To perform the unmap of the VP Assist page,
viridian_unmap_guest_page() is now directly called in the new
viridian_synic_vcpu_deinit() function (which is safe even if
is_viridian_vcpu() evaluates to false). This replaces the slightly
hacky mechanism of faking a zero write to the
HV_X64_MSR_VP_ASSIST_PAGE MSR in viridian_cpu_deinit().
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
---
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v4:
- Constify vcpu and domain pointers
v2:
- Pay attention to sync and time init hook return values
---
xen/arch/x86/hvm/viridian/private.h | 12 +
xen/arch/x86/hvm/viridian/synic.c| 19 ++
xen/arch/x86/hvm/viridian/time.c | 18 ++
xen/arch/x86/hvm/viridian/viridian.c | 37 ++--
4 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/private.h
b/xen/arch/x86/hvm/viridian/private.h
index 46174f48cd..8c029f62c6 100644
--- a/xen/arch/x86/hvm/viridian/private.h
+++ b/xen/arch/x86/hvm/viridian/private.h
@@ -74,6 +74,12 @@
int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val);
int viridian_synic_rdmsr(const struct vcpu *v, uint32_t idx, uint64_t *val);
+int viridian_synic_vcpu_init(const struct vcpu *v);
+int viridian_synic_domain_init(const struct domain *d);
+
+void viridian_synic_vcpu_deinit(const struct vcpu *v);
+void viridian_synic_domain_deinit(const struct domain *d);
+
void viridian_synic_save_vcpu_ctxt(const struct vcpu *v,
struct hvm_viridian_vcpu_context *ctxt);
void viridian_synic_load_vcpu_ctxt(
@@ -82,6 +88,12 @@ void viridian_synic_load_vcpu_ctxt(
int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val);
int viridian_time_rdmsr(const struct vcpu *v, uint32_t idx, uint64_t *val);
+int viridian_time_vcpu_init(const struct vcpu *v);
+int viridian_time_domain_init(const struct domain *d);
+
+void viridian_time_vcpu_deinit(const struct vcpu *v);
+void viridian_time_domain_deinit(const struct domain *d);
+
void viridian_time_save_domain_ctxt(
const struct domain *d, struct hvm_viridian_domain_context *ctxt);
void viridian_time_load_domain_ctxt(
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index 05d971b365..4b00dbe1b3 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -146,6 +146,25 @@ int viridian_synic_rdmsr(const struct vcpu *v, uint32_t
idx, uint64_t *val)
return X86EMUL_OKAY;
}
+int viridian_synic_vcpu_init(const struct vcpu *v)
+{
+return 0;
+}
+
+int viridian_synic_domain_init(const struct domain *d)
+{
+return 0;
+}
+
+void viridian_synic_vcpu_deinit(const struct vcpu *v)
+{
+viridian_unmap_guest_page(&v->arch.hvm.viridian->vp_assist);
+}
+
+void viridian_synic_domain_deinit(const struct domain *d)
+{
+}
+
void viridian_synic_save_vcpu_ctxt(const struct vcpu *v,
struct hvm_viridian_vcpu_context *ctxt)
{
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 909a3fb9e3..48aca7e0ab 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -215,6 +215,24 @@ int viridian_time_rdmsr(const struct vcpu *v, uint32_t
idx, uint64_t *val)
return X86EMUL_OKAY;
}
+int viridian_time_vcpu_init(const struct vcpu *v)
+{
+return 0;
+}
+
+int viridian_time_domain_init(const struct domain *d)
+{
+return 0;
+}
+
+void viridian_time_vcpu_deinit(const struct vcpu *v)
+{
+}
+
+void viridian_time_domain_deinit(const struct domain *d)
+{
+}
+
void viridian_time_save_domain_ctxt(
const struct domain *d, struct hvm_viridian_domain_context *ctxt)
{
diff --git a/xen/arch/x86/hvm/viridian/viridian.c
b/xen/arch/x86/hvm/viridian/viridian.c
index 1a20d68aaf..f9a509d918 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -418,22 +418,52 @@ int guest_rdmsr_viridian(const struct vcpu *v, uint32_t
idx, uint64_t *val)
int viridian_vcpu_init(struct vcpu *v)
{
+int rc;
+
ASSERT(!v->arch.hvm.viridian);
v->arch.hvm.viridian = xzalloc(struct viridian_vcpu);
if ( !v->arch.hvm.viridian )
return -ENOMEM;
+rc = viridian_synic_vcpu_init(v);
+if ( rc )
+goto fail;
+
+rc = viridian_time_vcpu_init(v);
+if ( rc )
+goto fail;
+
return 0;
+
+ fail:
+viridian_vcpu_deinit(v);
+
+return rc;
}
int viridian_domain_init(struct domain *d)
{
+int rc;
+
ASSERT(!d->arch.hvm.viridian);
d->arch.hvm.viridian = xzalloc(struct viridian_domain);
if ( !d->arch.hv
[Xen-devel] [PATCH v10 08/11] viridian: stop directly calling viridian_time_ref_count_freeze/thaw()...
...from arch_domain_shutdown/pause/unpause().
A subsequent patch will introduce an implementaion of synthetic timers
which will also need freeze/thaw hooks, so make the exported hooks more
generic and call through to (re-named and static) time_ref_count_freeze/thaw
functions.
NOTE: This patch also introduces a new time_ref_count() helper to return
the current counter value. This is currently only used by the MSR
read handler but the synthetic timer code will also need to use it.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
---
xen/arch/x86/domain.c | 12 ++--
xen/arch/x86/hvm/viridian/time.c | 24 +---
xen/include/asm-x86/hvm/viridian.h | 4 ++--
3 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 8d579e2cf9..02afa7518e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -657,20 +657,20 @@ void arch_domain_destroy(struct domain *d)
void arch_domain_shutdown(struct domain *d)
{
-if ( has_viridian_time_ref_count(d) )
-viridian_time_ref_count_freeze(d);
+if ( is_viridian_domain(d) )
+viridian_time_domain_freeze(d);
}
void arch_domain_pause(struct domain *d)
{
-if ( has_viridian_time_ref_count(d) )
-viridian_time_ref_count_freeze(d);
+if ( is_viridian_domain(d) )
+viridian_time_domain_freeze(d);
}
void arch_domain_unpause(struct domain *d)
{
-if ( has_viridian_time_ref_count(d) )
-viridian_time_ref_count_thaw(d);
+if ( is_viridian_domain(d) )
+viridian_time_domain_thaw(d);
}
int arch_domain_soft_reset(struct domain *d)
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 16fe41d411..71291d921c 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -91,7 +91,7 @@ static int64_t raw_trc_val(const struct domain *d)
return scale_delta(tsc, &tsc_to_ns) / 100ul;
}
-void viridian_time_ref_count_freeze(const struct domain *d)
+static void time_ref_count_freeze(const struct domain *d)
{
struct viridian_time_ref_count *trc =
&d->arch.hvm.viridian->time_ref_count;
@@ -100,7 +100,7 @@ void viridian_time_ref_count_freeze(const struct domain *d)
trc->val = raw_trc_val(d) + trc->off;
}
-void viridian_time_ref_count_thaw(const struct domain *d)
+static void time_ref_count_thaw(const struct domain *d)
{
struct viridian_time_ref_count *trc =
&d->arch.hvm.viridian->time_ref_count;
@@ -110,6 +110,24 @@ void viridian_time_ref_count_thaw(const struct domain *d)
trc->off = (int64_t)trc->val - raw_trc_val(d);
}
+static int64_t time_ref_count(const struct domain *d)
+{
+struct viridian_time_ref_count *trc =
+&d->arch.hvm.viridian->time_ref_count;
+
+return raw_trc_val(d) + trc->off;
+}
+
+void viridian_time_domain_freeze(const struct domain *d)
+{
+time_ref_count_freeze(d);
+}
+
+void viridian_time_domain_thaw(const struct domain *d)
+{
+time_ref_count_thaw(d);
+}
+
int viridian_time_wrmsr(struct vcpu *v, uint32_t idx, uint64_t val)
{
struct domain *d = v->domain;
@@ -179,7 +197,7 @@ int viridian_time_rdmsr(const struct vcpu *v, uint32_t idx,
uint64_t *val)
printk(XENLOG_G_INFO "d%d: VIRIDIAN MSR_TIME_REF_COUNT:
accessed\n",
d->domain_id);
-*val = raw_trc_val(d) + trc->off;
+*val = time_ref_count(d);
break;
}
diff --git a/xen/include/asm-x86/hvm/viridian.h
b/xen/include/asm-x86/hvm/viridian.h
index c65c044191..8146e2fc46 100644
--- a/xen/include/asm-x86/hvm/viridian.h
+++ b/xen/include/asm-x86/hvm/viridian.h
@@ -77,8 +77,8 @@ int guest_rdmsr_viridian(const struct vcpu *v, uint32_t idx,
uint64_t *val);
int
viridian_hypercall(struct cpu_user_regs *regs);
-void viridian_time_ref_count_freeze(const struct domain *d);
-void viridian_time_ref_count_thaw(const struct domain *d);
+void viridian_time_domain_freeze(const struct domain *d);
+void viridian_time_domain_thaw(const struct domain *d);
int viridian_vcpu_init(struct vcpu *v);
int viridian_domain_init(struct domain *d);
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v10 09/11] viridian: add implementation of synthetic interrupt MSRs
This patch introduces an implementation of the SCONTROL, SVERSION, SIEFP,
SIMP, EOM and SINT0-15 SynIC MSRs. No message source is added and, as such,
nothing will yet generate a synthetic interrupt. A subsequent patch will
add an implementation of synthetic timers which will need the infrastructure
added by this patch to deliver expiry messages to the guest.
NOTE: A 'synic' option is added to the toolstack viridian enlightenments
enumeration but is deliberately not documented as enabling these
SynIC registers without a message source is only useful for
debugging.
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
Reviewed-by: Jan Beulich
---
Cc: Ian Jackson
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: "Roger Pau Monné"
v8:
- Squash in
https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg01332.html
v7:
- Fix out label indentation
v6:
- Address further comments from Jan
v4:
- Address comments from Jan
v3:
- Add the 'SintPollingModeAvailable' bit in CPUID leaf 3
---
tools/libxl/libxl.h| 6 +
tools/libxl/libxl_dom.c| 3 +
tools/libxl/libxl_types.idl| 1 +
xen/arch/x86/hvm/viridian/synic.c | 241 -
xen/arch/x86/hvm/viridian/viridian.c | 19 ++
xen/arch/x86/hvm/vlapic.c | 20 +-
xen/include/asm-x86/hvm/hvm.h | 3 +
xen/include/asm-x86/hvm/viridian.h | 26 +++
xen/include/public/arch-x86/hvm/save.h | 2 +
xen/include/public/hvm/params.h| 7 +-
10 files changed, 323 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index a38e5cdba2..a923a380d3 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -318,6 +318,12 @@
*/
#define LIBXL_HAVE_VIRIDIAN_CRASH_CTL 1
+/*
+ * LIBXL_HAVE_VIRIDIAN_SYNIC indicates that the 'synic' value
+ * is present in the viridian enlightenment enumeration.
+ */
+#define LIBXL_HAVE_VIRIDIAN_SYNIC 1
+
/*
* LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE indicates that
* libxl_domain_build_info has the u.hvm.acpi_laptop_slate field.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 6160991af3..fb758d2ac3 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -317,6 +317,9 @@ static int hvm_set_viridian_features(libxl__gc *gc,
uint32_t domid,
if (libxl_bitmap_test(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_CRASH_CTL))
mask |= HVMPV_crash_ctl;
+if (libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_SYNIC))
+mask |= HVMPV_synic;
+
if (mask != 0 &&
xc_hvm_param_set(CTX->xch,
domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b685ac47ac..9860bcaf5f 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -235,6 +235,7 @@ libxl_viridian_enlightenment =
Enumeration("viridian_enlightenment", [
(4, "hcall_remote_tlb_flush"),
(5, "apic_assist"),
(6, "crash_ctl"),
+(7, "synic"),
])
libxl_hdtype = Enumeration("hdtype", [
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index fb560bc162..84ab02694f 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include "private.h"
@@ -28,6 +29,37 @@ typedef union _HV_VP_ASSIST_PAGE
uint8_t ReservedZBytePadding[PAGE_SIZE];
} HV_VP_ASSIST_PAGE;
+typedef enum HV_MESSAGE_TYPE {
+HvMessageTypeNone,
+HvMessageTimerExpired = 0x8010,
+} HV_MESSAGE_TYPE;
+
+typedef struct HV_MESSAGE_FLAGS {
+uint8_t MessagePending:1;
+uint8_t Reserved:7;
+} HV_MESSAGE_FLAGS;
+
+typedef struct HV_MESSAGE_HEADER {
+HV_MESSAGE_TYPE MessageType;
+uint16_t Reserved1;
+HV_MESSAGE_FLAGS MessageFlags;
+uint8_t PayloadSize;
+uint64_t Reserved2;
+} HV_MESSAGE_HEADER;
+
+#define HV_MESSAGE_SIZE 256
+#define HV_MESSAGE_MAX_PAYLOAD_QWORD_COUNT 30
+
+typedef struct HV_MESSAGE {
+HV_MESSAGE_HEADER Header;
+uint64_t Payload[HV_MESSAGE_MAX_PAYLOAD_QWORD_COUNT];
+} HV_MESSAGE;
+
+void __init __maybe_unused build_assertions(void)
+{
+BUILD_BUG_ON(sizeof(HV_MESSAGE) != HV_MESSAGE_SIZE);
+}
+
void viridian_apic_assist_set(const struct vcpu *v)
{
struct viridian_vcpu *vv = v->arch.hvm.viridian;
@@ -83,6 +115,8 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
struct viridian_vcpu *vv = v->arch.hvm.viridian;
struct domain *d = v->domain;
+ASSERT(v == current || !v->is_running);
+
switch ( idx )
{
case HV_X64_MSR_EOI:
@@ -107,6 +141,76 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
viridian_map_guest_page(d, &vv->vp_assist);
break;
+case HV_X64_MSR_SCONTROL:
+if ( !(viridian_feature_mask(d) & HVMPV_synic) )
+
[Xen-devel] [PATCH v10 01/11] viridian: add init hooks
This patch adds domain and vcpu init hooks for viridian features. The init
hooks do not yet do anything; the functionality will be added to by
subsequent patches.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v5:
- Put the call to viridian_domain_deinit() back into
hvm_domain_relinquish_resources() where it should be
v3:
- Re-instate call from domain deinit to vcpu deinit
- Move deinit calls to avoid introducing new labels
v2:
- Remove call from domain deinit to vcpu deinit
---
xen/arch/x86/hvm/hvm.c | 10 ++
xen/arch/x86/hvm/viridian/viridian.c | 10 ++
xen/include/asm-x86/hvm/viridian.h | 3 +++
3 files changed, 23 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8adbb61b57..11ce21fc08 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -666,6 +666,10 @@ int hvm_domain_initialise(struct domain *d)
if ( hvm_tsc_scaling_supported )
d->arch.hvm.tsc_scaling_ratio = hvm_default_tsc_scaling_ratio;
+rc = viridian_domain_init(d);
+if ( rc )
+goto fail2;
+
rc = hvm_funcs.domain_initialise(d);
if ( rc != 0 )
goto fail2;
@@ -687,6 +691,7 @@ int hvm_domain_initialise(struct domain *d)
hvm_destroy_cacheattr_region_list(d);
destroy_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0);
fail:
+viridian_domain_deinit(d);
return rc;
}
@@ -1526,6 +1531,10 @@ int hvm_vcpu_initialise(struct vcpu *v)
&& (rc = nestedhvm_vcpu_initialise(v)) < 0 ) /* teardown:
nestedhvm_vcpu_destroy */
goto fail5;
+rc = viridian_vcpu_init(v);
+if ( rc )
+goto fail5;
+
rc = hvm_all_ioreq_servers_add_vcpu(d, v);
if ( rc != 0 )
goto fail6;
@@ -1553,6 +1562,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
fail2:
hvm_vcpu_cacheattr_destroy(v);
fail1:
+viridian_vcpu_deinit(v);
return rc;
}
diff --git a/xen/arch/x86/hvm/viridian/viridian.c
b/xen/arch/x86/hvm/viridian/viridian.c
index 425af56856..5b0eb8a8c7 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -417,6 +417,16 @@ int guest_rdmsr_viridian(const struct vcpu *v, uint32_t
idx, uint64_t *val)
return X86EMUL_OKAY;
}
+int viridian_vcpu_init(struct vcpu *v)
+{
+return 0;
+}
+
+int viridian_domain_init(struct domain *d)
+{
+return 0;
+}
+
void viridian_vcpu_deinit(struct vcpu *v)
{
viridian_synic_wrmsr(v, HV_X64_MSR_VP_ASSIST_PAGE, 0);
diff --git a/xen/include/asm-x86/hvm/viridian.h
b/xen/include/asm-x86/hvm/viridian.h
index ec5ef8d3f9..f072838955 100644
--- a/xen/include/asm-x86/hvm/viridian.h
+++ b/xen/include/asm-x86/hvm/viridian.h
@@ -80,6 +80,9 @@ viridian_hypercall(struct cpu_user_regs *regs);
void viridian_time_ref_count_freeze(struct domain *d);
void viridian_time_ref_count_thaw(struct domain *d);
+int viridian_vcpu_init(struct vcpu *v);
+int viridian_domain_init(struct domain *d);
+
void viridian_vcpu_deinit(struct vcpu *v);
void viridian_domain_deinit(struct domain *d);
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v10 04/11] viridian: make 'fields' struct anonymous...
...inside viridian_page_msr and viridian_guest_os_id_msr unions.
There's no need to name it and the code is shortened by not doing so.
No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
xen/arch/x86/hvm/viridian/synic.c| 4 ++--
xen/arch/x86/hvm/viridian/time.c | 10 +-
xen/arch/x86/hvm/viridian/viridian.c | 20 +---
xen/include/asm-x86/hvm/viridian.h | 4 ++--
4 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/xen/arch/x86/hvm/viridian/synic.c
b/xen/arch/x86/hvm/viridian/synic.c
index f3d9f7ae74..05d971b365 100644
--- a/xen/arch/x86/hvm/viridian/synic.c
+++ b/xen/arch/x86/hvm/viridian/synic.c
@@ -102,7 +102,7 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
viridian_unmap_guest_page(&vv->vp_assist);
vv->vp_assist.msr.raw = val;
viridian_dump_guest_page(v, "VP_ASSIST", &vv->vp_assist);
-if ( vv->vp_assist.msr.fields.enabled )
+if ( vv->vp_assist.msr.enabled )
viridian_map_guest_page(v, &vv->vp_assist);
break;
@@ -161,7 +161,7 @@ void viridian_synic_load_vcpu_ctxt(
struct viridian_vcpu *vv = v->arch.hvm.viridian;
vv->vp_assist.msr.raw = ctxt->vp_assist_msr;
-if ( vv->vp_assist.msr.fields.enabled )
+if ( vv->vp_assist.msr.enabled )
viridian_map_guest_page(v, &vv->vp_assist);
vv->apic_assist_pending = ctxt->apic_assist_pending;
diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index 76f9612001..909a3fb9e3 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -29,16 +29,16 @@ static void dump_reference_tsc(const struct domain *d)
{
const union viridian_page_msr *rt = &d->arch.hvm.viridian->reference_tsc;
-if ( !rt->fields.enabled )
+if ( !rt->enabled )
return;
printk(XENLOG_G_INFO "d%d: VIRIDIAN REFERENCE_TSC: pfn: %lx\n",
- d->domain_id, (unsigned long)rt->fields.pfn);
+ d->domain_id, (unsigned long)rt->pfn);
}
static void update_reference_tsc(struct domain *d, bool initialize)
{
-unsigned long gmfn = d->arch.hvm.viridian->reference_tsc.fields.pfn;
+unsigned long gmfn = d->arch.hvm.viridian->reference_tsc.pfn;
struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
HV_REFERENCE_TSC_PAGE *p;
@@ -151,7 +151,7 @@ int viridian_time_wrmsr(struct vcpu *v, uint32_t idx,
uint64_t val)
vd->reference_tsc.raw = val;
dump_reference_tsc(d);
-if ( vd->reference_tsc.fields.enabled )
+if ( vd->reference_tsc.enabled )
update_reference_tsc(d, true);
break;
@@ -232,7 +232,7 @@ void viridian_time_load_domain_ctxt(
vd->time_ref_count.val = ctxt->time_ref_count;
vd->reference_tsc.raw = ctxt->reference_tsc;
-if ( vd->reference_tsc.fields.enabled )
+if ( vd->reference_tsc.enabled )
update_reference_tsc(d, false);
}
diff --git a/xen/arch/x86/hvm/viridian/viridian.c
b/xen/arch/x86/hvm/viridian/viridian.c
index 710470fed7..1a20d68aaf 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -192,7 +192,7 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t
leaf,
case 4:
/* Recommended hypercall usage. */
-if ( vd->guest_os_id.raw == 0 || vd->guest_os_id.fields.os < 4 )
+if ( vd->guest_os_id.raw == 0 || vd->guest_os_id.os < 4 )
break;
res->a = CPUID4A_RELAX_TIMER_INT;
if ( viridian_feature_mask(d) & HVMPV_hcall_remote_tlb_flush )
@@ -228,10 +228,8 @@ static void dump_guest_os_id(const struct domain *d)
printk(XENLOG_G_INFO
"d%d: VIRIDIAN GUEST_OS_ID: vendor: %x os: %x major: %x minor: %x
sp: %x build: %x\n",
- d->domain_id,
- goi->fields.vendor, goi->fields.os,
- goi->fields.major, goi->fields.minor,
- goi->fields.service_pack, goi->fields.build_number);
+ d->domain_id, goi->vendor, goi->os, goi->major, goi->minor,
+ goi->service_pack, goi->build_number);
}
static void dump_hypercall(const struct domain *d)
@@ -242,12 +240,12 @@ static void dump_hypercall(const struct domain *d)
printk(XENLOG_G_INFO "d%d: VIRIDIAN HYPERCALL: enabled: %x pfn: %lx\n",
d->domain_id,
- hg->fields.enabled, (unsigned long)hg->fields.pfn);
+ hg->enabled, (unsigned long)hg->pfn);
}
static void enable_hypercall_page(struct domain *d)
{
-unsigned long gmfn = d->arch.hvm.viridian->hypercall_gpa.fields.pfn;
+unsigned long gmfn = d->arch.hvm.viridian->hypercall_gpa.pfn;
struct page_info *page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
uint8_t *p;
@@ -297,7 +295,7 @@ int guest_wrmsr_viridian(struct vcpu *v, uint32_t idx,
uint64_t val)
case HV_X64_MSR_HYPERCALL:
vd->hy
Re: [Xen-devel] [PATCH v2 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU
On 2019/3/19 21:58, Jan Beulich wrote:
On 19.03.19 at 14:47, wrote:
On 2019/3/19 20:58, Jan Beulich wrote:
On 19.03.19 at 12:32, wrote:
On 2019/3/18 16:59, Jan Beulich wrote:
On 16.03.19 at 11:11, wrote:
On 2019/3/15 20:41, Jan Beulich wrote:
On 21.02.19 at 10:50, wrote:
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
switch ( current_cpu_data.x86 )
{
case 0x15:
+case 0x17:
+case 0x18:
num_counters = F15H_NUM_COUNTERS;
counters = AMD_F15H_COUNTERS;
ctrls = AMD_F15H_CTRLS;
Unless you know what AMD Fam18 will look like, you can't do it
like this. Fam18 really needs to be further qualified by a vendor
check at this point in time.
Hygon will negotiate with AMD to make sure that only Hygon should use
Fam18h.
In the success case of which please state this in the description.
Until those negotiations have succeeded I'm afraid I'm going to
insist to see the extra check added.
or just add Hygon support at beginning of amd_vpmu_init():
if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
num_counters = F15H_NUM_COUNTERS;
counters = AMD_F15H_COUNTERS;
ctrls = AMD_F15H_CTRLS;
k7_counters_mirrored = 1;
}
or perhaps even better would be two separate switch()-es, one for
AMD and one for Hygon. Possibly even a separate hygon_vpmu_init().
A separate hygon_vpmu_init() is also fine except that the last part of
the function can be shared.
So perhaps split that part out into a static _vpmu_init() or common_init()?
Okay, I'll try to split that part.
--
Regards,
Pu Wen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v10 11/11] viridian: add implementation of the HvSendSyntheticClusterIpi hypercall
This patch adds an implementation of the hypercall as documented in the
specification [1], section 10.5.2. This enlightenment, as with others, is
advertised by CPUID leaf 0x4004 and is under control of a new
'hcall_ipi' option in libxl.
If used, this enlightenment should mean the guest only takes a single VMEXIT
to issue IPIs to multiple vCPUs rather than the multiple VMEXITs that would
result from using the emulated local APIC.
[1]
https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/live/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0C.pdf
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
Reviewed-by: Jan Beulich
---
Cc: Ian Jackson
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: "Roger Pau Monné"
v4:
- Address comments from Jan
v3:
- New in v3
---
docs/man/xl.cfg.5.pod.in | 6 +++
tools/libxl/libxl.h | 6 +++
tools/libxl/libxl_dom.c | 3 ++
tools/libxl/libxl_types.idl | 1 +
xen/arch/x86/hvm/viridian/viridian.c | 63
xen/include/public/hvm/params.h | 7 +++-
6 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 355c654693..c7d70e618b 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2175,6 +2175,12 @@ ticks and hence enabling this group will ensure that
ticks will be
consistent with use of an enlightened time source (B or
B).
+=item B
+
+This set incorporates use of a hypercall for interprocessor interrupts.
+This enlightenment may improve performance of Windows guests with multiple
+virtual CPUs.
+
=item B
This is a special value that enables the default set of groups, which
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c8f219b0d3..482499a6c0 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -330,6 +330,12 @@
*/
#define LIBXL_HAVE_VIRIDIAN_STIMER 1
+/*
+ * LIBXL_HAVE_VIRIDIAN_HCALL_IPI indicates that the 'hcall_ipi' value
+ * is present in the viridian enlightenment enumeration.
+ */
+#define LIBXL_HAVE_VIRIDIAN_HCALL_IPI 1
+
/*
* LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE indicates that
* libxl_domain_build_info has the u.hvm.acpi_laptop_slate field.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2ee0f82ee7..879c806139 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -324,6 +324,9 @@ static int hvm_set_viridian_features(libxl__gc *gc,
uint32_t domid,
if (libxl_bitmap_test(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_STIMER))
mask |= HVMPV_time_ref_count | HVMPV_synic | HVMPV_stimer;
+if (libxl_bitmap_test(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_HCALL_IPI))
+mask |= HVMPV_hcall_ipi;
+
if (mask != 0 &&
xc_hvm_param_set(CTX->xch,
domid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 1cce249de4..cb4702fd7a 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -237,6 +237,7 @@ libxl_viridian_enlightenment =
Enumeration("viridian_enlightenment", [
(6, "crash_ctl"),
(7, "synic"),
(8, "stimer"),
+(9, "hcall_ipi"),
])
libxl_hdtype = Enumeration("hdtype", [
diff --git a/xen/arch/x86/hvm/viridian/viridian.c
b/xen/arch/x86/hvm/viridian/viridian.c
index dce648bb4e..4b06b78a27 100644
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@@ -28,6 +28,7 @@
#define HvFlushVirtualAddressSpace 0x0002
#define HvFlushVirtualAddressList 0x0003
#define HvNotifyLongSpinWait 0x0008
+#define HvSendSyntheticClusterIpi 0x000b
#define HvGetPartitionId 0x0046
#define HvExtCallQueryCapabilities 0x8001
@@ -95,6 +96,7 @@ typedef union _HV_CRASH_CTL_REG_CONTENTS
#define CPUID4A_HCALL_REMOTE_TLB_FLUSH (1 << 2)
#define CPUID4A_MSR_BASED_APIC (1 << 3)
#define CPUID4A_RELAX_TIMER_INT(1 << 5)
+#define CPUID4A_SYNTHETIC_CLUSTER_IPI (1 << 10)
/* Viridian CPUID leaf 6: Implementation HW features detected and in use */
#define CPUID6A_APIC_OVERLAY(1 << 0)
@@ -206,6 +208,8 @@ void cpuid_viridian_leaves(const struct vcpu *v, uint32_t
leaf,
res->a |= CPUID4A_HCALL_REMOTE_TLB_FLUSH;
if ( !cpu_has_vmx_apic_reg_virt )
res->a |= CPUID4A_MSR_BASED_APIC;
+if ( viridian_feature_mask(d) & HVMPV_hcall_ipi )
+res->a |= CPUID4A_SYNTHETIC_CLUSTER_IPI;
/*
* This value is the recommended number of attempts to try to
@@ -628,6 +632,65 @@ int viridian_hypercall(struct cpu_user_regs *regs)
break;
}
+case HvSendSyntheticClusterIpi:
+{
+struct vcpu *v;
+uint32_t vector;
+uint64_t vcpu_mask;
+
+status = HV_STATUS_INVALID_PARAMETER;
+
+/* Get input parameters. */
+if ( input.fast )
+{
+
[Xen-devel] [PATCH v10 10/11] viridian: add implementation of synthetic timers
This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs
and hence a the first SynIC message source.
The new (and documented) 'stimer' viridian enlightenment group may be
specified to enable this feature.
While in the neighbourhood, this patch adds a missing check for an
attempt to write the time reference count MSR, which should result in an
exception (but not be reported as an unimplemented MSR).
NOTE: It is necessary for correct operation that timer expiration and
message delivery time-stamping use the same time source as the guest.
The specification is ambiguous but testing with a Windows 10 1803
guest has shown that using the partition reference counter as a
source whilst the guest is using RDTSC and the reference tsc page
does not work correctly. Therefore the time_now() function is used.
This implements the algorithm for acquiring partition reference time
that is documented in the specifiction.
Signed-off-by: Paul Durrant
Acked-by: Wei Liu
---
Cc: Ian Jackson
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: "Roger Pau Monné"
v10:
- Make sure that reading the config MSR or a single-shot timer clears
the enabled bit if the timer has expired (regardless of whether the
message has been delivered or not)
v9:
- Revert some of the changes in v8 to make sure that the timer config
is only touched in current context or when the vcpu is not running
v8:
- Squash in
https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg01333.html
v7:
- Make sure missed count cannot be zero if expiration < now
v6:
- Stop using the reference tsc page in time_now()
- Address further comments from Jan
v5:
- Fix time_now() to read TSC as the guest would see it
v4:
- Address comments from Jan
v3:
- Re-worked missed ticks calculation
---
docs/man/xl.cfg.5.pod.in | 12 +-
tools/libxl/libxl.h| 6 +
tools/libxl/libxl_dom.c| 4 +
tools/libxl/libxl_types.idl| 1 +
xen/arch/x86/hvm/viridian/private.h| 9 +-
xen/arch/x86/hvm/viridian/synic.c | 55 +++-
xen/arch/x86/hvm/viridian/time.c | 397 -
xen/arch/x86/hvm/viridian/viridian.c | 5 +
xen/include/asm-x86/hvm/viridian.h | 32 +-
xen/include/public/arch-x86/hvm/save.h | 2 +
xen/include/public/hvm/params.h| 7 +-
11 files changed, 517 insertions(+), 13 deletions(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index ad81af1ed8..355c654693 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -2167,11 +2167,19 @@ This group incorporates the crash control MSRs. These
enlightenments
allow Windows to write crash information such that it can be logged
by Xen.
+=item B
+
+This set incorporates the SynIC and synthetic timer MSRs. Windows will
+use synthetic timers in preference to emulated HPET for a source of
+ticks and hence enabling this group will ensure that ticks will be
+consistent with use of an enlightened time source (B or
+B).
+
=item B
This is a special value that enables the default set of groups, which
-is currently the B, B, B, B
-and B groups.
+is currently the B, B, B, B,
+B and B groups.
=item B
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index a923a380d3..c8f219b0d3 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -324,6 +324,12 @@
*/
#define LIBXL_HAVE_VIRIDIAN_SYNIC 1
+/*
+ * LIBXL_HAVE_VIRIDIAN_STIMER indicates that the 'stimer' value
+ * is present in the viridian enlightenment enumeration.
+ */
+#define LIBXL_HAVE_VIRIDIAN_STIMER 1
+
/*
* LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE indicates that
* libxl_domain_build_info has the u.hvm.acpi_laptop_slate field.
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fb758d2ac3..2ee0f82ee7 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -269,6 +269,7 @@ static int hvm_set_viridian_features(libxl__gc *gc,
uint32_t domid,
libxl_bitmap_set(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_TIME_REF_COUNT);
libxl_bitmap_set(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_APIC_ASSIST);
libxl_bitmap_set(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_CRASH_CTL);
+libxl_bitmap_set(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_STIMER);
}
libxl_for_each_set_bit(v, info->u.hvm.viridian_enable) {
@@ -320,6 +321,9 @@ static int hvm_set_viridian_features(libxl__gc *gc,
uint32_t domid,
if (libxl_bitmap_test(&enlightenments, LIBXL_VIRIDIAN_ENLIGHTENMENT_SYNIC))
mask |= HVMPV_synic;
+if (libxl_bitmap_test(&enlightenments,
LIBXL_VIRIDIAN_ENLIGHTENMENT_STIMER))
+mask |= HVMPV_time_ref_count | HVMPV_synic | HVMPV_stimer;
+
if (mask != 0 &&
xc_hvm_param_set(CTX->xch,
domid,
diff --git a/tools
[Xen-devel] [PULL 0/1] xen queue 2019-03-19
The following changes since commit b98a66201dbc7cf3b962f4bb260f66100cc75578: Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-4.0-rc0-2' into staging (2019-03-19 12:55:02 +) are available in the Git repository at: https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git tags/pull-xen-20190319 for you to fetch changes up to 4158e93f4aced247c8db94a0275fc027da7dc97e: xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored (2019-03-19 15:32:13 +) Xen queue Fix a bug on FreeBSD when doing a migration. Roger Pau Monne (1): xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored hw/i386/xen/xen-mapcache.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 1/1] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored
From: Roger Pau Monne
Or if it's not possible to honor the hinted address an error is returned
instead. This makes it easier to spot the actual failure, instead of
failing later on when the caller of xen_remap_bucket realizes the
mapping has not been created at the requested address.
Also note that at least on FreeBSD using MAP_FIXED will cause mmap to
try harder to honor the passed address.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
Acked-by: Anthony PERARD
Reviewed-by: Igor Druzhinin
Message-Id: <20190318173731.14494-1-roger@citrix.com>
Signed-off-by: Anthony PERARD
---
hw/i386/xen/xen-mapcache.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index 349f72d00c..254759f776 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -184,9 +184,14 @@ static void xen_remap_bucket(MapCacheEntry *entry,
pfns[i] = (address_index << (MCACHE_BUCKET_SHIFT-XC_PAGE_SHIFT)) + i;
}
+/*
+ * If the caller has requested the mapping at a specific address use
+ * MAP_FIXED to make sure it's honored.
+ */
if (!dummy) {
vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid, vaddr,
- PROT_READ | PROT_WRITE, 0,
+ PROT_READ | PROT_WRITE,
+ vaddr ? MAP_FIXED : 0,
nb_pfn, pfns, err);
if (vaddr_base == NULL) {
perror("xenforeignmemory_map2");
@@ -198,7 +203,8 @@ static void xen_remap_bucket(MapCacheEntry *entry,
* mapping immediately due to certain circumstances (i.e. on resume
now)
*/
vaddr_base = mmap(vaddr, size, PROT_READ | PROT_WRITE,
- MAP_ANON | MAP_SHARED, -1, 0);
+ MAP_ANON | MAP_SHARED | (vaddr ? MAP_FIXED : 0),
+ -1, 0);
if (vaddr_base == MAP_FAILED) {
perror("mmap");
exit(-1);
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/3] mwait-idle: add enablement for AMD Naples and Rome
On 3/15/19 3:54 AM, Jan Beulich wrote: On 14.03.19 at 20:29, wrote: >> On 3/13/19 4:51 AM, Jan Beulich wrote: >> On 25.02.19 at 21:24, wrote: Add the needed data structures for enabling Naples (F17h M01h). Since Rome (F17h M31h) has the same c-state latencies and entry methods, the c-state information can be used for Rome as well. For both Naples and Rome, mwait is used for c1 (cc1) and halt is functionally the same as c2 (cc6). If c2 (cc6) is disabled in BIOS, then halt functions similar to c1 (cc1). >>> >>> But your code does not detect this situation, and does hence not update >>> the table used accordingly. Why is this? Is entering C1 cheaper one way >>> or the other in this situation (in which case the cheaper approach should >>> always be used)? >> >> Well, if Xen had an AML interrupter, we could use the ACPI tables like >> we do in Linux, but Xen doesn't (which is why we're hard coding it). > > But the necessary data gets uploaded by the ACPI code in Dom0. Or > else there wouldn't be a point to have an ACPI idle driver in Xen in the > first place. > > We should add custom (vendor specific) code to Xen only if there > are clear advantages over the ACPI based approach, and so far > the patch descriptions don't make clear what advantages there > are (besides becoming independent of Dom0, which I'd consider > marginal). > I'll update the patches to explain why this is needed (aka, unreliable (PV dom0) or no passing (PVH dom0) of the ACPI tables back to Xen. >> mwait has the CPUID_Fn0005_EDX MSR but since we don't have a mwait >> support for CC6, we can't use that. There's another register we _might_ >> be able to use, but support for CC6 is AND'd with that and another >> another register (we don't have access to). The register we'd read is >> also RW. So I'm not sure I trust it. > > It's hard to believe that one can't find out whether HLT would enter > only CC1 or eventually also CC6. > > Jan > There's a register, but it's AND'd with firmware for if C6 is enabled. Assuming it isn't touched, it should be able to determine if C6 is enabled or not by BIOS. That leads to more code and the negative of not checking is system thinking it's using CC6 when it's really using CC1. It's also NDA'd so I'd have to get approval to use it (and then also put it in the public PPR). Brian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] libxc: fix HVM core dump
f969bc9fc96 forbid get_address_size call on HVM guests, because that
didn't make sense. It broke core dump functionality on HVM because
libxc unconditionally asked for guest width.
Only issue the call when necessary in libxc.
Reported-by: Igor Druzhinin
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Igor Druzhinin
Cc: Juergen Gross
Juergen, this is probably too late for 4.12, but you can at least add
a release note somewhere.
Ian, please backport this to 4.12.
---
tools/libxc/xc_core.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tools/libxc/xc_core.c b/tools/libxc/xc_core.c
index e581905ba9..c825b5b0a0 100644
--- a/tools/libxc/xc_core.c
+++ b/tools/libxc/xc_core.c
@@ -459,12 +459,6 @@ xc_domain_dumpcore_via_callback(xc_interface *xch,
struct xc_core_section_headers *sheaders = NULL;
Elf64_Shdr *shdr;
-if ( xc_domain_get_guest_width(xch, domid, &dinfo->guest_width) != 0 )
-{
-PERROR("Could not get address size for domain");
-return sts;
-}
-
xc_core_arch_context_init(&arch_ctxt);
if ( (dump_mem_start = malloc(DUMP_INCREMENT*PAGE_SIZE)) == NULL )
{
@@ -487,6 +481,13 @@ xc_domain_dumpcore_via_callback(xc_interface *xch,
}
auto_translated_physmap = xc_core_arch_auto_translated_physmap(&info);
+if ( !auto_translated_physmap &&
+ xc_domain_get_guest_width(xch, domid, &dinfo->guest_width) != 0 )
+{
+PERROR("Could not get address size for domain");
+goto out;
+}
+
if ( domid != info.domid )
{
PERROR("Domain %d does not exist", domid);
@@ -742,7 +743,10 @@ xc_domain_dumpcore_via_callback(xc_interface *xch,
goto out;
/* elf note section: xen version */
-sts = elfnote_dump_xen_version(xch, args, dump_rtn, dinfo->guest_width);
+sts = elfnote_dump_xen_version(xch, args, dump_rtn,
+ auto_translated_physmap ?
+ sizeof(unsigned long):
+ dinfo->guest_width);
if ( sts != 0 )
goto out;
--
2.20.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt
On 3/15/19 3:37 AM, Jan Beulich wrote:
On 14.03.19 at 20:00, wrote:
>> On 3/13/19 4:35 AM, Jan Beulich wrote:
>> On 25.02.19 at 21:23, wrote:
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -103,6 +103,11 @@ static const struct cpuidle_state {
#define CPUIDLE_FLAG_DISABLED 0x1
/*
+ * On certain AMD families that support mwait, only c1 can be reached by
+ * mwait and to reach c2, halt has to be used.
+ */
+#define CPUIDLE_FLAG_USE_HALT 0x2
>>>
>>> Could you point us at where in the manuals this behavior is described?
>>> While PM Vol 2 has a chapter talking about P-states, I can't seem to
>>> find any mention of C-states there.
>>
>> IIRC it's in the NDA PPR and internally it's in some other documents.
>> We don't have support to use mwait while in CC6 due to caches being
>> turned off etc. If we did have mwait suport for CC6, we'd use that here
>> (basically mirroring Intel). Sadly I don't think we have any public
>> information directly detailing this information. If you'd like, I can
>> look further into it.
>
> Ah yes, I found it. But the text suggests to use SystemIO, not
> HLT for entering C2 (CC6). An important difference looks to be
> the state of EFLAGS.IF as to whether the core wakes up again.
> The SystemIO approach would better match the FFixedHW one,
> as we require and use MWAIT_ECX_INTERRUPT_BREAK.
>
> Furthermore I'm then once again wondering what the gain is
> over using the ACPI driver: The suggested _CST looks to exactly
> match the data you enter into the table in the later patch. IOW
> my fundamental concern didn't go away yet: As per the name
> of the driver, it shouldn't really need to support HLT (or anything
> other than MWAIT) as an entry method. Hence I think that at
> the very least you need to extend the description of the change
> quite a bit to explain why the ACPI driver is not suitable.
>
> Depending on how this comes out, it may then still be a matter
> of discussing whether, rather than fiddling with mwait-idle, it
> wouldn't be better to have an AMD-specific driver instead. Are
> there any thoughts in similar directions for Linux?
I can make it use sysIO rather than HLT if there's a need or strong
desire for it. I used HLT mainly because I thought it would be more
robust (like in the case of CC6 being disabled).
Because:
#1 getting the ACPI tables from dom0 is either unreliable (PV dom0) or
not possible (PVH dom0).
#2 the changes to the Intel code are minimal.
#3 worse case, Xen thinks it's using CC6 when it's using CC1. Not
perfect but far from fatal or breaking.
In Linux, they have a working AML interrupter so they just read the ACPI
tables. If Xen had a working AML interrupter, I'd suggest just reading
the ACPI tables as well. As far as a completely different driver for
AMD, it would mostly just be the Intel drive with the small changes and
some code removed. With the minimal changes needed, I don't see a
reason, but that's just me.
+ case ACPI_CSTATE_EM_HALT:
+ info = get_cpu_info();
+ spec_ctrl_enter_idle(info);
+ safe_halt();
+ spec_ctrl_exit_idle(info);
>>>
>>> ... wouldn't it be better to avoid the redundancy with default_idle(),
>>> by introducing a new helper function, e.g. spec_ctrl_safe_halt()?
>>>
>> See my email with Wei about this.
>
> There you've basically settled on making a helper function, to
> be used in pre-existing places as well as here.
>
> I've also just noticed that there's another safe_halt() invocation
> a few lines up from here, as a fallback. It doesn't come with any
> of the statistics though, so would probably be unsuitable to
> funnel into.
It does use follow the pattern of:
spec_ctrl_enter_idle(info);
safe_halt();
spec_ctrl_exit_idle(info);
though. I'm pretty sure out would work with what I suggested or am I
missing something?
@@ -1221,7 +1242,12 @@ static int mwait_idle_cpu_init(struct
notifier_block *nfb,
cx = dev->states + dev->count;
cx->type = state;
cx->address = hint;
- cx->entry_method = ACPI_CSTATE_EM_FFH;
+
+ if (flags & CPUIDLE_FLAG_USE_HALT)
+ cx->entry_method = ACPI_CSTATE_EM_HALT;
+ else
+ cx->entry_method = ACPI_CSTATE_EM_FFH;
>>>
>>> I'd prefer if you used a conditional expression here. One of the goals for
>>> any changes to this file should be to limit the delta to its Linux
>>> original, in
>>> order to increase the chances of patches coming from there to apply
>>> reasonably cleanly here.
>>>
>>> Doing so would also save me from complaining about the stray blank
>>> ahead of "else".
>>
>> By conditional statement you mean ternary? If so, that'll be easy enough.
>
> Yes.
>
[Xen-devel] [PATCH 0/3] docs: User oriented documentation
This is a project I've been musing over for a long time now, to try and address Xen's almost complete absense of documentation. This series, plus some other in-progress conversion of the command line doc, is available to view at: https://andrewcoop-xen.readthedocs.io/en/latest/ This is read-the-docs's automatic CI build of documentation from a branch on gitlab. Observe that the docs don't look like they are out of the 90's, and are automatically translated into PDF and ePUB format as well. In due course I'll see about updating xenbits.xen.org/docs to render this as well, but I don't have sufficient tuits at the moment. Andrew Cooper (3): docs/sphinx: Skeleton setup docs/rst: Use pandoc to render ReStructuredText docs/admin-guide: Boot time microcode loading docs/Makefile | 24 +++- docs/admin-guide/index.rst | 5 + docs/admin-guide/microcode-loading.rst | 103 ++ docs/conf.py | 193 + docs/index.rst | 10 ++ docs/sphinx/requirements.txt | 3 + 6 files changed, 336 insertions(+), 2 deletions(-) create mode 100644 docs/admin-guide/index.rst create mode 100644 docs/admin-guide/microcode-loading.rst create mode 100644 docs/conf.py create mode 100644 docs/index.rst create mode 100644 docs/sphinx/requirements.txt -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/3] docs/sphinx: Skeleton setup
Sphinx is a documentation system, which is popular for technical writing. It
uses ReStructuredText as its markup syntax, and is designed for whole-project
documentation, rather than the misc assortment of individual files that we
currently have.
This is a skeleton setup which just enough infrastructure to render an empty
set of pages. It will become better integrated into Xen's docs system when it
becomes less WIP.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
CC: Roger Pau Monné
CC: Lars Kurth
---
docs/Makefile| 12 +++
docs/conf.py | 193 +++
docs/index.rst | 2 +
docs/sphinx/requirements.txt | 3 +
4 files changed, 210 insertions(+)
create mode 100644 docs/conf.py
create mode 100644 docs/index.rst
create mode 100644 docs/sphinx/requirements.txt
diff --git a/docs/Makefile b/docs/Makefile
index 44aebf0..eda4bd8 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -37,6 +37,18 @@ all: build
.PHONY: build
build: html txt pdf man-pages figs
+# WIP Sphinx/RST documentation. Use virtualenv to get a suitable environment
+#
+# xen.git$ virtualenv venv-docs
+# xen.git$ . venv-docs/bin/activate
+# (venv-docs)xen.git$ pip install -r docs/sphinx/requirements.txt
+# (venv-docs)xen.git$ make -C docs/ sphinx-html
+# (venv-docs)xen.git$ deactivate
+# xen.git$
+.PHONY: sphinx-html
+sphinx-html:
+ sphinx-build -b html . sphinx/html
+
.PHONY: html
html: $(DOC_HTML) html/index.html
diff --git a/docs/conf.py b/docs/conf.py
new file mode 100644
index 000..73b7b9b
--- /dev/null
+++ b/docs/conf.py
@@ -0,0 +1,193 @@
+# -*- coding: utf-8 -*-
+#
+# Configuration file for the Sphinx documentation builder.
+#
+# This file does only contain a selection of the most common options. For a
+# full list see the documentation:
+# http://www.sphinx-doc.org/en/master/config
+
+# -- Path setup --
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#
+# import os
+# import sys
+# sys.path.insert(0, os.path.abspath('.'))
+
+
+# -- Project information -
+
+project = u'Xen'
+copyright = u'2019, The Xen development community'
+author = u'The Xen development community'
+
+# Pull the Xen version straight out of the Makefile
+try:
+xen_ver = xen_subver = xen_extra = None
+
+for line in open(u"../xen/Makefile"):
+if line.startswith(u"export XEN_VERSION"):
+xen_ver = line.split(u"=")[1].strip()
+elif line.startswith(u"export XEN_SUBVERSION"):
+xen_subver = line.split(u"=")[1].strip()
+elif line.startswith(u"export XEN_EXTRAVERSION"):
+xen_extra = line.split(u"=")[1].split(u"$", 1)[0].strip()
+except:
+pass
+finally:
+if xen_ver and xen_subver and xen_extra:
+version = xen_ver + u"." + xen_subver
+release = version + xen_extra
+else:
+version = release = u"unknown version"
+
+# -- General configuration ---
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#
+needs_sphinx = '1.4'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = []
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+#
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The master toctree document.
+master_doc = 'index'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+# This pattern also affects html_static_path and html_extra_path.
+exclude_patterns = [u'sphinx/output', 'Thumbs.db', '.DS_Store']
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = None
+
+primary_domain = 'c'
+highlight_language = 'none'
+
+# -- Options for HTML output -
+
+# The theme to use for HTML and HTML Help pages. See the documentation for
+# a list of builtin themes.
+#
+try:
+import sphinx_rtd_theme
+html_theme = 'sphinx_rtd_theme'
+html_theme_path = [sphinx_rtd_theme.get_html_them
[Xen-devel] [PATCH 2/3] docs/rst: Use pandoc to render ReStructuredText
Sphinx uses ReStructuredText as its markup format. Although missing the project wide integration, individual *.rst files can be rendered by pandoc to suppliement our existing ad-hoc documentation. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Wei Liu CC: Julien Grall CC: Roger Pau Monné CC: Lars Kurth --- docs/Makefile | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/docs/Makefile b/docs/Makefile index eda4bd8..0c1228c 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -11,6 +11,8 @@ MAN_SECTIONS:= 1 5 7 8 # Documentation sources to build MAN-SRC-y := $(sort $(basename $(wildcard man/*.pod man/*.pandoc))) +RST-SRC-y := $(sort $(filter-out %index.rst,$(shell find * -type f -name '*.rst' -print))) + TXTSRC-y := $(sort $(shell find misc -name '*.txt' -print)) PANDOCSRC-y := $(sort $(shell find designs/ features/ misc/ process/ specs/ -name '*.pandoc' -print)) @@ -22,13 +24,16 @@ $(foreach i,$(MAN_SECTIONS), \ DOC_HTML := html/SUPPORT.html \ $(patsubst %.pandoc,html/%.html,$(PANDOCSRC-y)) \ +$(patsubst %.rst,html/%.html,$(RST-SRC-y)) \ $(patsubst %,html/%.html,$(MAN-SRC-y)) \ $(patsubst %.txt,html/%.txt,$(TXTSRC-y)) \ $(patsubst %,html/hypercall/%/index.html,$(DOC_ARCHES)) DOC_TXT := $(patsubst %.txt,txt/%.txt,$(TXTSRC-y)) \ $(patsubst %.pandoc,txt/%.txt,$(PANDOCSRC-y)) \ +$(patsubst %.rst,txt/%.txt,$(RST-SRC-y)) \ $(patsubst %,txt/%.txt,$(MAN-SRC-y)) -DOC_PDF := $(patsubst %.pandoc,pdf/%.pdf,$(PANDOCSRC-y)) +DOC_PDF := $(patsubst %.pandoc,pdf/%.pdf,$(PANDOCSRC-y)) \ +$(patsubst %.rst,pdf/%.pdf,$(RST-SRC-y)) # Top level build targets .PHONY: all @@ -71,7 +76,7 @@ clean: clean-man-pages $(MAKE) -C figs clean rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ rm -rf *.ilg *.log *.ind *.toc *.bak *.tmp core - rm -rf html txt pdf + rm -rf html txt pdf sphinx/html .PHONY: distclean distclean: clean @@ -232,8 +237,11 @@ define GENERATE_PANDOC_RULE $(call GENERATE_PANDOC_RULE_RAW,$(1)/%.$(1),%.$(2)) endef $(eval $(call GENERATE_PANDOC_RULE,pdf,pandoc)) # pdf/%.pdf: %.pandoc +$(eval $(call GENERATE_PANDOC_RULE,pdf,rst)) # pdf/%.pdf: %.rst $(eval $(call GENERATE_PANDOC_RULE,txt,pandoc)) # txt/%.txt: %.pandoc +$(eval $(call GENERATE_PANDOC_RULE,txt,rst)) # txt/%.txt: %.rst $(eval $(call GENERATE_PANDOC_RULE,html,pandoc)) # html/%.html: %.pandoc +$(eval $(call GENERATE_PANDOC_RULE,html,rst)) # html/%.html: %.rst $(eval $(call GENERATE_PANDOC_RULE_RAW,html/SUPPORT.html,$(XEN_ROOT)/SUPPORT.md)) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/3] docs/admin-guide: Boot time microcode loading
Recent discussion on xen-devel has demonstrated that Xen existing microcode loading support isn't adequately documented. Take the opportunity to address this, and start some end-user focused documentation. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Tim Deegan CC: Wei Liu CC: Julien Grall CC: Roger Pau Monné CC: Lars Kurth I've deliberately omitted runtime microcode loading at this point, because it is currently rather broken and its implementation is in flux. This document can be extended in due course. --- docs/admin-guide/index.rst | 5 ++ docs/admin-guide/microcode-loading.rst | 103 + docs/index.rst | 8 +++ 3 files changed, 116 insertions(+) create mode 100644 docs/admin-guide/index.rst create mode 100644 docs/admin-guide/microcode-loading.rst diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst new file mode 100644 index 000..4d9bcb4 --- /dev/null +++ b/docs/admin-guide/index.rst @@ -0,0 +1,5 @@ +User documentation +== + +.. toctree:: + microcode-loading diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst new file mode 100644 index 000..58393b8 --- /dev/null +++ b/docs/admin-guide/microcode-loading.rst @@ -0,0 +1,103 @@ +Microcode Loading += + +Like many other pieces of hardware, CPUs themselves have errata which are +discovered after shipping, and need to be addressed in the field. Microcode +can be considered as firmware for the processor, and new microcode is +published as needed by the processor vendors. + +Microcode is included as part of the system firmware by an OEM, and a system +firmware update is the preferred way of obtaining updated microcode. However, +this is often not the most expedient way to get updated microcode, so Xen +supports loading microcode itself. + +Distros typically package microcode updates for users, and may provide hooks +to cause microcode to be automatically loaded at boot time. Consult your dom0 +distro guidance for microcode loading. + +Microcode can make almost arbitrary changes to the processor, including to +software visible features. This includes removing features (e.g. the Haswell +TSX errata which necessitated disabling the feature entirely), or the addition +of brand new features (e.g. the Spectre v2 controls to work around speculative +execution vulnerabilities). + + +Boot time microcode loading +--- + +Where possible, microcode should be loaded at boot time. This allows the CPU +to be updated to its eventual configuration before Xen starts making setup +decisions based on the visible features. + +Xen will report during boot if it performed a microcode update. e.g.:: + + [root@host ~]# xl dmesg | grep microcode + (XEN) microcode: CPU0 updated from revision 0x1a to 0x25, date = 2018-04-02 + (XEN) microcode: CPU2 updated from revision 0x1a to 0x25, date = 2018-04-02 + (XEN) microcode: CPU4 updated from revision 0x1a to 0x25, date = 2018-04-02 + (XEN) microcode: CPU6 updated from revision 0x1a to 0x25, date = 2018-04-02 + +The exact details printed are system and microcode specific. After boot, the +current microcode version can obtained from with dom0. e.g.:: + + [root@host ~]# head /proc/cpuinfo + processor: 0 + vendor_id: GenuineIntel + cpu family : 6 + model: 60 + model name : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz + stepping : 3 + microcode: 0x25 + cpu MHz : 3392.148 + cache size : 8192 KB + physical id : 0 + + +Loading microcode from a single file + + +Xen handles microcode blobs in the binary form shipped by vendors, which is +also the form the processor uses. This binary form contains header +information which Xen and various userspace tools can use to identify the +correct blob for a specific CPU. + +Tools such as dracut will identify the correct blob for the current CPU, which +will be a few kilobytes, for minimal overhead during boot. + +Additionally, Xen is capable of handling a number of blobs concatenated +together, and will locate the appropriate blob based on the header +information. + +This option is less efficient during boot, but may be preferred in situations +where the exact CPU details aren't known ahead of booting (e.g. install +media). + +The file containing the blob(s) needs to be accessible to Xen as early as +possible. + +* For multiboot/multiboot2 boots, this is achieved by loading the blob as a + multiboot module. The ``ucode=$num`` command line option can be used to + identify which multiboot module contains the microcode, including negative + indexing to count from the end. + +* For EFI boots, there isn't really a concept of modules. A microcode file + can be specified in the EFI configuration file with ``ucode=$file``. Us
Re: [Xen-devel] [PULL 0/1] xen queue 2019-03-19
On Tue, 19 Mar 2019 at 15:45, Anthony PERARD wrote: > > The following changes since commit b98a66201dbc7cf3b962f4bb260f66100cc75578: > > Merge remote-tracking branch > 'remotes/palmer/tags/riscv-for-master-4.0-rc0-2' into staging (2019-03-19 > 12:55:02 +) > > are available in the Git repository at: > > https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git > tags/pull-xen-20190319 > > for you to fetch changes up to 4158e93f4aced247c8db94a0275fc027da7dc97e: > > xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored > (2019-03-19 15:32:13 +) > > > Xen queue > > Fix a bug on FreeBSD when doing a migration. > > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0 for any user-visible changes. -- PMM ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/3] docs/admin-guide: Boot time microcode loading
>>> On 19.03.19 at 17:20, wrote: > Recent discussion on xen-devel has demonstrated that Xen existing microcode > loading support isn't adequately documented. Take the opportunity to address > this, and start some end-user focused documentation. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v10 10/11] viridian: add implementation of synthetic timers
>>> On 19.03.19 at 16:22, wrote: > This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs > and hence a the first SynIC message source. > > The new (and documented) 'stimer' viridian enlightenment group may be > specified to enable this feature. > > While in the neighbourhood, this patch adds a missing check for an > attempt to write the time reference count MSR, which should result in an > exception (but not be reported as an unimplemented MSR). > > NOTE: It is necessary for correct operation that timer expiration and > message delivery time-stamping use the same time source as the guest. > The specification is ambiguous but testing with a Windows 10 1803 > guest has shown that using the partition reference counter as a > source whilst the guest is using RDTSC and the reference tsc page > does not work correctly. Therefore the time_now() function is used. > This implements the algorithm for acquiring partition reference time > that is documented in the specifiction. > > Signed-off-by: Paul Durrant > Acked-by: Wei Liu Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 39/55] x86: switch root_pgt to mfn_t and use new APIs
On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote:
> This then requires moving declaration of root page table mfn into
> mm.h
> and modify setup_cpu_root_pgt to have a single exit path.
>
> We also need to force map_domain_page to use direct map when
> switching
> per-domain mappings. This is contrary to our end goal of removing
> direct map, but this will be removed once we make map_domain_page
> context-switch safe in another (large) patch series.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/domain.c | 15 ---
> xen/arch/x86/domain_page.c | 2 +-
> xen/arch/x86/mm.c | 2 +-
> xen/arch/x86/pv/domain.c| 2 +-
> xen/arch/x86/smpboot.c | 40 +++--
> ---
> xen/include/asm-x86/mm.h| 2 ++
> xen/include/asm-x86/processor.h | 1 -
> 7 files changed, 44 insertions(+), 20 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 32dc4253ff..603495e55a 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -68,6 +68,7 @@
> #include
> #include
> #include
> +#include
>
> DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
>
> @@ -1589,12 +1590,20 @@ void paravirt_ctxt_switch_from(struct vcpu
> *v)
>
> void paravirt_ctxt_switch_to(struct vcpu *v)
> {
> -root_pgentry_t *root_pgt = this_cpu(root_pgt);
> +mfn_t rpt_mfn = this_cpu(root_pgt_mfn);
>
> -if ( root_pgt )
> -root_pgt[root_table_offset(PERDOMAIN_VIRT_START)] =
> +if ( !mfn_eq(rpt_mfn, INVALID_MFN) )
> +{
> +root_pgentry_t *rpt;
> +
> +mapcache_override_current(INVALID_VCPU);
Can you elaborate why this is required? A comment might help. I assume
this forces the root pt to be mapped in idle domain context instead of
current vcpu?
- Stefan
> +rpt = map_xen_pagetable_new(rpt_mfn);
> +rpt[root_table_offset(PERDOMAIN_VIRT_START)] =
> l4e_from_page(v->domain->arch.perdomain_l3_pg,
> __PAGE_HYPERVISOR_RW);
> +UNMAP_XEN_PAGETABLE_NEW(rpt);
> +mapcache_override_current(NULL);
> +}
>
> if ( unlikely(v->arch.dr7 & DR7_ACTIVE_MASK) )
> activate_debugregs(v);
> diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
> index 24083e9a86..cfcffd35f3 100644
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -57,7 +57,7 @@ static inline struct vcpu
> *mapcache_current_vcpu(void)
> return v;
> }
>
> -void __init mapcache_override_current(struct vcpu *v)
> +void mapcache_override_current(struct vcpu *v)
> {
> this_cpu(override) = v;
> }
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 9e115ef0b8..44c9df5c9e 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -564,7 +564,7 @@ void write_ptbase(struct vcpu *v)
> if ( is_pv_vcpu(v) && v->domain->arch.pv.xpti )
> {
> cpu_info->root_pgt_changed = true;
> -cpu_info->pv_cr3 = __pa(this_cpu(root_pgt));
> +cpu_info->pv_cr3 = mfn_to_maddr(this_cpu(root_pgt_mfn));
> if ( new_cr4 & X86_CR4_PCIDE )
> cpu_info->pv_cr3 |= get_pcid_bits(v, true);
> switch_cr3_cr4(v->arch.cr3, new_cr4);
> diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> index 7e84b04082..2fd944b7e3 100644
> --- a/xen/arch/x86/pv/domain.c
> +++ b/xen/arch/x86/pv/domain.c
> @@ -303,7 +303,7 @@ static void _toggle_guest_pt(struct vcpu *v)
> struct cpu_info *cpu_info = get_cpu_info();
>
> cpu_info->root_pgt_changed = true;
> -cpu_info->pv_cr3 = __pa(this_cpu(root_pgt)) |
> +cpu_info->pv_cr3 = mfn_to_maddr(this_cpu(root_pgt_mfn)) |
> (d->arch.pv.pcid ? get_pcid_bits(v, true)
> : 0);
> }
>
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index a9a39cea6e..32dce00d10 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -819,7 +819,7 @@ static int clone_mapping(const void *ptr,
> root_pgentry_t *rpt)
> return rc;
> }
>
> -DEFINE_PER_CPU(root_pgentry_t *, root_pgt);
> +DEFINE_PER_CPU(mfn_t, root_pgt_mfn);
>
> static root_pgentry_t common_pgt;
>
> @@ -827,19 +827,27 @@ extern const char _stextentry[], _etextentry[];
>
> static int setup_cpu_root_pgt(unsigned int cpu)
> {
> -root_pgentry_t *rpt;
> +root_pgentry_t *rpt = NULL;
> +mfn_t rpt_mfn;
> unsigned int off;
> int rc;
>
> if ( !opt_xpti_hwdom && !opt_xpti_domu )
> -return 0;
> +{
> +rc = 0;
> +goto out;
> +}
>
> -rpt = alloc_xen_pagetable();
> -if ( !rpt )
> -return -ENOMEM;
> +rpt_mfn = alloc_xen_pagetable_new();
> +if ( mfn_eq(rpt_mfn, INVALID_MFN) )
> +{
> +rc = -ENOMEM;
> +goto out;
> +}
>
> +rpt = map_xen_pagetable_new(rpt_mfn);
> clear_page(rpt);
> -per_cpu(root_pgt, cpu) = rpt;
> +per_cpu(root_pgt_mfn, cpu) = rpt_mfn;
>
> r
Re: [Xen-devel] [PATCH RFC 41/55] x86_64/mm: map and unmap page tables in m2p_mapped
On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/x86_64/mm.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index 216f97c95f..2b88a1af37 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -130,28 +130,36 @@ static int m2p_mapped(unsigned long spfn)
> {
> unsigned long va;
> l3_pgentry_t *l3_ro_mpt;
> -l2_pgentry_t *l2_ro_mpt;
> +l2_pgentry_t *l2_ro_mpt = NULL;
> +int rc = M2P_NO_MAPPED;
>
> va = RO_MPT_VIRT_START + spfn *
> sizeof(*machine_to_phys_mapping);
> -l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
> +l3_ro_mpt = map_xen_pagetable_new(
> +l4e_get_mfn(idle_pg_table[l4_table_offset(va)]));
>
> switch ( l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
> (_PAGE_PRESENT |_PAGE_PSE))
> {
> case _PAGE_PSE|_PAGE_PRESENT:
> -return M2P_1G_MAPPED;
> +rc = M2P_1G_MAPPED;
> +goto out;
> /* Check for next level */
> case _PAGE_PRESENT:
> break;
> default:
> -return M2P_NO_MAPPED;
> +rc = M2P_NO_MAPPED;
nit: This assignment is redundant now, but it might stay for clarity.
- Stefan
> +goto out;
> }
> -l2_ro_mpt = l3e_to_l2e(l3_ro_mpt[l3_table_offset(va)]);
> +l2_ro_mpt = map_xen_pagetable_new(
> +l3e_get_mfn(l3_ro_mpt[l3_table_offset(va)]));
>
> if (l2e_get_flags(l2_ro_mpt[l2_table_offset(va)]) &
> _PAGE_PRESENT)
> -return M2P_2M_MAPPED;
> +rc = M2P_2M_MAPPED;
>
> -return M2P_NO_MAPPED;
> + out:
> +UNMAP_XEN_PAGETABLE_NEW(l2_ro_mpt);
> +UNMAP_XEN_PAGETABLE_NEW(l3_ro_mpt);
> +return rc;
> }
>
> static int share_hotadd_m2p_table(struct mem_hotadd_info *info)
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 42/55] x86_64/mm: map and unmap page tables in share_hotadd_m2p_table
On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/x86_64/mm.c | 31 +++
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index 2b88a1af37..597d8e9ed8 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -166,8 +166,8 @@ static int share_hotadd_m2p_table(struct
> mem_hotadd_info *info)
> {
> unsigned long i, n, v;
> mfn_t m2p_start_mfn = INVALID_MFN;
> -l3_pgentry_t l3e;
> -l2_pgentry_t l2e;
> +l3_pgentry_t l3e, *l3t;
> +l2_pgentry_t l2e, *l2t;
>
> /* M2P table is mappable read-only by privileged domains. */
> for ( v = RDWR_MPT_VIRT_START;
> @@ -175,14 +175,22 @@ static int share_hotadd_m2p_table(struct
> mem_hotadd_info *info)
> v += n << PAGE_SHIFT )
> {
> n = L2_PAGETABLE_ENTRIES * L1_PAGETABLE_ENTRIES;
> -l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
> -l3_table_offset(v)];
> +
> +l3t = map_xen_pagetable_new(
> +l4e_get_mfn(idle_pg_table[l4_table_offset(v)]));
> +l3e = l3t[l3_table_offset(v)];
> Can you elaborate why this is required?
>
> >
> +UNMAP_XEN_PAGETABLE_NEW(l3t);
> +
This pattern of mapping the table, retrieving the entry and then
immediately unmapping the table is repeated a couple of times here and
in later patches. This looks like it could use a convenience wrapper.
- Stefan
> if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
> continue;
> if ( !(l3e_get_flags(l3e) & _PAGE_PSE) )
> {
> n = L1_PAGETABLE_ENTRIES;
> -l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
> +
> +l2t = map_xen_pagetable_new(l3e_get_mfn(l3e));
> +l2e = l2t[l2_table_offset(v)];
> +UNMAP_XEN_PAGETABLE_NEW(l2t);
> +
> if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
> continue;
> m2p_start_mfn = l2e_get_mfn(l2e);
> @@ -203,11 +211,18 @@ static int share_hotadd_m2p_table(struct
> mem_hotadd_info *info)
> v != RDWR_COMPAT_MPT_VIRT_END;
> v += 1 << L2_PAGETABLE_SHIFT )
> {
> -l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
> -l3_table_offset(v)];
> +l3t = map_xen_pagetable_new(
> +l4e_get_mfn(idle_pg_table[l4_table_offset(v)]));
> +l3e = l3t[l3_table_offset(v)];
> +UNMAP_XEN_PAGETABLE_NEW(l3t);
> +
> if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
> continue;
> -l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
> +
> +l2t = map_xen_pagetable_new(l3e_get_mfn(l3e));
> +l2e = l2t[l2_table_offset(v)];
> +UNMAP_XEN_PAGETABLE_NEW(l2t);
> +
> if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
> continue;
> m2p_start_mfn = l2e_get_mfn(l2e);
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: p2m: configure pa_range_info table to support 42 bit PA systems.
On 3/18/19 4:05 AM, Julien Grall wrote: > Hello, > > On 15/03/2019 23:57, Feng Kan OS wrote: >> On 3/15/19 4:21 AM, Julien Grall wrote: >>> On 15/03/2019 08:34, Vishnu Pajjuri OS wrote: Current pa_range_info table's configuration prevents 42 bit PA systems from booting DOM0. This patch modifies t0sz=22 and root_order=3 to expose 42-bit IPA (Intermediate Physical Address). It is required for hardware which is having peripherals above 40 bits. >>> >>> The commit message is a bit confusing, you first say Xen does not boot >>> on 42-bits PA systems but towards the end of the commit you restrict to >>> only platform that have address wired above 40-bits. >>> >>> The limitation was introduced because existing platform back then had >>> all address wired below 40-bits. So we can limit to 40-bits and allocate >>> 2 pages rather than 8 pages for each page-tables. >>> >>> While I am perfectly fine to see this for Dom0, I am still unsure this >>> is the right things for guest. Do you currently have any use case for >>> 42-bits (4TB) guest? >> I agree there is no use case at the moment for 42 bit guest, it is a fix >> for DOM0 booting with peripheral and memory above 40 bits of PA. The >> other option is to keep separate table for the guest? > > Having a separate table is a possibility. Although, it would require a > bit more work than that. VCR_EL2, P2M_ROOT_LEVEL, P2M_ROOT_ORDER would > now become per-domain. > > I am not entirely sure such changes is worth it yet. IIRC, in the > previous version of this patch, this would be fine for you to allocate > more memory as you have a lot of memory. Am I correct? Yes, eMAG can go upto 1TB of RAM. We will reformat commit description. > >>> >>> I can't remember which other platforms support 42-bits PA. I think at >>> that time it was X-Gene. As long as no current embedded platform we >>> support use 42-bit PA, this change may be ok. Stefano do you recall what >>> was the platform? >> Ampere eMAG platform is essentially the continuation of X-Gene. These >> systems are targeted as servers with upto 1TB of RAM. > > So my memory hasn't failed yet :). > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] mwait-idle: add support for using halt
>>> On 19.03.19 at 17:12, wrote:
> On 3/15/19 3:37 AM, Jan Beulich wrote:
> On 14.03.19 at 20:00, wrote:
>>> On 3/13/19 4:35 AM, Jan Beulich wrote:
>>> On 25.02.19 at 21:23, wrote:
> --- a/xen/arch/x86/cpu/mwait-idle.c
> +++ b/xen/arch/x86/cpu/mwait-idle.c
> @@ -103,6 +103,11 @@ static const struct cpuidle_state {
>
>#define CPUIDLE_FLAG_DISABLED 0x1
>/*
> + * On certain AMD families that support mwait, only c1 can be reached by
> + * mwait and to reach c2, halt has to be used.
> + */
> +#define CPUIDLE_FLAG_USE_HALT0x2
Could you point us at where in the manuals this behavior is described?
While PM Vol 2 has a chapter talking about P-states, I can't seem to
find any mention of C-states there.
>>>
>>> IIRC it's in the NDA PPR and internally it's in some other documents.
>>> We don't have support to use mwait while in CC6 due to caches being
>>> turned off etc. If we did have mwait suport for CC6, we'd use that here
>>> (basically mirroring Intel). Sadly I don't think we have any public
>>> information directly detailing this information. If you'd like, I can
>>> look further into it.
>>
>> Ah yes, I found it. But the text suggests to use SystemIO, not
>> HLT for entering C2 (CC6). An important difference looks to be
>> the state of EFLAGS.IF as to whether the core wakes up again.
>> The SystemIO approach would better match the FFixedHW one,
>> as we require and use MWAIT_ECX_INTERRUPT_BREAK.
>>
>> Furthermore I'm then once again wondering what the gain is
>> over using the ACPI driver: The suggested _CST looks to exactly
>> match the data you enter into the table in the later patch. IOW
>> my fundamental concern didn't go away yet: As per the name
>> of the driver, it shouldn't really need to support HLT (or anything
>> other than MWAIT) as an entry method. Hence I think that at
>> the very least you need to extend the description of the change
>> quite a bit to explain why the ACPI driver is not suitable.
>>
>> Depending on how this comes out, it may then still be a matter
>> of discussing whether, rather than fiddling with mwait-idle, it
>> wouldn't be better to have an AMD-specific driver instead. Are
>> there any thoughts in similar directions for Linux?
>
> I can make it use sysIO rather than HLT if there's a need or strong
> desire for it. I used HLT mainly because I thought it would be more
> robust (like in the case of CC6 being disabled).
Well, you know whether to trust your documentation.
> Because:
> #1 getting the ACPI tables from dom0 is either unreliable (PV dom0) or
> not possible (PVH dom0).
Why unreliable? And PVH Dom0 is still WIP.
> #2 the changes to the Intel code are minimal.
But they go against the purpose of the file, which is to make use of
MWAIT.
> #3 worse case, Xen thinks it's using CC6 when it's using CC1. Not
> perfect but far from fatal or breaking.
Yes, that's a minor aspect.
> In Linux, they have a working AML interrupter so they just read the ACPI
> tables. If Xen had a working AML interrupter, I'd suggest just reading
> the ACPI tables as well. As far as a completely different driver for
> AMD, it would mostly just be the Intel drive with the small changes and
> some code removed. With the minimal changes needed, I don't see a
> reason, but that's just me.
Well, I've put this up for discussion, and specifically raised the
question of what Linux is doing here.
> + case ACPI_CSTATE_EM_HALT:
> + info = get_cpu_info();
> + spec_ctrl_enter_idle(info);
> + safe_halt();
> + spec_ctrl_exit_idle(info);
... wouldn't it be better to avoid the redundancy with default_idle(),
by introducing a new helper function, e.g. spec_ctrl_safe_halt()?
>>> See my email with Wei about this.
>>
>> There you've basically settled on making a helper function, to
>> be used in pre-existing places as well as here.
>>
>> I've also just noticed that there's another safe_halt() invocation
>> a few lines up from here, as a fallback. It doesn't come with any
>> of the statistics though, so would probably be unsuitable to
>> funnel into.
>
> It does use follow the pattern of:
> spec_ctrl_enter_idle(info);
> safe_halt();
> spec_ctrl_exit_idle(info);
> though. I'm pretty sure out would work with what I suggested or am I
> missing something?
I'm afraid I'm not understanding the question in this context. Perhaps
I'm largely confused by the use of "out" in the middle of the sentence.
Is this referring to the OUT instruction in context of the SysIO aspect
discussed further up? If so - I don't understand what you're trying to
get at in the context here. If not, I'm lost altogether.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/paging: paging_set_allocation() is init-only
On 3/11/19 4:38 PM, Jan Beulich wrote: > This is needed for Dom0 creation only, therefore it gets additionally > framed by an #ifdef. > > Signed-off-by: Jan Beulich Reviewed-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86: don't allow clearing of TF_kernel_mode for other than 64-bit PV
On 3/11/19 4:37 PM, Jan Beulich wrote: > The flag is really only meant for those, both HVM and 32-bit PV tell > kernel from user mode based on CPL/RPL. Remove the all-question-marks > comment and let's be on the safe side here and also suppress clearing > for 32-bit PV (this isn't a fast path after all). > > Remove no longer necessary is_pv_32bit_*() from sh_update_cr3() and > sh_walk_guest_tables(). Note that shadow_one_bit_disable() already > assumes the new behavior. > > Signed-off-by: Jan Beulich Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/3] mwait-idle: add enablement for AMD Naples and Rome
>>> On 19.03.19 at 16:59, wrote: > On 3/15/19 3:54 AM, Jan Beulich wrote: > On 14.03.19 at 20:29, wrote: >>> There's another register we _might_ >>> be able to use, but support for CC6 is AND'd with that and another >>> another register (we don't have access to). The register we'd read is >>> also RW. So I'm not sure I trust it. >> >> It's hard to believe that one can't find out whether HLT would enter >> only CC1 or eventually also CC6. > > There's a register, but it's AND'd with firmware for if C6 is enabled. > Assuming it isn't touched, it should be able to determine if C6 is > enabled or not by BIOS. That leads to more code and the negative of not > checking is system thinking it's using CC6 when it's really using CC1. > It's also NDA'd so I'd have to get approval to use it (and then also put > it in the public PPR). Well, no need to go through too many hoops for this. It would just have been nice to tell the two apart, not the least because of their quite different wakeup latencies. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 133927: tolerable all pass - PUSHED
flight 133927 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133927/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen a892f81ddecf0ad90564a4d91d520234c542b068 baseline version: xen 17f74242ccf0ce6e51c03a5860947865c0ef0dc2 Last test of basis 133911 2019-03-18 19:00:37 Z0 days Testing same since 133927 2019-03-19 15:00:29 Z0 days1 attempts People who touched revisions under test: Jan Beulich Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 17f74242cc..a892f81dde a892f81ddecf0ad90564a4d91d520234c542b068 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Maintainers, please tell us how to boot your machines!
Markus Armbruster writes: > Dear board code maintainers, > > This is a (rather late) follow-up to the last QEMU summit. Minutes[*]: > > * Deprecating unmaintained features (devices, targets, backends) in QEMU > >QEMU has a mechanism to deprecate features but there remains a lot of >old unmaintained code. Refactoring is hindered by untested legacy >code, so there is a desire to deprecate unmaintained features more >often. > >[...] > >We should require at least a minimal test for each board; if nobody >cares enough to come up with one, that board should be deprecated. > >[...] > >Also see the qemu-devel discussion about deprecating code: >https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html. > > That's a link to "Minutes of KVM Forum BoF on deprecating stuff". > Quote: > > * One obvious class of candidates for removal is machines we don't know >how to boot, or can't boot, say because we lack required firmware >and/or OS. > >Of course, "can boot" should be an automated test. As a first step >towards that, we should at least document how to boot each machine. >We're going to ask machine maintainers to do that. > > Let's get going on this. > > I gathered the machine types, mapped them to source files, which I fed > to get_maintainer.pl. Results are appended. If you're cc'ed, > MAINTAINERS fingers you for at least one machine type's source file. > Please tell us for all of them how to to a "meaningful" boot test. > > For now, what's "meaningful" is entirely up to you. Booting Linux > certainly is. > > Make sure to include a complete QEMU command line. If your QEMU command > line requires resources beyond the QEMU source tree and what we build > from it, please detail them, and provide download URLs as far as > possible. > > Goals for this exercise: > > * Gather information we need to cover more machines in our automated > testing. > > Related work: > [PATCH v4 00/19] Acceptance Tests: target architecture support > Message-Id: <20190312121150.8638-1-cr...@redhat.com> > https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg03881.html > > * Maybe identify a few machines we don't know how to boot anymore. > > Thanks in advance for your help! Quite a few maintainers replied, and a few others, too. Thank you! I still have to fully digest the replies, in particular whether there's enough detail for me to actually boot a guest. I'm still lacking information on 26 machines. If you're cc'ed, you're considered a possible source of information. Please help. If you're a supporter or maintainer, but can't help, please consider adjusting MAINTAINERS to S: Odd Fixes for the machine. Machines with at least one supporter: = hw/xenpv/xen_machine_pv.c = Stefano Stabellini (supporter:X86) Anthony Perard (supporter:X86) Paul Durrant (supporter:X86) xen-devel@lists.xenproject.org (open list:X86) Machines with no supporter, but at least one maintainer: = hw/arm/integratorcp.c = Peter Maydell (maintainer:Integrator CP) qemu-...@nongnu.org (open list:Integrator CP) = hw/arm/omap_sx1.c = Peter Maydell (maintainer:OMAP) qemu-...@nongnu.org (open list:ARM) = hw/mips/mips_jazz.c = "Hervé Poussineau" (maintainer:Jazz) Aleksandar Rikalo (reviewer:Jazz) Aurelien Jarno (maintainer:MIPS) Aleksandar Markovic (maintainer:MIPS) = hw/mips/mips_r4k.c = Aurelien Jarno (maintainer:R4000) Aleksandar Rikalo (reviewer:R4000) Aleksandar Markovic (maintainer:MIPS) = hw/moxie/moxiesim.c = Anthony Green (maintainer:Moxie) = hw/nios2/10m50_devboard.c = Chris Wulff (maintainer:NiosII) Marek Vasut (maintainer:NiosII) = hw/ppc/virtex_ml507.c = "Edgar E. Iglesias" (odd fixer:virtex_ml507) David Gibson (maintainer:PowerPC) qemu-...@nongnu.org (open list:virtex_ml507) = hw/tricore/tricore_testboard.c = Bastian Koppelmann (maintainer:TriCore) = hw/unicore32/puv3.c = Guan Xuetao (maintainer:UniCore32) Machines with no maintainer and no supporter: = hw/arm/collie.c = Peter Maydell (odd fixer:Sharp SL-5500 (Co...) qemu-...@nongnu.org (open list:Sharp SL-5500 (Co...) = hw/arm/exynos4_boards.c = Igor Mitsyanko (odd fixer:Exynos) Peter Maydell (odd fixer:Exynos) qemu-...@nongnu.org (open list:Exynos) = hw/arm/imx25_pdk.c = Peter Maydell (odd fixer:i.MX25 PDK) Jean-Christophe Dubois (reviewer:i.MX25 PDK) qemu-...@nongnu.org (open list:i.MX25 PDK) = hw/arm/mainstone.c = Andrzej Zaborowski (odd fixer:PXA2XX) Peter Maydell (odd fixer:PXA2XX) qemu-...@nongnu.org (open list:PXA2XX) = hw/arm/mcimx6ul-evk.c = Peter Maydell (odd fixer:MCIMX6UL EVK / i) Jean-Christophe Dubois (reviewer:MCIMX6UL EVK / i) qemu-...@nongnu.org (open list:MCIMX6UL EVK / i) = hw/arm/mcimx7d-sabre.c = Peter Maydell (odd fixer:MC
[Xen-devel] [libvirt test] 133904: regressions - FAIL
flight 133904 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/133904/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 133846 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 133846 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 133846 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 133846 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a version targeted for testing: libvirt 3aa190f2a43a632b542a6ba751a6c3ab4d51f1dd baseline version: libvirt 25e2e4e04f13901b3db903b2301bd11381bdf128 Last test of basis 133846 2019-03-16 02:09:09 Z3 days Failing since133876 2019-03-17 11:33:04 Z2 days2 attempts Testing same since 133904 2019-03-18 15:34:55 Z1 days1 attempts People who touched revisions under test: Andrea Bolognani Cole Robinson Daniel P. Berrangé Michal Privoznik Nikolay Shirokovskiy Peter Krempa jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd 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 489 lines long.) ___ Xen-devel
Re: [Xen-devel] Maintainers, please tell us how to boot your machines!
On Tue, 19 Mar 2019 at 18:34, Markus Armbruster wrote:
Here are some command lines from my image zoo. Unfortunately
typically the images themselves are random accumulations
from people and I have no idea how to rebuild them (and
they are thus not redistributable, generally).
> = hw/arm/integratorcp.c =
> Peter Maydell (maintainer:Integrator CP)
> qemu-...@nongnu.org (open list:Integrator CP)
${QEMU} \
-M integratorcp \
-kernel "${TESTDIR}"/zImage.integrator \
-initrd "${TESTDIR}"/arm_root.img -serial stdio \
-append "console=ttyAMA0"
(I think this test image and kernel used to be kicking around
on the QEMU wiki at one point. Provenance unknown, naturally.)
> = hw/arm/musicpal.c =
> Jan Kiszka (odd fixer:Musicpal)
> Peter Maydell (odd fixer:Musicpal)
> qemu-...@nongnu.org (open list:Musicpal)
${QEMU} \
-machine musicpal \
-pflash "${TESTDIR}"/musicpal.image -snapshot \
-kernel "${TESTDIR}"/u-boot.image -serial stdio
I got the test image from Jan ages ago. No idea how to rebuild.
> = hw/arm/sabrelite.c =
> Peter Maydell (odd fixer:SABRELITE / i.MX6)
> Jean-Christophe Dubois (reviewer:SABRELITE / i.MX6)
> qemu-...@nongnu.org (open list:SABRELITE / i.MX6)
${QEMU} \
-smp 4 -M sabrelite -m 1024M -display none \
-no-reboot -kernel "${TESTDIR}"/zImage \
-initrd "${TESTDIR}"/rootfs.cpio.gz \
-dtb "${TESTDIR}"/imx6q-sabrelite.dtb \
-serial null -serial stdio
>
> = hw/arm/spitz.c =
> Andrzej Zaborowski (odd fixer:PXA2XX)
> Peter Maydell (odd fixer:PXA2XX)
> qemu-...@nongnu.org (open list:PXA2XX)
${QEMU} -M spitz \
-kernel "${TESTDIR}"/zaurus-test/zImage.zaurus \
-initrd "${TESTDIR}"/zaurus-test/zaurus_root.img -serial stdio \
-append 'console=ttyS0,115200n8 init=/bin/bash'
> = hw/arm/z2.c =
> Andrzej Zaborowski (odd fixer:PXA2XX)
> Peter Maydell (odd fixer:PXA2XX)
> qemu-...@nongnu.org (open list:PXA2XX)
${QEMU} \
-M z2 -pflash "${TESTDIR}"/zipit.flash \
-sd "${TESTDIR}"/zipit.sd \
-show-cursor -serial null -serial null -serial null \
-kernel "${TESTDIR}"/uImage \
-append "console=tty0 fbcon=rotate:3 root=/dev/mmcblk0 ro rootdelay=3" \
-rotate 270
> = hw/lm32/milkymist.c =
> Michael Walle (maintainer:milkymist)
${QEMU} -M milkymist -serial stdio -kernel "${TESTDIR}"/flickernoise
thanks
-- PMM
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/pv: Add PV specific legacy_pic struct to expose legacy IRQs.
The ACPI tables doesn't always contain all IRQs for legacy devices
such as RTC. Since no PIC controller is visible for a PV linux guest,
under Xen, legacy_pic currently defaults to the null_legacy_pic - with
reports no legacy IRQs. Since the commit "rtc: cmos: Do not assume
irq 8 for rtc when there are no legacy irqs" by Hans de Goede
(commit id: a1e23a42f1bdc00e32fc4869caef12e4e6272f26), the rtc now
incorrectly decides it has no irq it can use, for some hardware.
This patch rectifies the problem by providing a xen legacy_pic
struct, which is much like the null_legacy_pic except that it
reports NR_IRQS_LEGACY irqs.
Signed-off-by: Jennifer Herbert
---
arch/x86/xen/enlighten_pv.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index c54a493..7644bdf 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +50,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1188,6 +1190,41 @@ static void __init xen_dom0_set_legacy_features(void)
x86_platform.legacy.rtc = 1;
}
+/*
+ * The ACPI tables doesn't always contain all IRQ's for legacy devices
+ * such as RTC. Since no PIC controller is visible, we'd otherwise
+ * default to the null_legacy_pic - with no legacy IRQs. To allow drivers
+ * to use these IRQs despite this, provide a xen specific legacy_pic
+ * structure, which is noop, other then reporting NR_IRQS_LEGACY irqs.
+ */
+
+static void xen_legacy_pic_noop(void) { };
+static void xen_legacy_pic_uint_noop(unsigned int unused) { };
+static void xen_legacy_pic_int_noop(int unused) { };
+static int xen_legacy_pic_irq_pending_noop(unsigned int irq)
+{
+ return 0;
+}
+
+static int xen_legacy_pic_probe(void)
+{
+ pr_info("Using Xen legacy PIC\n");
+ return nr_legacy_irqs();
+}
+
+struct legacy_pic xen_legacy_pic = {
+ .nr_legacy_irqs = NR_IRQS_LEGACY,
+ .chip = &dummy_irq_chip,
+ .mask = xen_legacy_pic_uint_noop,
+ .unmask = xen_legacy_pic_uint_noop,
+ .mask_all = xen_legacy_pic_noop,
+ .restore_mask = xen_legacy_pic_noop,
+ .init = xen_legacy_pic_int_noop,
+ .probe = xen_legacy_pic_probe,
+ .irq_pending = xen_legacy_pic_irq_pending_noop,
+ .make_irq = xen_legacy_pic_uint_noop,
+};
+
/* First C function to be called on Xen boot */
asmlinkage __visible void __init xen_start_kernel(void)
{
@@ -1267,6 +1304,8 @@ asmlinkage __visible void __init xen_start_kernel(void)
xen_init_capabilities();
+ legacy_pic = &xen_legacy_pic;
+
#ifdef CONFIG_X86_LOCAL_APIC
/*
* set up the basic apic ops.
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
