Re: [Xen-devel] [PATCH 1/2] domain: introduce alloc/free_shared_info() helpers...

[Julien Grall]

Hi,

On 25/02/2020 09:53, Paul Durrant wrote:

... and save the MFN.

This patch modifies the 'shared_info' field of struct domain to be
a structure comprising an MFN and a virtual address. Allocations are
still done from xenheap, so the virtual address still equates to
virt_to_mfn() called on the MFN but subsequent patch will change this.
Hence the need to save the MFN.

NOTE: Whist defining the new helpers, virt_to_mfn() in common/domain.c
   is made type safe.
   The definition of nmi_reason() in asm-x86/shared.h is also re-
   flowed to avoid overly long lines.

Signed-off-by: Paul Durrant 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-next test] 147536: regressions - FAIL

[osstest service owner]

flight 147536 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147536/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-thunderx 16 guest-start/debian.repeat fail REGR. vs. 147410
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 147410
 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 147410
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 147410
 test-armhf-armhf-xl-multivcpu  7 xen-bootfail REGR. vs. 147410
 test-armhf-armhf-libvirt-raw  7 xen-boot fail REGR. vs. 147410
 test-armhf-armhf-xl-vhd   7 xen-boot fail REGR. vs. 147410
 test-armhf-armhf-xl-cubietruck  7 xen-boot   fail REGR. vs. 147410
 test-armhf-armhf-xl-credit1   7 xen-boot fail REGR. vs. 147410
 test-armhf-armhf-libvirt  7 xen-boot fail REGR. vs. 147410

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-seattle 16 guest-start/debian.repeat fail blocked in 147410
 test-arm64-arm64-xl  17 guest-start.2   fail blocked in 147410
 test-amd64-amd64-xl-rtds 12 guest-start  fail  like 147410
 test-amd64-amd64-xl-credit1  12 guest-start  fail  like 147410
 test-amd64-amd64-xl-multivcpu 12 guest-start  fail like 147410
 test-amd64-amd64-xl-credit2  12 guest-start  fail  like 147410
 test-amd64-i386-xl-shadow12 guest-start  fail  like 147410
 test-amd64-amd64-xl-shadow   12 guest-start  fail  like 147410
 test-arm64-arm64-xl-credit2  12 guest-start  fail  like 147410
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 
147410
 test-armhf-armhf-xl-rtds 12 guest-start  fail  like 147410
 test-armhf-armhf-xl-credit2  12 guest-start  fail  like 147410
 test-arm64-arm64-xl-credit1  12 guest-start  fail  like 147410
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 147410
 test-arm64-arm64-xl-xsm  16 guest-start/debian.repeatfail  like 147410
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 147410
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 147410
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 147410
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 147410
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 147410
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 147410
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linuxbdc5461b23ca293a2a83c851423aae0dd32a48c0
baseline version:
 linuxca7e1fd1026c5af6a533b4b5447e1d2f153e28f2

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   147536  2020-02-24 09:19:01 Z1 days1 attempts

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm 

Re: [Xen-devel] [PATCH 7/8] x86/setup: simplify handling of initrdidx when no initrd present

[Jan Beulich]

On 26.02.2020 08:13, Julien Grall wrote:
> On 25/02/2020 12:34, Jan Beulich wrote:
>> Further, even if all current implementations obeyed by the more
>> strict rule, this still wouldn't mean callers are actually permitted
>> to assume such. The more strict rule would then also need to be
>> written down, such that it won't get violated again in the future
>> (by changes to an existing arch's implementation, or by a new port
> 
> To be honest, the rule should be written down in any case. The current 
> one is not necessarily an obvious one and also differ from what Linux 
> folks can expect.

I think we should stick to the more relaxed rule in any event, unless
there's a strong reason to enforce the more strict one. Much (but not
all) of Linux code looks to assume the more relaxed rule too, likely
also for historical reasons (when the implementation on e.g. x86-64
still followed the more relaxed model).

> Regarding future port, the number of architectures in Linux using custom 
> bitops are fairly limited (AFAICT only arm32 and unicore32). All the 
> rest (including x86) using a generic implementation.
> 
> On Xen, Arm64 is already using the generic implementation. Is there any 
> particular concern to use it for x86 as well?

According to the (over 10 years old) commit updating Linux x86 this
way, the generic implementation was even faster. If that was the
case today and for our implementation as well, then I think it
would be very nice if we updated. If, otoh, data isn't as clear,
then further consideration may be needed. Andrew, do you have any
thoughts either way?

> If not, I can pull a patch to use the generic implementation on 
> x86/arm32. This would solve the discrenpancies in find_*_bit 
> implementations.

This is orthogonal to the issue discussed - as said, I think code
using the functions would still better assume the more relaxed model.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] xen/sched: rework credit2 run-queue allocation

[Dario Faggioli]

On Thu, 2020-02-20 at 14:39 +0100, Juergen Gross wrote:
> Currently the memory for each run-queue of the credit2 scheduler is
> allocated at the scheduler's init function: for each cpu in the
> system
> a struct csched2_runqueue_data is being allocated, even if the
> current scheduler only handles one physical cpu or is configured to
> work with a single run-queue. As each struct contains 4 cpumasks this
> sums up to rather large memory sizes pretty fast.
> 
> Rework the memory allocation for run-queues to be done only when
> needed, i.e. when adding a physical cpu to the scheduler requiring a
> new run-queue.
> 
> In fact this fixes a bug in credit2 related to run-queue handling:
> cpu_to_runqueue() will return the first free or matching run-queue,
> which ever is found first. So in case a cpu is removed from credit2
> this could result in e.g. run-queue 0 becoming free, so when another
> cpu is added it will in any case be assigned to that free run-queue,
> even if it would have found another run-queue matching later.
> 
> Signed-off-by: Juergen Gross 
>
Reviewed-by: Dario Faggioli 

Regards 
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] x86/vPMU: don't blindly assume IA32_PERF_CAPABILITIES MSR exists

[Jan Beulich]

Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
be consulted first.

Reported-by: Farrah Chen 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -900,7 +900,6 @@ int vmx_vpmu_initialise(struct vcpu *v)
 
 int __init core2_vpmu_init(void)
 {
-u64 caps;
 unsigned int version = 0;
 unsigned int i;
 
@@ -932,8 +931,14 @@ int __init core2_vpmu_init(void)
 
 arch_pmc_cnt = core2_get_arch_pmc_count();
 fixed_pmc_cnt = core2_get_fixed_pmc_count();
-rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
-full_width_write = (caps >> 13) & 1;
+
+if ( cpu_has_pdcm )
+{
+uint64_t caps;
+
+rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
+full_width_write = (caps >> 13) & 1;
+}
 
 fixed_ctrl_mask = ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1);
 /* mask .AnyThread bits for all fixed counters */

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/sysctl: Don't return cpu policy data for compiled-out support

[Jan Beulich]

On 25.02.2020 18:31, Andrew Cooper wrote:
> Policy objects aren't tiny, and the derivation logic isn't trivial.  We are
> about to increase the number of policy objects, so take this opportunity to
> drop logic and storage space based on CONFIG_{PV,HVM}.

It doesn't look as if you were dropping either logic or storage space. With
this aspect taken care of (by adjusting wording, or by clarification of what
is meant) ...

> Start by causing XEN_SYSCTL_get_cpu_policy to fail with -EOPNOTSUPP when
> requesting data for a compiled-out subsystem.  Update xen-cpuid to cope and
> continue to further system policies, seeing as the indicies are interleaved.
> 
> Signed-off-by: Andrew Cooper 

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 V4] x86/altp2m: Hypercall to set altp2m view visibility

[Alexandru Stefan ISAILA]

On 24.02.2020 11:06, Alexandru Stefan ISAILA wrote:
> 
> 
> On 21.02.2020 18:39, Jan Beulich wrote:
>> On 21.02.2020 09:30, Alexandru Stefan ISAILA wrote:
>>> @@ -4835,6 +4836,26 @@ static int do_altp2m_op(
>>>break;
>>>}
>>>
>>> +case HVMOP_altp2m_set_visibility:
>>> +{
>>> +uint16_t idx = a.u.set_visibility.altp2m_idx;
>>> +
>>> +if ( a.u.set_visibility.pad ||
>>> + idx >= min(ARRAY_SIZE(d->arch.altp2m_p2m), MAX_EPTP) ||
>>
>> Why min() here? You only access MAX_EPTP-dimensioned arrays afaics. If
>> this is intentional, I think it deserves a comment.
> 
> I have min() here because the altp2m index should not be grater then
> MAX_ALTP2M. I know this is used as altp2m_eptp() index but the two are
> coupled.
> 
>>
>>> + d->arch.altp2m_eptp[array_index_nospec(idx, MAX_EPTP)] ==
>>> + mfn_x(INVALID_MFN) )
>>> +rc = -EINVAL;
>>> +else if ( !altp2m_active(d) )
>>> +rc = -EOPNOTSUPP;
>>> +else if ( a.u.set_visibility.visible )
>>> +d->arch.altp2m_working_eptp[array_index_nospec(idx, MAX_EPTP)] 
>>> =
>>> +d->arch.altp2m_eptp[array_index_nospec(idx, MAX_EPTP)];
>>> +else
>>> +d->arch.altp2m_working_eptp[array_index_nospec(idx, MAX_EPTP)] 
>>> =
>>> +mfn_x(INVALID_MFN);
>>> +break;
>>
>> You don't seem to be holding any locks. At the very least this means
>> the in-range-index-is-valid check further up will have become stale
>> by the time you actually consume the slot.
>>
> 
> Good thing to point this out here. I will add altp2m_list_lock/unlock(d)
> to guard this check and operation.

I think it's better to move all the altp2m things in a new function, 
something like p2m_set_altp2m_view_visibility(), in p2m.c. This way 
there will be no additional include needed.

Alex
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/sysctl: Don't return cpu policy data for compiled-out support

[Andrew Cooper]

On 26/02/2020 09:32, Jan Beulich wrote:
> On 25.02.2020 18:31, Andrew Cooper wrote:
>> Policy objects aren't tiny, and the derivation logic isn't trivial.  We are
>> about to increase the number of policy objects, so take this opportunity to
>> drop logic and storage space based on CONFIG_{PV,HVM}.
> It doesn't look as if you were dropping either logic or storage space. With
> this aspect taken care of (by adjusting wording, or by clarification of what
> is meant) ...
>
>> Start by

That is this is here to signify.

No logic or storage space can be dropped until some #ifdef-ary is
sprinkled around cpuid.c and msr.c, but I can't do any of that while
there are unguarded external references to the objects.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-coverity test] 147631: all pass - PUSHED

[osstest service owner]

flight 147631 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147631/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  d90bcb5f10995c52d080274d66bfdc362b22598e
baseline version:
 xen  4cdd4fa29fc24d2d898ac01988b2b10936556d72

Last test of basis   147488  2020-02-23 09:18:55 Z3 days
Testing same since   147631  2020-02-26 09:18:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Paul Durrant 
  Wei Liu 

jobs:
 coverity-amd64   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4cdd4fa29f..d90bcb5f10  d90bcb5f10995c52d080274d66bfdc362b22598e -> 
coverity-tested/smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 4/5] x86/smp: use a dedicated scratch cpumask in send_IPI_mask

[Jan Beulich]

On 24.02.2020 11:46, Roger Pau Monne wrote:
> Using scratch_cpumask in send_IPI_mask is not safe because it can be
> called from interrupt context, and hence Xen would have to make sure
> all the users of the scratch cpumask disable interrupts while using
> it.
> 
> Instead introduce a new cpumask to be used by send_IPI_mask, and
> disable interrupts while using it.

The alternative of also adding ...

> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -59,6 +59,7 @@ static void send_IPI_shortcut(unsigned int shortcut, int 
> vector,
>  apic_write(APIC_ICR, cfg);
>  }
>  
> +DECLARE_PER_CPU(cpumask_var_t, send_ipi_cpumask);
>  /*
>   * send_IPI_mask(cpumask, vector): sends @vector IPI to CPUs in @cpumask,
>   * excluding the local CPU. @cpumask may be empty.
> @@ -67,7 +68,21 @@ static void send_IPI_shortcut(unsigned int shortcut, int 
> vector,
>  void send_IPI_mask(const cpumask_t *mask, int vector)
>  {
>  bool cpus_locked = false;
> -cpumask_t *scratch = this_cpu(scratch_cpumask);
> +cpumask_t *scratch = this_cpu(send_ipi_cpumask);
> +unsigned long flags;
> +
> +if ( in_mc() || in_nmi() )

... in_irq() here was considered, and discarded because of? With
this you'd not need the second CPU mask and you'd also be able
to avoid disabling an re-enabling IRQs.

In order to not disturb the partial sentence, a small request on
the previous hunk as well: Could you add a blank line after the
new definition, please?

> +{
> +/*
> + * When in #NMI or #MC context fallback to the old (and simpler) IPI

Note that conventional notation indeed is #MC but just NMI (applies
here, in the description, and also elsewhere in the series).

> @@ -81,7 +96,15 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
>   local_irq_is_enabled() && (cpus_locked = get_cpu_maps()) &&
>   (park_offline_cpus ||
>cpumask_equal(&cpu_online_map, &cpu_present_map)) )
> +{
> +/*
> + * send_IPI_mask can be called from interrupt context, and hence we
> + * need to disable interrupts in order to protect the per-cpu
> + * send_ipi_cpumask while being used.
> + */
> +local_irq_save(flags);
>  cpumask_or(scratch, mask, cpumask_of(smp_processor_id()));
> +}
>  else
>  {
>  if ( cpus_locked )
> @@ -89,6 +112,7 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
>  put_cpu_maps();
>  cpus_locked = false;
>  }
> +local_irq_save(flags);
>  cpumask_clear(scratch);
>  }
>  
> @@ -97,6 +121,7 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
>  else
>  alternative_vcall(genapic.send_IPI_mask, mask, vector);
>  
> +local_irq_restore(flags);

Wouldn't it be better to re-enable interrupts in the "else" branch
visible in context ahead of the call?

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/vPMU: don't blindly assume IA32_PERF_CAPABILITIES MSR exists

[Andrew Cooper]

On 26/02/2020 09:19, Jan Beulich wrote:
> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
> be consulted first.
>
> Reported-by: Farrah Chen 
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/vPMU: don't blindly assume IA32_PERF_CAPABILITIES MSR exists

[Roger Pau Monné]

On Wed, Feb 26, 2020 at 10:19:19AM +0100, Jan Beulich wrote:
> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
> be consulted first.
> 
> Reported-by: Farrah Chen 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -900,7 +900,6 @@ int vmx_vpmu_initialise(struct vcpu *v)
>  
>  int __init core2_vpmu_init(void)
>  {
> -u64 caps;
>  unsigned int version = 0;
>  unsigned int i;
>  
> @@ -932,8 +931,14 @@ int __init core2_vpmu_init(void)
>  
>  arch_pmc_cnt = core2_get_arch_pmc_count();
>  fixed_pmc_cnt = core2_get_fixed_pmc_count();
> -rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
> -full_width_write = (caps >> 13) & 1;
> +
> +if ( cpu_has_pdcm )
> +{
> +uint64_t caps;
> +
> +rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
> +full_width_write = (caps >> 13) & 1;

Will PMU work without PDCM?

I've been grepping the Intel SDMs, but the only mention is that PDCM
signal the availability of MSR_IA32_PERF_CAPABILITIES.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 4/5] x86/smp: use a dedicated scratch cpumask in send_IPI_mask

[Roger Pau Monné]

On Wed, Feb 26, 2020 at 11:07:44AM +0100, Jan Beulich wrote:
> On 24.02.2020 11:46, Roger Pau Monne wrote:
> > Using scratch_cpumask in send_IPI_mask is not safe because it can be
> > called from interrupt context, and hence Xen would have to make sure
> > all the users of the scratch cpumask disable interrupts while using
> > it.
> > 
> > Instead introduce a new cpumask to be used by send_IPI_mask, and
> > disable interrupts while using it.
> 
> The alternative of also adding ...
> 
> > --- a/xen/arch/x86/smp.c
> > +++ b/xen/arch/x86/smp.c
> > @@ -59,6 +59,7 @@ static void send_IPI_shortcut(unsigned int shortcut, int 
> > vector,
> >  apic_write(APIC_ICR, cfg);
> >  }
> >  
> > +DECLARE_PER_CPU(cpumask_var_t, send_ipi_cpumask);
> >  /*
> >   * send_IPI_mask(cpumask, vector): sends @vector IPI to CPUs in @cpumask,
> >   * excluding the local CPU. @cpumask may be empty.
> > @@ -67,7 +68,21 @@ static void send_IPI_shortcut(unsigned int shortcut, int 
> > vector,
> >  void send_IPI_mask(const cpumask_t *mask, int vector)
> >  {
> >  bool cpus_locked = false;
> > -cpumask_t *scratch = this_cpu(scratch_cpumask);
> > +cpumask_t *scratch = this_cpu(send_ipi_cpumask);
> > +unsigned long flags;
> > +
> > +if ( in_mc() || in_nmi() )
> 
> ... in_irq() here was considered, and discarded because of? With
> this you'd not need the second CPU mask and you'd also be able
> to avoid disabling an re-enabling IRQs.

I aimed to use the shorthand as much as possible, but I would also be
fine with not using it in irq context. I assume there aren't that many
flushes in irq context, and then the IPIs sent are probably not
broadcast ones.

> 
> In order to not disturb the partial sentence, a small request on
> the previous hunk as well: Could you add a blank line after the
> new definition, please?
> 
> > +{
> > +/*
> > + * When in #NMI or #MC context fallback to the old (and simpler) 
> > IPI
> 
> Note that conventional notation indeed is #MC but just NMI (applies
> here, in the description, and also elsewhere in the series).
> 
> > @@ -81,7 +96,15 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
> >   local_irq_is_enabled() && (cpus_locked = get_cpu_maps()) &&
> >   (park_offline_cpus ||
> >cpumask_equal(&cpu_online_map, &cpu_present_map)) )
> > +{
> > +/*
> > + * send_IPI_mask can be called from interrupt context, and hence we
> > + * need to disable interrupts in order to protect the per-cpu
> > + * send_ipi_cpumask while being used.
> > + */
> > +local_irq_save(flags);
> >  cpumask_or(scratch, mask, cpumask_of(smp_processor_id()));
> > +}
> >  else
> >  {
> >  if ( cpus_locked )
> > @@ -89,6 +112,7 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
> >  put_cpu_maps();
> >  cpus_locked = false;
> >  }
> > +local_irq_save(flags);
> >  cpumask_clear(scratch);
> >  }
> >  
> > @@ -97,6 +121,7 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
> >  else
> >  alternative_vcall(genapic.send_IPI_mask, mask, vector);
> >  
> > +local_irq_restore(flags);
> 
> Wouldn't it be better to re-enable interrupts in the "else" branch
> visible in context ahead of the call?

I think I will go with your suggestion and don't use the shorthand in
irq contenxt, and hence we won't need to disable interrupts then.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [ANNOUNCE] Xen 4.14 Development Update

[Paul Durrant]

This email only tracks big items for xen.git tree. Please reply for items
you would like to see in 4.14 so that people have an idea what
is going on and prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release about every 8
 months.
The critical dates for Xen 4.14 are as follows:

---> We are here
* Last posting date: May 1st, 2020
* Hard code freeze: May 22nd, 2020
* Release: June 26th, 2020

Note that we don't have a freeze exception scheme anymore. All patches
that wish to go into 4.14 must be posted initially no later than the
last posting date and finally no later than the hard code freeze.
All patches posted after that date will be automatically queued into next
release.

RCs will be arranged immediately after freeze.

There is also a jira instance to track all the tasks (not only big)
for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.

Some of the tasks tracked by this e-mail also have a corresponding jira task
referred by XEN-N.

There is a version number for patch series associated to each feature.
Can each owner send an update giving the latest version number if the
series has been re-posted? Also, can the owners of any completed items
please respond so that the item can be moved into the 'Completed' section.

= Projects =

== Hypervisor == 

*  Live-Updating Xen (RFC v2)
  -  David Woodhouse
  -  The latest code is available at 
https://xenbits.xen.org/gitweb/?p=people/dwmw2/xen.git;a=shortlog;h=refs/heads/lu-master
  -  Project wiki page at https://wiki.xenproject.org/wiki/Live-Updating_Xen

*  Non-Cooperative Live Migration
  -  Paul Durrant

*  Secret Hiding (v5)
  -  Hongyan Xia

*  Hypervisor file system (v3)
  -  Juergen Gross

=== x86 === 

*  Linux stub domains (v4)
  -  Marek Marczykowski-Górecki

*  Virtualise MSR_ARCH_CAPS for guests
  -  Andrew Cooper

*  AMD hardware mitigations (Rome)
  -  Andrew Cooper

*  Xen ioreq server (v3)
  -  Roger Pau Monne

*  Memory read caching in emulation (v4)
  -  Jan Beulich

*  Instruction emulator improvements
  -  Jan Beulich

*  VM forking (v10)
  -  Tamas K Lengyel

=== ARM === 

== Completed == 


Paul Durrant

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-4.14 bisection] complete test-amd64-amd64-qemuu-nested-intel

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-install/l1/l2

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  f96e1469ad06b61796c60193daaeb9f8a96d7458
  Bug not present: 0729830cc425a8ff27a3137e87b93768ae3c853c
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/147628/


  commit f96e1469ad06b61796c60193daaeb9f8a96d7458
  Author: Roger Pau Monné 
  Date:   Wed Feb 5 13:49:09 2020 +0100
  
  x86/vvmx: fix virtual interrupt injection when Ack on exit control is used
  
  When doing a virtual vmexit (ie: a vmexit handled by the L1 VMM)
  interrupts shouldn't be injected using the virtual interrupt delivery
  mechanism unless the Ack on exit vmexit control bit isn't set in the
  nested vmcs.
  
  Gate the call to nvmx_update_apicv helper on whether the nested vmcs
  has the Ack on exit bit set in the vmexit control field.
  
  Note that this fixes the usage of x2APIC by the L1 VMM, at least when
  the L1 VMM is Xen.
  
  Signed-off-by: Roger Pau Monné 
  Reviewed-by: Kevin Tian 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.14/test-amd64-amd64-qemuu-nested-intel.debian-hvm-install--l1--l2.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-4.14/test-amd64-amd64-qemuu-nested-intel.debian-hvm-install--l1--l2
 --summary-out=tmp/147628.bisection-summary --basis-template=142849 
--blessings=real,real-bisect linux-4.14 test-amd64-amd64-qemuu-nested-intel 
debian-hvm-install/l1/l2
Searching for failure / basis pass:
 147487 fail [host=chardonnay0] / 147038 [host=godello1] 146981 
[host=huxelrebe0] 146905 [host=godello0] 143911 [host=godello1] 143834 
[host=italia0] 143610 [host=elbling0] 143513 ok.
Failure / basis pass flights: 147487 / 143513
(tree with no url: minios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 98db2bf27b9ed2d5ed0b6c9c8a4bfcb127a19796 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
70911f1f4aee0366b6122f2b90d367ec0f066beb 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
76551856b28d227cb0386a1ab0e774329b941f7d 
c47984aabead53918e5ba6d43cdb3f1467452739
Basis pass ddef1e8e3f6eb26034833b7255e3fa584d54a230 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b15646484eaffcf7cc464fdea0214498f26addc2 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
120996f147131eca8af90e30c900bc14bc824d9f 
518c935fac4d30b3ec35d4b6add82b17b7d7aca3
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#ddef1e8e3f6eb26034833b7255e3fa584d54a230-98db2bf27b9ed2d5ed0b6c9c8a4bfcb127a19796
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#b15646484eaffcf7cc464fdea0214498f26addc2-70911f1f4aee0366b6122f2b90d367ec0f066beb
 git://xenbits.xen.org/qemu-xen-traditional\
 
.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/osstest/seabios.git#120996f147131eca8af90e30c900bc14bc824d9f-76551856b28d227cb0386a1ab0e774329b941f7d
 
git://xenbits.xen.org/xen.git#518c935fac4d30b3ec35d4b6add82b17b7d7aca3-c47984aabead53918e5ba6d43cdb3f1467452739
Use of uninitialized value $parents in array dereference at 
./adhoc-revtuple-generator line 465.
Use of uninitialized value in concatenation (.) or string at 
./adhoc-revtuple-generator line 465.
Loaded 13452 nodes in revision graph
Searching for test results:
 143409 [host=elbling1]
 143513 pass ddef1e8e3f6eb26034833b7255e3fa584d54a230 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b15646484eaffcf7cc464fdea0214498f26addc2 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
120996f147131eca8af90e30

Re: [Xen-devel] [PATCH v3 5/5] x86: add accessors for scratch cpu mask

[Jan Beulich]

On 24.02.2020 11:46, Roger Pau Monne wrote:
> Current usage of the per-CPU scratch cpumask is dangerous since
> there's no way to figure out if the mask is already being used except
> for manual code inspection of all the callers and possible call paths.
> 
> This is unsafe and not reliable, so introduce a minimal get/put
> infrastructure to prevent nested usage of the scratch mask and usage
> in interrupt context.

While I can see the reasoning (especially in light of the change
which did violate to assumption), I'm still uncertain if this isn't
"over-engineering". Andrew, do you have a clear opinion one way or
the other here?

> Move the declaration of scratch_cpumask to smp.c in order to place the
> declaration and the accessors as close as possible.

s/declaration/definition/g

> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -196,7 +196,7 @@ static void _clear_irq_vector(struct irq_desc *desc)
>  {
>  unsigned int cpu, old_vector, irq = desc->irq;
>  unsigned int vector = desc->arch.vector;
> -cpumask_t *tmp_mask = this_cpu(scratch_cpumask);
> +cpumask_t *tmp_mask = get_scratch_cpumask();
>  
>  BUG_ON(!valid_irq_vector(vector));
>  
> @@ -223,7 +223,10 @@ static void _clear_irq_vector(struct irq_desc *desc)
>  trace_irq_mask(TRC_HW_IRQ_CLEAR_VECTOR, irq, vector, tmp_mask);
>  
>  if ( likely(!desc->arch.move_in_progress) )
> +{
> +put_scratch_cpumask();
>  return;
> +}

I think if possible such error path adjustments would better be
avoided. And this seems feasible here: There are two entirely
independent used of the scratch mask in this function. You could
therefore put the mask above from here, and get it again further
down, or you could leverage a property of the current
implementation, plus the fact that the 2nd use doesn't involved
any "real" function calls, and avoid a 2nd get/put altogether.

Of course another question then is whether it is a good property
of the current model, i.e. whether it wouldn't be better for
"put" to actually zap the pointer, to prevent subsequent use.

> @@ -2531,12 +2536,12 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
>  unsigned int irq;
>  static int warned;
>  struct irq_desc *desc;
> +cpumask_t *affinity = get_scratch_cpumask();
>  
>  for ( irq = 0; irq < nr_irqs; irq++ )
>  {
>  bool break_affinity = false, set_affinity = true;
>  unsigned int vector;
> -cpumask_t *affinity = this_cpu(scratch_cpumask);
>  
>  if ( irq == 2 )
>  continue;
> @@ -2640,6 +2645,8 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
> irq, CPUMASK_PR(affinity));
>  }
>  
> +put_scratch_cpumask();

Just as a remark, not necessarily as a request to change the code: I
wonder if down the road this pretty wide scope of "holding" the mask
isn't going to bite us, when a function called from here (in a range
of code not actively needing the mask) also may want to use the mask.
But of course we can make this finer grained at the point where it
might actually start mattering.

> @@ -3645,12 +3647,17 @@ long do_mmuext_op(
> mask)) )
>  rc = -EINVAL;
>  if ( unlikely(rc) )
> +{
> +put_scratch_cpumask();
>  break;
> +}

Again, instead of adjusting an error path, how about making this
have an empty statement (i.e. dropping the break) and ...

>  if ( op.cmd == MMUEXT_TLB_FLUSH_MULTI )

... having this become "else if()"?

> @@ -4384,6 +4393,9 @@ static int __do_update_va_mapping(
>  break;
>  }
>  
> +if ( mask && mask != d->dirty_cpumask )
> +put_scratch_cpumask();

The right side of the && here makes things feel a little fragile for
me.

> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -159,13 +159,15 @@ void msi_compose_msg(unsigned vector, const cpumask_t 
> *cpu_mask, struct msi_msg
>  
>  if ( cpu_mask )
>  {
> -cpumask_t *mask = this_cpu(scratch_cpumask);
> +cpumask_t *mask;
>  
>  if ( !cpumask_intersects(cpu_mask, &cpu_online_map) )
>  return;
>  
> +mask = get_scratch_cpumask();
>  cpumask_and(mask, cpu_mask, &cpu_online_map);
>  msg->dest32 = cpu_mask_to_apicid(mask);
> +put_scratch_cpumask();
>  }

This, I think, could do with a little more changing:

if ( cpu_mask )
{
cpumask_t *mask = get_scratch_cpumask();

cpumask_and(mask, cpu_mask, &cpu_online_map);
if ( !cpumask_empty(mask) )
msg->dest32 = cpu_mask_to_apicid(mask);
put_scratch_cpumask();
}

This way instead of looking twice at two cpumask_t instances, the
2nd one involves just one. Thoughts?

> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -25,6 +25,31 @@
>  #include 
>  #include 
>  
> +DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, scratch_cpumask);
> +
> 

Re: [Xen-devel] [PATCH] x86/vPMU: don't blindly assume IA32_PERF_CAPABILITIES MSR exists

[Jan Beulich]

On 26.02.2020 11:09, Roger Pau Monné wrote:
> On Wed, Feb 26, 2020 at 10:19:19AM +0100, Jan Beulich wrote:
>> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
>> be consulted first.
>>
>> Reported-by: Farrah Chen 
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/cpu/vpmu_intel.c
>> +++ b/xen/arch/x86/cpu/vpmu_intel.c
>> @@ -900,7 +900,6 @@ int vmx_vpmu_initialise(struct vcpu *v)
>>  
>>  int __init core2_vpmu_init(void)
>>  {
>> -u64 caps;
>>  unsigned int version = 0;
>>  unsigned int i;
>>  
>> @@ -932,8 +931,14 @@ int __init core2_vpmu_init(void)
>>  
>>  arch_pmc_cnt = core2_get_arch_pmc_count();
>>  fixed_pmc_cnt = core2_get_fixed_pmc_count();
>> -rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
>> -full_width_write = (caps >> 13) & 1;
>> +
>> +if ( cpu_has_pdcm )
>> +{
>> +uint64_t caps;
>> +
>> +rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
>> +full_width_write = (caps >> 13) & 1;
> 
> Will PMU work without PDCM?
> 
> I've been grepping the Intel SDMs, but the only mention is that PDCM
> signal the availability of MSR_IA32_PERF_CAPABILITIES.

Well, there's no other use of the MSR afaics except for getting
the one bit here, so I assume it'll work.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/sysctl: Don't return cpu policy data for compiled-out support

[Jan Beulich]

On 26.02.2020 10:58, Andrew Cooper wrote:
> On 26/02/2020 09:32, Jan Beulich wrote:
>> On 25.02.2020 18:31, Andrew Cooper wrote:
>>> Policy objects aren't tiny, and the derivation logic isn't trivial.  We are
>>> about to increase the number of policy objects, so take this opportunity to
>>> drop logic and storage space based on CONFIG_{PV,HVM}.
>> It doesn't look as if you were dropping either logic or storage space. With
>> this aspect taken care of (by adjusting wording, or by clarification of what
>> is meant) ...
>>
>>> Start by
> 
> That is this is here to signify.

How about s/take this/will have the/ in the sentence further up then?
To me, "Start by" in no way indicates that really there aren't any
savings yet. Might be my non-native English understanding of this
phrase, of course.

> No logic or storage space can be dropped until some #ifdef-ary is
> sprinkled around cpuid.c and msr.c, but I can't do any of that while
> there are unguarded external references to the objects.

Of course.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 4/5] x86/smp: use a dedicated scratch cpumask in send_IPI_mask

[Jan Beulich]

On 26.02.2020 11:18, Roger Pau Monné wrote:
> On Wed, Feb 26, 2020 at 11:07:44AM +0100, Jan Beulich wrote:
>> On 24.02.2020 11:46, Roger Pau Monne wrote:
>>> Using scratch_cpumask in send_IPI_mask is not safe because it can be
>>> called from interrupt context, and hence Xen would have to make sure
>>> all the users of the scratch cpumask disable interrupts while using
>>> it.
>>>
>>> Instead introduce a new cpumask to be used by send_IPI_mask, and
>>> disable interrupts while using it.
>>
>> The alternative of also adding ...
>>
>>> --- a/xen/arch/x86/smp.c
>>> +++ b/xen/arch/x86/smp.c
>>> @@ -59,6 +59,7 @@ static void send_IPI_shortcut(unsigned int shortcut, int 
>>> vector,
>>>  apic_write(APIC_ICR, cfg);
>>>  }
>>>  
>>> +DECLARE_PER_CPU(cpumask_var_t, send_ipi_cpumask);
>>>  /*
>>>   * send_IPI_mask(cpumask, vector): sends @vector IPI to CPUs in @cpumask,
>>>   * excluding the local CPU. @cpumask may be empty.
>>> @@ -67,7 +68,21 @@ static void send_IPI_shortcut(unsigned int shortcut, int 
>>> vector,
>>>  void send_IPI_mask(const cpumask_t *mask, int vector)
>>>  {
>>>  bool cpus_locked = false;
>>> -cpumask_t *scratch = this_cpu(scratch_cpumask);
>>> +cpumask_t *scratch = this_cpu(send_ipi_cpumask);
>>> +unsigned long flags;
>>> +
>>> +if ( in_mc() || in_nmi() )
>>
>> ... in_irq() here was considered, and discarded because of? With
>> this you'd not need the second CPU mask and you'd also be able
>> to avoid disabling an re-enabling IRQs.
> 
> I aimed to use the shorthand as much as possible, but I would also be
> fine with not using it in irq context. I assume there aren't that many
> flushes in irq context, and then the IPIs sent are probably not
> broadcast ones.

Well, here it's not just flushes, is it? Knowing some (typical)
IRQ context uses could allow us take a better decision. After
Sander's report, did you actually identify what path(s) the
earlier change broke?

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 4/5] x86/smp: use a dedicated scratch cpumask in send_IPI_mask

[Roger Pau Monné]

On Wed, Feb 26, 2020 at 11:45:40AM +0100, Jan Beulich wrote:
> On 26.02.2020 11:18, Roger Pau Monné wrote:
> > On Wed, Feb 26, 2020 at 11:07:44AM +0100, Jan Beulich wrote:
> >> On 24.02.2020 11:46, Roger Pau Monne wrote:
> >>> Using scratch_cpumask in send_IPI_mask is not safe because it can be
> >>> called from interrupt context, and hence Xen would have to make sure
> >>> all the users of the scratch cpumask disable interrupts while using
> >>> it.
> >>>
> >>> Instead introduce a new cpumask to be used by send_IPI_mask, and
> >>> disable interrupts while using it.
> >>
> >> The alternative of also adding ...
> >>
> >>> --- a/xen/arch/x86/smp.c
> >>> +++ b/xen/arch/x86/smp.c
> >>> @@ -59,6 +59,7 @@ static void send_IPI_shortcut(unsigned int shortcut, 
> >>> int vector,
> >>>  apic_write(APIC_ICR, cfg);
> >>>  }
> >>>  
> >>> +DECLARE_PER_CPU(cpumask_var_t, send_ipi_cpumask);
> >>>  /*
> >>>   * send_IPI_mask(cpumask, vector): sends @vector IPI to CPUs in @cpumask,
> >>>   * excluding the local CPU. @cpumask may be empty.
> >>> @@ -67,7 +68,21 @@ static void send_IPI_shortcut(unsigned int shortcut, 
> >>> int vector,
> >>>  void send_IPI_mask(const cpumask_t *mask, int vector)
> >>>  {
> >>>  bool cpus_locked = false;
> >>> -cpumask_t *scratch = this_cpu(scratch_cpumask);
> >>> +cpumask_t *scratch = this_cpu(send_ipi_cpumask);
> >>> +unsigned long flags;
> >>> +
> >>> +if ( in_mc() || in_nmi() )
> >>
> >> ... in_irq() here was considered, and discarded because of? With
> >> this you'd not need the second CPU mask and you'd also be able
> >> to avoid disabling an re-enabling IRQs.
> > 
> > I aimed to use the shorthand as much as possible, but I would also be
> > fine with not using it in irq context. I assume there aren't that many
> > flushes in irq context, and then the IPIs sent are probably not
> > broadcast ones.
> 
> Well, here it's not just flushes, is it?

No, this covers all IPIs. My remark was that flush IPIs are more
likely to target all CPUs than other IPIs, together with global
rendezvous but I assume those aren't that frequent.

> Knowing some (typical)
> IRQ context uses could allow us take a better decision. After
> Sander's report, did you actually identify what path(s) the
> earlier change broke?

No, I assume something related to passthrough, but I haven't been able
to trigger it myself.

Going for the easier solution right now seems like the most sensible
approach, we can always add a dedicated mask if necessary.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/vPMU: don't blindly assume IA32_PERF_CAPABILITIES MSR exists

[Andrew Cooper]

On 26/02/2020 10:39, Jan Beulich wrote:
> On 26.02.2020 11:09, Roger Pau Monné wrote:
>> On Wed, Feb 26, 2020 at 10:19:19AM +0100, Jan Beulich wrote:
>>> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
>>> be consulted first.
>>>
>>> Reported-by: Farrah Chen 
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/cpu/vpmu_intel.c
>>> +++ b/xen/arch/x86/cpu/vpmu_intel.c
>>> @@ -900,7 +900,6 @@ int vmx_vpmu_initialise(struct vcpu *v)
>>>  
>>>  int __init core2_vpmu_init(void)
>>>  {
>>> -u64 caps;
>>>  unsigned int version = 0;
>>>  unsigned int i;
>>>  
>>> @@ -932,8 +931,14 @@ int __init core2_vpmu_init(void)
>>>  
>>>  arch_pmc_cnt = core2_get_arch_pmc_count();
>>>  fixed_pmc_cnt = core2_get_fixed_pmc_count();
>>> -rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
>>> -full_width_write = (caps >> 13) & 1;
>>> +
>>> +if ( cpu_has_pdcm )
>>> +{
>>> +uint64_t caps;
>>> +
>>> +rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
>>> +full_width_write = (caps >> 13) & 1;
>> Will PMU work without PDCM?

The performance counter interface in CPUs predate the introduction of
PERF_CAPS.

>> I've been grepping the Intel SDMs, but the only mention is that PDCM
>> signal the availability of MSR_IA32_PERF_CAPABILITIES.
> Well, there's no other use of the MSR afaics except for getting
> the one bit here, so I assume it'll work.

It is an off-by-default, outside security support area of functionality
with known functional bugs outstanding against it.

"not crash" is a fine improvement on the status quo.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 07/23] xen/build: Use obj-y += subdir/ instead of subdir-y

[Anthony PERARD]

This is part of upgrading our build system and import more of Linux's
one.

In Linux, subdir-y in Makefiles is only used to descend into
subdirectory when there are no object to build, Xen doesn't have that
and all subdir have object to be included in the final binary.

To allow the new syntax, the "obj-y" and "subdir-*" calculation in
Rules.mk is changed and partially imported from Linux's Kbuild.

The command used to modify the Makefile was:
sed -i -r 's#^subdir-(.*)#obj-\1/#;' **/Makefile

Signed-off-by: Anthony PERARD 
---

Notes:
v3:
- no more tabs
- reshuffle variable, and remove __subdir-y

 xen/Rules.mk | 19 ---
 xen/arch/arm/Makefile| 14 +++---
 xen/arch/arm/arm32/Makefile  |  2 +-
 xen/arch/arm/arm64/Makefile  |  2 +-
 xen/arch/x86/Makefile| 18 +-
 xen/arch/x86/acpi/Makefile   |  2 +-
 xen/arch/x86/cpu/Makefile|  4 ++--
 xen/arch/x86/guest/Makefile  |  4 ++--
 xen/arch/x86/hvm/Makefile|  6 +++---
 xen/arch/x86/mm/Makefile |  4 ++--
 xen/arch/x86/x86_64/Makefile |  2 +-
 xen/common/Makefile  | 10 +-
 xen/drivers/Makefile | 14 +++---
 xen/drivers/acpi/Makefile|  6 +++---
 xen/drivers/passthrough/Makefile |  8 
 xen/drivers/passthrough/vtd/Makefile |  2 +-
 xen/lib/Makefile |  2 +-
 xen/xsm/Makefile |  2 +-
 xen/xsm/flask/Makefile   |  2 +-
 19 files changed, 60 insertions(+), 63 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index c7a067d25409..cc9c71bb1327 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -111,17 +111,14 @@ define gendep
 endef
 $(foreach o,$(filter-out %/,$(obj-y) $(obj-bin-y) $(extra-y)),$(eval $(call 
gendep,$(o
 
-# Ensure each subdirectory has exactly one trailing slash.
-subdir-n := $(patsubst %,%/,$(patsubst %/,%,$(subdir-n) $(subdir-)))
-subdir-y := $(patsubst %,%/,$(patsubst %/,%,$(subdir-y)))
-
-# Add explicitly declared subdirectories to the object lists.
-obj-y += $(patsubst %/,%/built_in.o,$(subdir-y))
-
-# Add implicitly declared subdirectories (in the object lists) to the
-# subdirectory list, and rewrite the object-list entry.
-subdir-y += $(filter %/,$(obj-y))
-obj-y:= $(patsubst %/,%/built-in.o,$(obj-y))
+# Handle objects in subdirs
+# ---
+# o if we encounter foo/ in $(obj-y), replace it by foo/built_in.o
+#   and add the directory to the list of dirs to descend into: $(subdir-y)
+subdir-y := $(subdir-y) $(filter %/, $(obj-y))
+obj-y:= $(patsubst %/, %/built_in.o, $(obj-y))
+
+subdir-n   := $(subdir-n) $(subdir-) $(filter %/, $(obj-n) $(obj-))
 
 subdir-all := $(subdir-y) $(subdir-n)
 
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 70f532e42a06..1044c2298a05 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -1,11 +1,11 @@
-subdir-$(CONFIG_ARM_32) += arm32
-subdir-$(CONFIG_ARM_64) += arm64
-subdir-$(CONFIG_ARM_64) += efi
-subdir-$(CONFIG_ACPI) += acpi
+obj-$(CONFIG_ARM_32) += arm32/
+obj-$(CONFIG_ARM_64) += arm64/
+obj-$(CONFIG_ARM_64) += efi/
+obj-$(CONFIG_ACPI) += acpi/
 ifneq ($(CONFIG_NO_PLAT),y)
-subdir-y += platforms
+obj-y += platforms/
 endif
-subdir-$(CONFIG_TEE) += tee
+obj-$(CONFIG_TEE) += tee/
 
 obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.init.o
@@ -48,7 +48,7 @@ obj-y += sysctl.o
 obj-y += time.o
 obj-y += traps.o
 obj-y += vcpreg.o
-subdir-$(CONFIG_NEW_VGIC) += vgic
+obj-$(CONFIG_NEW_VGIC) += vgic/
 ifneq ($(CONFIG_NEW_VGIC),y)
 obj-y += gic-vgic.o
 obj-y += vgic.o
diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 0ac254f34714..539bbef298a7 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -1,4 +1,4 @@
-subdir-y += lib
+obj-y += lib/
 
 obj-$(EARLY_PRINTK) += debug.o
 obj-y += domctl.o
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c4f3a28a0d0b..db8565b71a33 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,4 +1,4 @@
-subdir-y += lib
+obj-y += lib/
 
 obj-y += cache.o
 obj-$(CONFIG_HARDEN_BRANCH_PREDICTOR) += bpi.o
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index bce5fdb3170f..ed709e2373ac 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -1,12 +1,12 @@
-subdir-y += acpi
-subdir-y += cpu
-subdir-y += genapic
-subdir-$(CONFIG_GUEST) += guest
-subdir-$(CONFIG_HVM) += hvm
-subdir-y += mm
-subdir-$(CONFIG_XENOPROF) += oprofile
-subdir-$(CONFIG_PV) += pv
-subdir-y += x86_64
+obj-y += acpi/
+obj-y += cpu/
+obj-y += genapic/
+obj-$(CONFIG_GUEST) += guest/
+obj-$(CONFIG_HVM) += hvm/
+obj-y += mm/
+obj-$(CONFIG_XENOPROF) += oprofile/
+obj-$(CONFIG_PV) += pv/
+obj-y += x86_64/
 
 alternative-y := alternative.init.o
 alternative-$(CONFIG_LIVEPATCH) :=
diff --git a/x

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[Julien Grall]

Hi Paul,

On 25/02/2020 09:53, Paul Durrant wrote:

There's no particular reason shared_info need use a xenheap page.


AFAICT, a side-effect of this change is the shared_info is now going to 
be part of the migration stream. One issue with this is on the restore 
side, they will be accounted in number of pages allocated to the domain.


I am fairly certain dirty logging on page with PGC_extra set would not 
work properly as well.


As the pages will be recreated in the restore side, I would suggest to 
skip them in XEN_DOMCTL_getpageframeinfo3.



It's
only purpose is to be mapped by the guest so use a PGC_extra domheap page
instead. This does entail freeing shared_info during
domain_relinquish_resources() rather than domain_destroy() so care is
needed to avoid de-referencing a NULL shared_info pointer hence some
extra checks of 'is_dying' are needed.
ASSERTions are added before apparently vulnerable dereferences in the
event channel code. These should not be hit because domain_kill() calls
evtchn_destroy() before calling domain_relinquish_resources() but are
added to catch any future re-ordering.


IHMO, the ASSERTions in the event channel pending/mask/... helpers will 
not protect against re-ordering. You may never hit them even if there is 
a re-ordering. It would be better to add an ASSERT()/BUG_ON() in 
evtchn_destroy() and possibly a comment in domain_kill() to mention 
ordering.



For Arm, the call to free_shared_info() in arch_domain_destroy() is left
in place since it called in the error path for arch_domain_create().

NOTE: A modification in p2m_alloc_table() is required to avoid a false
   positive when checking for domain memory.
   A fix is also needed in dom0_construct_pv() to avoid automatically
   adding PGC_extra pages to the physmap.


I am not entirely sure how this is related to this patch. Was it a 
latent bug? If so, I think it would make sense to split it from this patch.




Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Volodymyr Babchuk 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Wei Liu 
---
  xen/arch/arm/domain.c|  2 ++
  xen/arch/x86/domain.c|  3 ++-
  xen/arch/x86/mm/p2m.c|  3 +--
  xen/arch/x86/pv/dom0_build.c |  4 
  xen/common/domain.c  | 25 +++--
  xen/common/event_2l.c|  4 
  xen/common/event_fifo.c  |  1 +
  xen/common/time.c|  3 +++
  8 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2cbcdaac08..3904519256 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1006,6 +1006,8 @@ int domain_relinquish_resources(struct domain *d)
  BUG();
  }
  
+free_shared_info(d);

+
  return 0;
  }
  
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c

index eb7b0fc51c..3ad532eccf 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -691,7 +691,6 @@ void arch_domain_destroy(struct domain *d)
  pv_domain_destroy(d);
  free_perdomain_mappings(d);
  
-free_shared_info(d);

  cleanup_domain_irq_mapping(d);
  
  psr_domain_free(d);

@@ -2246,6 +2245,8 @@ int domain_relinquish_resources(struct domain *d)
  if ( is_hvm_domain(d) )
  hvm_domain_relinquish_resources(d);
  
+free_shared_info(d);

+
  return 0;
  }
  
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c

index c5f428d67c..787d97d85e 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -695,8 +695,7 @@ int p2m_alloc_table(struct p2m_domain *p2m)
  
  p2m_lock(p2m);
  
-if ( p2m_is_hostp2m(p2m)

- && !page_list_empty(&d->page_list) )
+if ( p2m_is_hostp2m(p2m) && domain_tot_pages(d) )
  {
  P2M_ERROR("dom %d already has memory allocated\n", d->domain_id);
  p2m_unlock(p2m);
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index dc16ef2e79..f8f1bbe2f4 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -792,6 +792,10 @@ int __init dom0_construct_pv(struct domain *d,
  {
  mfn = mfn_x(page_to_mfn(page));
  BUG_ON(SHARED_M2P(get_gpfn_from_mfn(mfn)));
+
+if ( page->count_info & PGC_extra )
+continue;


I would add a comment explaining why we skip page with PGC_extra set.


+
  if ( get_gpfn_from_mfn(mfn) >= count )
  {
  BUG_ON(is_pv_32bit_domain(d));
diff --git a/xen/common/domain.c b/xen/common/domain.c
index ba7a905258..1d42fbcc0f 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -128,9 +128,9 @@ static void vcpu_info_reset(struct vcpu *v)
  {
  struct domain *d = v->domain;
  
-v->vcpu_info = ((v->vcpu_id < XEN_LEGACY_MAX_VCPUS)

+v->vcpu_info = (!d->is_dying && v->vcpu_id < XEN_LEGACY_MAX_VCPUS)
  ? (vcpu_info_t *)&shared_info(d, vcpu_info[v->vcpu_id])
-   

[Xen-devel] [XEN PATCH v3 09/23] xen/build: extract clean target from Rules.mk

[Anthony PERARD]

From: Anthony PERARD 

Most of the code executed by Rules.mk isn't necessary for the clean
target, especially not the CFLAGS. This patch makes running make clean
much faster.

The patch extract the clean target into a different Makefile,
Makefile.clean.

Since Makefile.clean, doesn't want to include Config.mk, we need to
define the variables DEPS_INCLUDE and DEPS in a place common to
Rules.mk and Makefile.clean, this is Kbuild.include. DEPS_RM is only
needed in Makefile.clean so can be defined there.

Even so Rules.mk includes Config.mk, it includes Kbuild.include after,
so the effective definition of DEPS_INCLUDE is "xen/" one and the
same one as used by Makefile.clean.

This is inspired by Kbuild, with Makefile.clean partially copied from
Linux v5.4.

Signed-off-by: Anthony PERARD 
---

Notes:
v3:
- rewrite of commit message
- have only subdir-all, without intermediare variable subdir-y and
  subdir-n in Makefile.clean

 xen/Rules.mk   | 12 
 xen/scripts/Kbuild.include |  7 ++-
 xen/scripts/Makefile.clean | 30 ++
 3 files changed, 36 insertions(+), 13 deletions(-)
 create mode 100644 xen/scripts/Makefile.clean

diff --git a/xen/Rules.mk b/xen/Rules.mk
index e3b19319b1f5..0c1a3ee5905d 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -100,8 +100,6 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
 
 include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
 
-DEPS = .*.d
-
 include Makefile
 
 define gendep
@@ -118,10 +116,6 @@ $(foreach o,$(filter-out %/,$(obj-y) $(obj-bin-y) 
$(extra-y)),$(eval $(call gend
 subdir-y := $(subdir-y) $(filter %/, $(obj-y))
 obj-y:= $(patsubst %/, %/built_in.o, $(obj-y))
 
-subdir-n   := $(subdir-n) $(subdir-) $(filter %/, $(obj-n) $(obj-))
-
-subdir-all := $(subdir-y) $(subdir-n)
-
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-DINIT_SECTIONS_ONLY
 
 ifeq ($(CONFIG_COVERAGE),y)
@@ -185,12 +179,6 @@ FORCE:
 %/built_in_bin.o: FORCE
$(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in_bin.o
 
-.PHONY: clean
-clean:: $(addprefix _clean_, $(subdir-all))
-   rm -f *.o .*.o.tmp *~ core $(DEPS_RM)
-_clean_%/: FORCE
-   $(MAKE) $(clean) $*
-
 SRCPATH := $(patsubst $(BASEDIR)/%,%,$(CURDIR))
 
 %.o: %.c Makefile
diff --git a/xen/scripts/Kbuild.include b/xen/scripts/Kbuild.include
index 2465cc4060c3..6a9b0c39da53 100644
--- a/xen/scripts/Kbuild.include
+++ b/xen/scripts/Kbuild.include
@@ -2,6 +2,11 @@
 
 # kbuild: Generic definitions
 
+###
+# dependencies
+DEPS = .*.d
+DEPS_INCLUDE = $(addsuffix .d2, $(basename $(wildcard $(DEPS
+
 # cc-ifversion
 # Usage:  EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1)
 cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && echo $(3) || 
echo $(4))
@@ -9,4 +14,4 @@ cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] 
&& echo $(3) || e
 # Shorthand for $(MAKE) clean
 # Usage:
 # $(MAKE) $(clean) dir
-clean := -f $(BASEDIR)/Rules.mk clean -C
+clean := -f $(BASEDIR)/scripts/Makefile.clean clean -C
diff --git a/xen/scripts/Makefile.clean b/xen/scripts/Makefile.clean
new file mode 100644
index ..53379e6102cc
--- /dev/null
+++ b/xen/scripts/Makefile.clean
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0
+# ==
+# Cleaning up
+# ==
+
+clean::
+
+include $(BASEDIR)/scripts/Kbuild.include
+
+include Makefile
+
+# Figure out what we need to clean from the various variables
+# ==
+subdir-all := $(subdir-y) $(subdir-n) $(subdir-) \
+  $(filter %/, $(obj-y) $(obj-n) $(obj-))
+
+DEPS_RM = $(DEPS) $(DEPS_INCLUDE)
+.PHONY: clean
+clean:: $(addprefix _clean_, $(subdir-all))
+   rm -f *.o .*.o.tmp *~ core $(DEPS_RM)
+
+# Descending
+# ---
+
+_clean_%/: FORCE
+   $(MAKE) $(clean) $*
+
+# Force execution of pattern rules (for which PHONY cannot be directly used).
+.PHONY: FORCE
+FORCE:
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 05/23] xen/build: Allow to test clang .include without asm symlink

[Anthony PERARD]

The clang test for "asm()-s support .include." needs to be modified
because the symbolic link asm -> asm-x86 may not exist when the test
is runned. Since it's an x86 test, we don't need the link.

This will be an issue with the following patch "xen/build: have the
root Makefile generates the CFLAGS".

Signed-off-by: Anthony PERARD 
---

Notes:
v3:
- new patch
  (needed for "xen/build: have the root Makefile generates the CFLAGS")

 xen/arch/x86/Rules.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index e69b8e697cc0..4b7ab784670c 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -26,7 +26,7 @@ $(call as-option-add,CFLAGS,CC,".L0: .L1: .skip (.L1 - 
.L0)",,\
  -no-integrated-as)
 
 # Check whether clang asm()-s support .include.
-$(call as-option-add,CFLAGS,CC,".include \"asm/indirect_thunk_asm.h\"",,\
+$(call as-option-add,CFLAGS,CC,".include \"asm-x86/indirect_thunk_asm.h\"",,\
  -no-integrated-as)
 
 # Check whether clang keeps .macro-s between asm()-s:
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 03/23] xen/build: Remove confusing comment on the %.s:%.S rule

[Anthony PERARD]

That comment was introduce by 3943db776371 ("[XEN] Can be built
-std=gnu99 (except for .S files).") to explain why CFLAGS was removed
from the command line. The comment is already written where the
-std=gnu flags gets remove from AFLAGS, no need to repeat it.

Signed-off-by: Anthony PERARD 
---

Notes:
v3:
- new patch

 xen/Rules.mk | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index d22a16d28282..c21203351a9f 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -230,7 +230,6 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): 
%.init.o: %.o Makefile
 %.s: %.c Makefile
$(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -S $< -o $@
 
-# -std=gnu{89,99} gets confused by # as an end-of-line comment marker
 %.s: %.S Makefile
$(CPP) $(filter-out -Wa$(comma)%,$(AFLAGS)) $< -o $@
 
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 02/23] Makefile: Fix install-tests

[Anthony PERARD]

The top-level makefile make uses of internal implementation detail of
the xen build system. Avoid that by creating a new target
"install-tests" in xen/Makefile, and by fixing the top-level Makefile
to not call xen/Rules.mk anymore.

Signed-off-by: Anthony PERARD 
Reviewed-by: Jan Beulich 
---

Notes:
v2.1:
- new patch, fix `make dist-tests` in osstest.

 Makefile | 6 ++
 xen/Makefile | 3 +++
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 512d6b73c898..9ad2602f63f0 100644
--- a/Makefile
+++ b/Makefile
@@ -155,13 +155,11 @@ install-docs:
 # We only have build-tests install-tests, not uninstall-tests etc.
 .PHONY: build-tests
 build-tests: build-xen
-   export BASEDIR=$(XEN_ROOT)/xen; \
-   $(MAKE) -f $$BASEDIR/Rules.mk -C xen/test build
+   $(MAKE) -C xen tests
 
 .PHONY: install-tests
 install-tests: install-xen
-   export BASEDIR=$(XEN_ROOT)/xen; \
-   $(MAKE) -f $$BASEDIR/Rules.mk -C xen/test install
+   $(MAKE) -C xen $@
 
 # build xen and the tools and place them in the install
 # directory. 'make install' should then copy them to the normal system
diff --git a/xen/Makefile b/xen/Makefile
index c326fee5880e..72bc89924622 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -90,6 +90,9 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 .PHONY: _tests
 _tests:
$(MAKE) -f $(BASEDIR)/Rules.mk -C test tests
+.PHONY: install-tests
+install-tests:
+   $(MAKE) -f $(BASEDIR)/Rules.mk -C test install
 
 .PHONY: _uninstall
 _uninstall: D=$(DESTDIR)
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 04/23] xen/build: remove use of AFLAGS-y

[Anthony PERARD]

And simply add directly to AFLAGS.

Signed-off-by: Anthony PERARD 
---

Notes:
v3:
- new patch

 xen/Rules.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index c21203351a9f..154269bfd96c 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -71,7 +71,7 @@ ifneq ($(CONFIG_CC_IS_CLANG),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif
 
-AFLAGS-y+= -D__ASSEMBLY__
+AFLAGS += -D__ASSEMBLY__
 
 ALL_OBJS := $(ALL_OBJS-y)
 
@@ -85,7 +85,7 @@ CFLAGS += $(EXTRA_CFLAGS_XEN_CORE)
 # Most CFLAGS are safe for assembly files:
 #  -std=gnu{89,99} gets confused by #-prefixed end-of-line comments
 #  -flto makes no sense and annoys clang
-AFLAGS += $(AFLAGS-y) $(filter-out -std=gnu% -flto,$(CFLAGS))
+AFLAGS += $(filter-out -std=gnu% -flto,$(CFLAGS))
 
 # LDFLAGS are only passed directly to $(LD)
 LDFLAGS += $(LDFLAGS_DIRECT)
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 06/23] xen/build: Fix section-renaming of libfdt and libelf

[Anthony PERARD]

In common/libelf/Makefile, when SECTIONS gets defined
SPECIAL_DATA_SECTIONS doesn't exist, so only "text data" sections are
been renamed. This was different before 48115d14743e ("Move more
kernel decompression bits to .init.* sections").

Move SPECIAL_DATA_SECTIONS in Rules.mk before including "Makefile" to
fix this.

Signed-off-by: Anthony PERARD 
---
 xen/Rules.mk | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 154269bfd96c..c7a067d25409 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -92,6 +92,12 @@ LDFLAGS += $(LDFLAGS_DIRECT)
 
 LDFLAGS += $(LDFLAGS-y)
 
+SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
+$(foreach w,1 2 4, \
+rodata.str$(w).$(a)) \
+rodata.cst$(a)) \
+ $(foreach r,rel rel.ro,data.$(r).local)
+
 include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
 
 DEPS = .*.d
@@ -206,12 +212,6 @@ endif
 %.o: %.S Makefile
$(CC) $(AFLAGS) -c $< -o $@
 
-SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
-   $(foreach w,1 2 4, \
-   rodata.str$(w).$(a)) \
-   rodata.cst$(a)) \
-$(foreach r,rel rel.ro,data.$(r).local)
-
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' | while read idx name 
sz rest; do \
case "$$name" in \
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 08/23] xen/build: use $(clean) shorthand for clean targets

[Anthony PERARD]

From: Anthony PERARD 

Collect all the clean targets as we are going to modify it shortly.
Also, this is inspired by Linux's Kbuild.

"Kbuild.include" isn't included by "Makefile", but the "_clean" target
is only used by Rules.mk which include Kbuild.include.

Signed-off-by: Anthony PERARD 
Reviewed-by: Jan Beulich 
---
 xen/Makefile   | 16 
 xen/Rules.mk   |  2 +-
 xen/scripts/Kbuild.include |  5 +
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 72bc89924622..65bd913cd133 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -120,14 +120,14 @@ _debug:
 .PHONY: _clean
 _clean: delete-unfresh-files
$(MAKE) -C tools clean
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C include clean
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C common clean
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C drivers clean
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/arm clean
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/x86 clean
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
+   $(MAKE) $(clean) include
+   $(MAKE) $(clean) common
+   $(MAKE) $(clean) drivers
+   $(MAKE) $(clean) xsm
+   $(MAKE) $(clean) crypto
+   $(MAKE) $(clean) arch/arm
+   $(MAKE) $(clean) arch/x86
+   $(MAKE) $(clean) test
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) clean
find . \( -name "*.o" -o -name ".*.d" -o -name ".*.d2" -o -name 
"*.gcno" \) -exec rm -f {} \;
rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi 
$(TARGET).efi.map $(TARGET)-syms $(TARGET)-syms.map *~ core
diff --git a/xen/Rules.mk b/xen/Rules.mk
index cc9c71bb1327..e3b19319b1f5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -189,7 +189,7 @@ FORCE:
 clean:: $(addprefix _clean_, $(subdir-all))
rm -f *.o .*.o.tmp *~ core $(DEPS_RM)
 _clean_%/: FORCE
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C $* clean
+   $(MAKE) $(clean) $*
 
 SRCPATH := $(patsubst $(BASEDIR)/%,%,$(CURDIR))
 
diff --git a/xen/scripts/Kbuild.include b/xen/scripts/Kbuild.include
index a5c462fd9777..2465cc4060c3 100644
--- a/xen/scripts/Kbuild.include
+++ b/xen/scripts/Kbuild.include
@@ -5,3 +5,8 @@
 # cc-ifversion
 # Usage:  EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1)
 cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && echo $(3) || 
echo $(4))
+
+# Shorthand for $(MAKE) clean
+# Usage:
+# $(MAKE) $(clean) dir
+clean := -f $(BASEDIR)/Rules.mk clean -C
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 00/23] xen: Build system improvements

[Anthony PERARD]

Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git 
br.build-system-xen-v3

v3:
- new patches that do some cleanup or fix issues
- have rework most patches, to have better commit message or change the coding
  style, or fix issues that I've seen. There were some cases where CFLAGS were
  missing.
  See patch notes for details
- introduce if_changed*. That plenty of new patches on top of what we had in v2.
  (those changes ignore CONFIG_LTO=y, I'll see about fixing that later)

(There is more to come in order to use fixdep from Linux, but that's not ready)

v2.1:
- some fixes

v2:
Rather than taking Kbuild and making it work with Xen, the v2 takes the opposite
approach of slowly transforming our current build system into Kbuild. That have
the advantage of keeping all the feature we have and making the patches much
easier to review. Kconfig update is done in an other patch series.

Hi,

I have work toward building Xen (the hypervisor) with Linux's build system,
Kbuild.

The main reason for that is to be able to have out-of-tree build. It's annoying
when a build fail because of the pvshim. Other benefit is a much faster
rebuild, and `make clean` doesn't take ages, and better dependencies to figure
out what needs to be rebuild.

So, we are not there yet, but the series already contain quite a few
improvement and cleanup. More patches are going to be added to the series.

Cheers,

Anthony PERARD (23):
  xen/include: remove include of Config.mk
  Makefile: Fix install-tests
  xen/build: Remove confusing comment on the %.s:%.S rule
  xen/build: remove use of AFLAGS-y
  xen/build: Allow to test clang .include without asm symlink
  xen/build: Fix section-renaming of libfdt and libelf
  xen/build: Use obj-y += subdir/ instead of subdir-y
  xen/build: use $(clean) shorthand for clean targets
  xen/build: extract clean target from Rules.mk
  xen/build: run targets csopes,tags,.. without Rules.mk
  xen/build: make tests in test/ directly
  xen/build: Move as-option-add to xen/
  xen/build: include include/config/auto.conf in main Makefile
  xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)
  xen/build: have the root Makefile generates the CFLAGS
  xen/build: introduce if_changed and if_changed_rule
  xen/build: Start using if_changed
  xen/build: use if_changed on built_in.o
  xen/build: Use if_changed_rules with %.o:%.c targets
  xen/build: factorise generation of the linker scripts
  xen/build: Use if_changed for prelink*.o
  xen,symbols: rework file symbols selection
  xen/build: use if_changed to build guest_%.o

 .gitignore   |   1 +
 Config.mk|  17 --
 Makefile |   6 +-
 xen/Makefile | 257 -
 xen/Rules.mk | 269 +++
 xen/arch/arm/Makefile|  33 ++--
 xen/arch/arm/Rules.mk|  93 -
 xen/arch/arm/arch.mk |  88 +
 xen/arch/arm/arm32/Makefile  |   2 +-
 xen/arch/arm/arm64/Makefile  |   2 +-
 xen/arch/arm/efi/Makefile|   2 +-
 xen/arch/x86/Makefile|  55 +++---
 xen/arch/x86/Rules.mk|  91 +
 xen/arch/x86/acpi/Makefile   |   2 +-
 xen/arch/x86/arch.mk |  84 +
 xen/arch/x86/cpu/Makefile|   4 +-
 xen/arch/x86/efi/Makefile|   9 +-
 xen/arch/x86/guest/Makefile  |   4 +-
 xen/arch/x86/hvm/Makefile|   6 +-
 xen/arch/x86/mm/Makefile |  19 +-
 xen/arch/x86/mm/hap/Makefile |  15 +-
 xen/arch/x86/mm/shadow/Makefile  |  15 +-
 xen/arch/x86/x86_64/Makefile |   2 +-
 xen/common/Makefile  |  10 +-
 xen/common/libelf/Makefile   |  14 +-
 xen/common/libfdt/Makefile   |  11 +-
 xen/drivers/Makefile |  14 +-
 xen/drivers/acpi/Makefile|   6 +-
 xen/drivers/passthrough/Makefile |   8 +-
 xen/drivers/passthrough/vtd/Makefile |   2 +-
 xen/include/Makefile |   4 +-
 xen/lib/Makefile |   2 +-
 xen/scripts/Kbuild.include   | 134 +
 xen/scripts/Makefile.clean   |  30 +++
 xen/tools/symbols.c  |  22 ++-
 xen/xsm/Makefile |   2 +-
 xen/xsm/flask/Makefile   |  21 ++-
 xen/xsm/flask/ss/Makefile|   2 +-
 38 files changed, 870 insertions(+), 488 deletions(-)
 create mode 100644 xen/arch/arm/arch.mk
 create mode 100644 xen/arch/x86/arch.mk
 create mode 100644 xen/scripts/Makefile.clean

-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 01/23] xen/include: remove include of Config.mk

[Anthony PERARD]

It isn't necessary to include Config.mk here because this Makefile is
only used by xen/Rules.mk which already includes Config.mk.

Signed-off-by: Anthony PERARD 
Reviewed-by: Jan Beulich 
---
 xen/include/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/xen/include/Makefile b/xen/include/Makefile
index fde0ca013121..433bad9055b2 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -1,5 +1,3 @@
-include $(XEN_ROOT)/Config.mk
-
 ifneq ($(CONFIG_COMPAT),)
 
 compat-arch-$(CONFIG_X86) := x86_32
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 20/23] xen/build: factorise generation of the linker scripts

[Anthony PERARD]

In Arm and X86 makefile, generating the linker script is the same, so
we can simply have both call the same macro.

We need to add *.lds files into extra-y so that Rules.mk can find the
.*.cmd dependency file and load it.

Signed-off-by: Anthony PERARD 
---
 xen/Rules.mk  | 8 
 xen/arch/arm/Makefile | 5 ++---
 xen/arch/x86/Makefile | 6 +++---
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 8c7dba9211d1..02cd37d04054 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -230,6 +230,14 @@ cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< 
-o $@
 %.s: %.S FORCE
$(call if_changed,cpp_s_S)
 
+# Linker scripts, .lds.S -> .lds
+quiet_cmd_cc_lds_S = LDS $@
+define cmd_cc_lds_S
+$(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<; \
+sed -e 's/.*\.lds\.o:/$(@F):/g' <$(dot-target).d >$(dot-target).d.new; \
+mv -f $(dot-target).d.new $(dot-target).d
+endef
+
 # Add intermediate targets:
 # When building objects with specific suffix patterns, add intermediate
 # targets that the final targets are derived from.
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 37ca6d25c08e..b3ee4adb9ac4 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -124,9 +124,8 @@ asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
$(CC) $(filter-out -flto,$(c_flags)) -S -o $@ $<
 
 xen.lds: xen.lds.S
-   $(CC) -P -E -Ui386 $(a_flags) -o $@ $<
-   sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
-   mv -f .xen.lds.d.new .xen.lds.d
+   $(call if_changed,cc_lds_S)
+extra-y += xen.lds
 
 dtb.o: $(CONFIG_DTB_FILE)
 
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 6fb6cafdf47b..1be94846e11f 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -75,6 +75,7 @@ obj-y += hpet.o
 obj-y += vm_event.o
 obj-y += xstate.o
 extra-y += asm-macros.i
+extra-y += xen.lds
 
 x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
 
@@ -197,6 +198,7 @@ endif
 note_file_option ?= $(note_file)
 
 ifeq ($(XEN_BUILD_PE),y)
+extra-y += efi.lds
 $(TARGET).efi: prelink-efi.o $(note_file) efi.lds efi/relocs-dummy.o 
efi/mkreloc
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
  $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< 
efi/relocs-dummy.o \
@@ -244,9 +246,7 @@ $(BASEDIR)/include/asm-x86/asm-macros.h: asm-macros.i 
Makefile
 
 efi.lds: AFLAGS-y += -DEFI
 xen.lds efi.lds: xen.lds.S
-   $(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $<
-   sed -e 's/.*\.lds\.o:/$(@F):/g' <.$(@F).d >.$(@F).d.new
-   mv -f .$(@F).d.new .$(@F).d
+   $(call if_changed,cc_lds_S)
 
 boot/mkelf32: boot/mkelf32.c
$(HOSTCC) $(HOSTCFLAGS) -o $@ $<
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 11/23] xen/build: make tests in test/ directly

[Anthony PERARD]

It is unnecessary to make _tests via Rules.mk because the target
use Rules.mk as well.

Signed-off-by: Anthony PERARD 
Reviewed-by: Jan Beulich 
---
 xen/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 10bc4bf3646c..8267ace51b0d 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -51,8 +51,8 @@ dist: install
 
 build install:: include/config/auto.conf
 
-.PHONY: build install uninstall clean distclean MAP tests
-build install uninstall debug clean distclean MAP tests::
+.PHONY: build install uninstall clean distclean MAP
+build install uninstall debug clean distclean MAP::
 ifneq ($(XEN_TARGET_ARCH),x86_32)
$(MAKE) -f Rules.mk _$@
 else
@@ -92,8 +92,8 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
fi; \
fi
 
-.PHONY: _tests
-_tests:
+.PHONY: tests
+tests:
$(MAKE) -f $(BASEDIR)/Rules.mk -C test tests
 .PHONY: install-tests
 install-tests:
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 18/23] xen/build: use if_changed on built_in.o

[Anthony PERARD]

In the case where $(obj-y) is empty, we also replace $(c_flags) by
$(XEN_CFLAGS) to avoid generating an .%.d dependency file. This avoid
make trying to include %.h file in the ld command if $(obj-y) isn't
empty anymore on a second run.

Signed-off-by: Anthony PERARD 
---
 xen/Rules.mk | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index bb4ced5f0dd4..cbf4feba0e0f 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -126,14 +126,21 @@ include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
 c_flags += $(CFLAGS-y)
 a_flags += $(CFLAGS-y) $(AFLAGS-y)
 
-built_in.o: $(obj-y) $(extra-y)
+quiet_cmd_ld_builtin = LD  $@
+cmd_ld_builtin = \
+$(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$(real-prereqs))
+quiet_cmd_cc_builtin = LD  $@
+cmd_cc_builtin = \
+$(CC) $(XEN_CFLAGS) -c -x c /dev/null -o $@
+
+built_in.o: $(obj-y) $(extra-y) FORCE
 ifeq ($(obj-y),)
-   $(CC) $(c_flags) -c -x c /dev/null -o $@
+   $(call if_changed,cc_builtin)
 else
 ifeq ($(CONFIG_LTO),y)
$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
 else
-   $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
+   $(call if_changed,ld_builtin)
 endif
 endif
 
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 22/23] xen, symbols: rework file symbols selection

[Anthony PERARD]

Rework symbols so it prefer file symbols that names an object file to
file symbols that have a directory component.

But have symbols still prefer the first file symbol if one of the above
is true, or prefer the second file symbols if it names a source file
without directory component.

In a future patch, we are going want to run $(CC) from the root directory
(xen.git/xen that is). So the guest_walk_%.o files are going to have
two file symbols, one with a directory component and another one
which name an object file. We still want to prefer the file symbols
that names an object file, no mater if it is first or second.

And before running everything from the root directory, we will be able
to use the same runes to build the guest_%.o as to build any other %.o
files from %.c files (the rule with the objcopy --redefine-sym).

Signed-off-by: Anthony PERARD 
---
 xen/tools/symbols.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/xen/tools/symbols.c b/xen/tools/symbols.c
index 9f9e2c990061..b7a00b4be487 100644
--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -80,11 +80,17 @@ static inline int is_arm_mapping_symbol(const char *str)
   && (str[2] == '\0' || str[2] == '.');
 }
 
+enum symbol_type {
+ symbol = 0,
+ single_source = 1,
+ dir_source = 2,
+ obj_source = 3,
+};
 static int read_symbol(FILE *in, struct sym_entry *s)
 {
char str[500], type[20] = "";
char *sym, stype;
-   static enum { symbol, single_source, multi_source } last;
+   static enum symbol_type last;
static char *filename;
int rc = -1;
 
@@ -125,13 +131,19 @@ static int read_symbol(FILE *in, struct sym_entry *s)
 * prefer the first one if that names an object file or has a
 * directory component (to cover multiply compiled files).
 */
-   bool multi = strchr(str, '/') || (sym && sym[1] == 'o');
-
-   if (multi || last != multi_source) {
+   enum symbol_type current;
+   if (sym && sym[1] == 'o')
+   current = obj_source;
+   else if (strchr(str, '/'))
+   current = dir_source;
+   else
+   current = single_source;
+
+   if (current > last || last == single_source) {
free(filename);
filename = *str ? strdup(str) : NULL;
+   last = current;
}
-   last = multi ? multi_source : single_source;
goto skip_tail;
}
 
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 14/23] xen/build: use new $(c_flags) and $(a_flags) instead of $(CFLAGS)

[Anthony PERARD]

From: Anthony PERARD 

In a later patch ("xen/build: have the root Makefile generates the
CFLAGS), we want to generate the CFLAGS in xen/Makefile, then export
it and have Rules.mk use a CFLAGS from the environment variables. That
changes the flavor of the CFLAGS and flags intended for one target
(like -D__OBJECT_FILE__ and -M%) gets propagated and duplicated. So we
start by moving such flags out of $(CFLAGS) and into $(c_flags) which
is to be modified by only Rules.mk.

__OBJECT_FILE__ is only used by arch/x86/mm/*.c files, so having it in
$(c_flags) is enough, we don't need it in $(a_flags).

For include/Makefile and as-insn we can keep using CFLAGS, but since
it doesn't have -M* flags anymore there is no need to filter them out.

The XEN_BUILD_EFI tests in arch/x86/Makefile was filtering out
CFLAGS-y, but according to dd40177c1bc8 ("x86-64/EFI: add CFLAGS to
check compile"), it was done to filter out -MF. CFLAGS doesn't
have those flags anymore, so no filtering is needed.

This is inspired by the way Kbuild generates CFLAGS for each targets.

Signed-off-by: Anthony PERARD 
---

Notes:
v3:
- include/Makefile: Keep using CFLAGS, but since it doesn't have -M*
  flags anymore, no need to filter it.
- Write c_flags and a_flags on a single line.
- arch/x86/Makefile: remove the filter-out of dependency flags
  they are remove from CFLAGS anyway.
  (was intended to be done in xen/build: have the root Makefile
  generates the CFLAGS originally, move the change to this patch).
- also modify as-insn as it is now xen/ only.

 xen/Rules.mk| 23 +++
 xen/arch/arm/Makefile   |  4 ++--
 xen/arch/x86/Makefile   |  6 +++---
 xen/arch/x86/mm/Makefile|  6 +++---
 xen/arch/x86/mm/hap/Makefile|  6 +++---
 xen/arch/x86/mm/shadow/Makefile |  6 +++---
 xen/include/Makefile|  2 +-
 xen/scripts/Kbuild.include  |  2 +-
 8 files changed, 27 insertions(+), 28 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 92a13ca60163..4aa119a90c27 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -57,7 +57,6 @@ CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
 $(call cc-option-add,CFLAGS,CC,-Wvla)
 CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS-$(CONFIG_DEBUG_INFO) += -g
-CFLAGS += '-D__OBJECT_FILE__="$@"'
 
 ifneq ($(CONFIG_CC_IS_CLANG),y)
 # Clang doesn't understand this command line argument, and doesn't appear to
@@ -70,9 +69,6 @@ AFLAGS += -D__ASSEMBLY__
 
 ALL_OBJS := $(ALL_OBJS-y)
 
-# Get gcc to generate the dependencies for us.
-CFLAGS-y += -MMD -MF $(@D)/.$(@F).d
-
 CFLAGS += $(CFLAGS-y)
 # allow extra CFLAGS externally via EXTRA_CFLAGS_XEN_CORE
 CFLAGS += $(EXTRA_CFLAGS_XEN_CORE)
@@ -146,9 +142,12 @@ endif
 # Always build obj-bin files as binary even if they come from C source. 
 $(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
 
+c_flags = -MMD -MF $(@D)/.$(@F).d $(CFLAGS) '-D__OBJECT_FILE__="$@"'
+a_flags = -MMD -MF $(@D)/.$(@F).d $(AFLAGS)
+
 built_in.o: $(obj-y) $(extra-y)
 ifeq ($(obj-y),)
-   $(CC) $(CFLAGS) -c -x c /dev/null -o $@
+   $(CC) $(c_flags) -c -x c /dev/null -o $@
 else
 ifeq ($(CONFIG_LTO),y)
$(LD_LTO) -r -o $@ $(filter-out $(extra-y),$^)
@@ -159,7 +158,7 @@ endif
 
 built_in_bin.o: $(obj-bin-y) $(extra-y)
 ifeq ($(obj-bin-y),)
-   $(CC) $(AFLAGS) -c -x assembler /dev/null -o $@
+   $(CC) $(a_flags) -c -x assembler /dev/null -o $@
 else
$(LD) $(LDFLAGS) -r -o $@ $(filter-out $(extra-y),$^)
 endif
@@ -178,7 +177,7 @@ SRCPATH := $(patsubst $(BASEDIR)/%,%,$(CURDIR))
 
 %.o: %.c Makefile
 ifeq ($(CONFIG_ENFORCE_UNIQUE_SYMBOLS),y)
-   $(CC) $(CFLAGS) -c $< -o $(@D)/.$(@F).tmp -MQ $@
+   $(CC) $(c_flags) -c $< -o $(@D)/.$(@F).tmp -MQ $@
 ifeq ($(CONFIG_CC_IS_CLANG),y)
$(OBJCOPY) --redefine-sym $<=$(SRCPATH)/$< $(@D)/.$(@F).tmp $@
 else
@@ -186,11 +185,11 @@ else
 endif
rm -f $(@D)/.$(@F).tmp
 else
-   $(CC) $(CFLAGS) -c $< -o $@
+   $(CC) $(c_flags) -c $< -o $@
 endif
 
 %.o: %.S Makefile
-   $(CC) $(AFLAGS) -c $< -o $@
+   $(CC) $(a_flags) -c $< -o $@
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' | while read idx name 
sz rest; do \
@@ -205,12 +204,12 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): 
%.init.o: %.o Makefile
$(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section 
.$(s)=.init.$(s)) $< $@
 
 %.i: %.c Makefile
-   $(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) $< -o $@
+   $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@
 
 %.s: %.c Makefile
-   $(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -S $< -o $@
+   $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
 
 %.s: %.S Makefile
-   $(CPP) $(filter-out -Wa$(comma)%,$(AFLAGS)) $< -o $@
+   $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
 
 -include $(DEPS_INCLUDE)
diff --git a/xen/

[Xen-devel] [XEN PATCH v3 19/23] xen/build: Use if_changed_rules with %.o:%.c targets

[Anthony PERARD]

Use $(dot-target) to have the target name prefix with a dot.

Now, when the CC command has run, it is recorded in .*.cmd
file, then if_changed_rules will compare it on subsequent runs.

Signed-off-by: Anthony PERARD 
---
 xen/Rules.mk | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index cbf4feba0e0f..8c7dba9211d1 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -167,19 +167,27 @@ FORCE:
 
 SRCPATH := $(patsubst $(BASEDIR)/%,%,$(CURDIR))
 
-%.o: %.c Makefile
+quiet_cmd_cc_o_c = CC  $@
 ifeq ($(CONFIG_ENFORCE_UNIQUE_SYMBOLS),y)
-   $(CC) $(c_flags) -c $< -o $(@D)/.$(@F).tmp -MQ $@
-ifeq ($(CONFIG_CC_IS_CLANG),y)
-   $(OBJCOPY) --redefine-sym $<=$(SRCPATH)/$< $(@D)/.$(@F).tmp $@
-else
-   $(OBJCOPY) --redefine-sym $(https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 12/23] xen/build: Move as-option-add to xen/

[Anthony PERARD]

Only xen/ uses as-option-add and as-insn, so there aren't needed in
Config.mk.

Signed-off-by: Anthony PERARD 
---

Notes:
v3:
- new patch

 Config.mk  | 17 -
 xen/scripts/Kbuild.include | 17 +
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/Config.mk b/Config.mk
index 65649d6122d1..dc6e7d03dffe 100644
--- a/Config.mk
+++ b/Config.mk
@@ -143,23 +143,6 @@ ifndef XEN_HAS_CHECKPOLICY
 export XEN_HAS_CHECKPOLICY
 endif
 
-# as-insn: Check whether assembler supports an instruction.
-# Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",option-yes,option-no)
-as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
-   | $(filter-out -M% %.d -include 
%/include/xen/config.h,$(1)) \
-  -c -x c -o /dev/null - 2>&1),$(4),$(3))
-
-# as-option-add: Conditionally add options to flags
-# Usage: $(call as-option-add,CFLAGS,CC,"insn",option-yes,option-no)
-as-option-add = $(eval $(call as-option-add-closure,$(1),$(2),$(3),$(4),$(5)))
-define as-option-add-closure
-ifeq ($$(call as-insn,$$($(2)) $$($(1)),$(3),y,n),y)
-$(1) += $(4)
-else
-$(1) += $(5)
-endif
-endef
-
 define buildmakevars2shellvars
 export PREFIX="$(prefix)";\
 export XEN_SCRIPT_DIR="$(XEN_SCRIPT_DIR)";\
diff --git a/xen/scripts/Kbuild.include b/xen/scripts/Kbuild.include
index 6a9b0c39da53..806c68824ed5 100644
--- a/xen/scripts/Kbuild.include
+++ b/xen/scripts/Kbuild.include
@@ -7,6 +7,23 @@
 DEPS = .*.d
 DEPS_INCLUDE = $(addsuffix .d2, $(basename $(wildcard $(DEPS
 
+# as-insn: Check whether assembler supports an instruction.
+# Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",option-yes,option-no)
+as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
+   | $(filter-out -M% %.d -include 
%/include/xen/config.h,$(1)) \
+  -c -x c -o /dev/null - 2>&1),$(4),$(3))
+
+# as-option-add: Conditionally add options to flags
+# Usage: $(call as-option-add,CFLAGS,CC,"insn",option-yes,option-no)
+as-option-add = $(eval $(call as-option-add-closure,$(1),$(2),$(3),$(4),$(5)))
+define as-option-add-closure
+ifeq ($$(call as-insn,$$($(2)) $$($(1)),$(3),y,n),y)
+$(1) += $(4)
+else
+$(1) += $(5)
+endif
+endef
+
 # cc-ifversion
 # Usage:  EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1)
 cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && echo $(3) || 
echo $(4))
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 10/23] xen/build: run targets csopes, tags, .. without Rules.mk

[Anthony PERARD]

Those targets make use of $(all_sources) which depends on TARGET_ARCH,
so we just need to set TARGET_ARCH earlier and once.

XEN_TARGET_ARCH isn't expected to change during the build, so
TARGET_SUBARCH and TARGET_ARCH aren't going to change either. Set them
once and for all in the Xen root Makefile. This allows to run more
targets without Rules.mk.

XEN_TARGET_ARCH is actually changed in arch/x86/boot/build32.mk, but
it doesn't use the TARGET_{,SUB}ARCH variables either, and doesn't use
Rules.mk (it replaces it).

TARGET_{,SUB}ARCH are no longer overridden because that would have
no effect on the values that Rules.mk will use.

Signed-off-by: Anthony PERARD 
---

Notes:
v3:
- Improve commit message, try to explain why override disappeared

 xen/Makefile | 25 +++--
 xen/Rules.mk |  5 -
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 65bd913cd133..10bc4bf3646c 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -35,6 +35,11 @@ SRCARCH=$(shell echo $(ARCH) | sed -e 's/x86.*/x86/' -e 
s'/arm\(32\|64\)/arm/g')
 # we need XEN_TARGET_ARCH to generate the proper config
 include $(XEN_ROOT)/Config.mk
 
+# Set ARCH/SUBARCH appropriately.
+export TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
+export TARGET_ARCH := $(shell echo $(XEN_TARGET_ARCH) | \
+sed -e 's/x86.*/x86/' -e s'/arm\(32\|64\)/arm/g')
+
 # Allow someone to change their config file
 export KCONFIG_CONFIG ?= .config
 
@@ -46,8 +51,8 @@ dist: install
 
 build install:: include/config/auto.conf
 
-.PHONY: build install uninstall clean distclean cscope TAGS tags MAP gtags 
tests
-build install uninstall debug clean distclean cscope TAGS tags MAP gtags 
tests::
+.PHONY: build install uninstall clean distclean MAP tests
+build install uninstall debug clean distclean MAP tests::
 ifneq ($(XEN_TARGET_ARCH),x86_32)
$(MAKE) -f Rules.mk _$@
 else
@@ -223,25 +228,25 @@ endef
 xenversion:
@echo $(XEN_FULLVERSION)
 
-.PHONY: _TAGS
-_TAGS: 
+.PHONY: TAGS
+TAGS:
set -e; rm -f TAGS; \
$(call set_exuberant_flags,etags); \
$(all_sources) | xargs etags $$exuberant_flags -a
 
-.PHONY: _tags
-_tags: 
+.PHONY: tags
+tags:
set -e; rm -f tags; \
$(call set_exuberant_flags,ctags); \
$(all_sources) | xargs ctags $$exuberant_flags -a
 
-.PHONY: _gtags
-_gtags:
+.PHONY: gtags
+gtags:
set -e; rm -f GTAGS GSYMS GPATH GRTAGS
$(all_sources) | gtags -f -
 
-.PHONY: _cscope
-_cscope:
+.PHONY: cscope
+cscope:
$(all_sources) > cscope.files
cscope -k -b -q
 
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 0c1a3ee5905d..92a13ca60163 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -27,11 +27,6 @@ ifneq ($(origin verbose),undefined)
 $(error "You must use 'make menuconfig' to enable/disable verbose now.")
 endif
 
-# Set ARCH/SUBARCH appropriately.
-override TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
-override TARGET_ARCH := $(shell echo $(XEN_TARGET_ARCH) | \
-  sed -e 's/x86.*/x86/' -e s'/arm\(32\|64\)/arm/g')
-
 TARGET := $(BASEDIR)/xen
 
 # Note that link order matters!
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 15/23] xen/build: have the root Makefile generates the CFLAGS

[Anthony PERARD]

Instead of generating the CFLAGS in Rules.mk everytime we enter a new
subdirectory, we are going to generate most of them a single time, and
export the result in the environment so that Rules.mk can use it.  The
only flags left to generates are the one that depends on the targets,
but the variable $(c_flags) takes care of that.

Arch specific CFLAGS are generated by a new file "arch/*/arch.mk"
which is included by the root Makefile.

We export the *FLAGS via the environment variables XEN_*FLAGS because
Rules.mk still includes Config.mk and would add duplicated flags to
CFLAGS.

When running Rules.mk in the root directory (xen/), the variable
`root-make-done' is set, so `need-config' will remain undef and so the
root Makefile will not generate the cflags again.

We can't use CFLAGS in subdirectories to add flags to particular
targets, instead start to use CFLAGS-y. Idem for AFLAGS.
So there are two different CFLAGS-y, the one in xen/Makefile (and
arch.mk), and the one in subdirs that Rules.mk is going to use.
We can't add to XEN_CFLAGS because it is exported, so making change to
it might be propagated to subdirectory which isn't intended.

Some style change are introduced in this patch:
when LDFLAGS_DIRECT is included in LDFLAGS
use of CFLAGS-$(CONFIG_INDIRECT_THUNK) instead of ifeq().

There is on FIXME added about LTO build, but since LTO is marked as
BROKEN, this commit doesn't attempt to filter -flto flags out of the
CFLAGS.

Signed-off-by: Anthony PERARD 
---

Notes:
v3:
- squash "xen/build: introduce ccflags-y and CFLAGS_$@" here, with
  those changes:
- rename ccflags-y to simply CFLAGS-y and start using AFLAGS-y in
  subdirs.
- remove CFLAGS_$@, we don't need it yet.
- fix build of xen.lds and efi.lds which needed -D to be a_flags
- remove arch_ccflags, and modify c_flags directly
  with that change, reorder c_flags, so that target specific flags are last.
- remove HAVE_AS_QUOTED_SYM from envvar and check XEN_CFLAGS to find if
  it's there when adding -D__OBJECT_LABEL__.
- fix missing some flags in AFLAGS
  (like -fshort-wchar in xen/arch/x86/efi/Makefile,
   and -D__OBJECT_LABEL__ and CFLAGS-stack-boundary)
- keep COV_FLAGS generation in Rules.mk since it doesn't invovle to
  call CC
- fix clang test for "asm()-s support .include." (in a new patch done
  ahead)
- include Kconfig.include in xen/Makefile because as-option-add is
  defined there now.

 xen/Makefile   | 60 
 xen/Rules.mk   | 74 --
 xen/arch/arm/Makefile  | 10 ++--
 xen/arch/arm/Rules.mk  | 93 --
 xen/arch/arm/arch.mk   | 88 
 xen/arch/arm/efi/Makefile  |  2 +-
 xen/arch/x86/Makefile  | 24 +-
 xen/arch/x86/Rules.mk  | 91 +++--
 xen/arch/x86/arch.mk   | 84 ++
 xen/arch/x86/efi/Makefile  |  2 +-
 xen/common/libelf/Makefile |  4 +-
 xen/common/libfdt/Makefile |  4 +-
 xen/include/Makefile   |  2 +-
 xen/xsm/flask/Makefile |  2 +-
 xen/xsm/flask/ss/Makefile  |  2 +-
 15 files changed, 283 insertions(+), 259 deletions(-)
 create mode 100644 xen/arch/arm/arch.mk
 create mode 100644 xen/arch/x86/arch.mk

diff --git a/xen/Makefile b/xen/Makefile
index a6120e577e9b..da017dc29d36 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -94,6 +94,8 @@ config: FORCE
 
 else # !config-build
 
+include scripts/Kbuild.include
+
 ifeq ($(need-config),y)
 include include/config/auto.conf
 # Read in dependencies to all Kconfig* files, make sure to run syncconfig if
@@ -113,6 +115,64 @@ $(KCONFIG_CONFIG):
 include/config/%.conf include/config/%.conf.cmd: $(KCONFIG_CONFIG)
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" syncconfig
 
+ifeq ($(CONFIG_DEBUG),y)
+CFLAGS += -O1
+else
+CFLAGS += -O2
+endif
+
+ifeq ($(CONFIG_FRAME_POINTER),y)
+CFLAGS += -fno-omit-frame-pointer
+else
+CFLAGS += -fomit-frame-pointer
+endif
+
+CFLAGS += -nostdinc -fno-builtin -fno-common
+CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
+$(call cc-option-add,CFLAGS,CC,-Wvla)
+CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
+CFLAGS-$(CONFIG_DEBUG_INFO) += -g
+
+ifneq ($(CONFIG_CC_IS_CLANG),y)
+# Clang doesn't understand this command line argument, and doesn't appear to
+# have an suitable alternative.  The resulting compiled binary does function,
+# but has an excessively large symbol table.
+CFLAGS += -Wa,--strip-local-absolute
+endif
+
+AFLAGS += -D__ASSEMBLY__
+
+CFLAGS += $(CFLAGS-y)
+# allow extra CFLAGS externally via EXTRA_CFLAGS_XEN_CORE
+CFLAGS += $(EXTRA_CFLAGS_XEN_CORE)
+
+# Most CFLAGS are safe for assembly files:
+#  -std=gnu{89,99} gets confused by #-prefixed end-of-line comments
+#  -flto makes no sense and annoys clang

[Xen-devel] [XEN PATCH v3 16/23] xen/build: introduce if_changed and if_changed_rule

[Anthony PERARD]

The if_changed macro from Linux can record the command used to build a
target then compare it on rebuild. Thus if a command has changed, for
example due to introducing new flags in CFLAGS or due to using a
different compiler, the target will be rebuilt.

if_changed_rule checks dependencies like if_changed, but execute
rule_$(1) instead of cmd_$(1) when the command is different. A rule_
macro can call more than one cmd_ macro. One of the cmd_ macro in a
rule need to be call using a macro that record the command line, so
cmd_and_record is introduced. It is similar to cmd_and_fixup from
Linux but without a call to fixdep which we don't have yet. (We will
later replace cmd_and_record by cmd_and_fixup.)

Example of a rule_ macro:
define rule_cc_o_c
$(call cmd_and_record,cc_o_o)
$(call cmd,objcopy)
endef

This needs one of the call to use cmd_and_record, otherwise no .*.cmd
file will be created, and the target will keep been rebuilt.

In order for if_changed to works correctly, we need to load the .%.cmd
files that the macro generates, this is done by adding targets in to
the $(targets) variable. We use intermediate_targets to add %.init.o
dependency %.o to target since there aren't in obj-y.

We also add $(MAKECMDGOALS) to targets so that when running for
example `make common/memory.i`, make will load the associated .%.cmd
dependency file.

Beside the if_changed*, we import the machinery used for a "beautify
output". The important one is when running make with V=2 which help to
debug the makefiles by printing why a target is been rebuilt, via the
$(echo-why) macro.

if_changed and if_changed_rule aren't used yet.

Most of this code is copied from Linux v5.4.

Signed-off-by: Anthony PERARD 
---
 .gitignore |   1 +
 xen/Makefile   |  53 +-
 xen/Rules.mk   |  33 +++-
 xen/scripts/Kbuild.include | 107 +
 4 files changed, 192 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 4ca679ddbc9a..c73f9f480780 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,6 +6,7 @@
 *.o
 *.d
 *.d2
+.*.cmd
 *.opic
 *.a
 *.so
diff --git a/xen/Makefile b/xen/Makefile
index da017dc29d36..fbd087e6f360 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -52,7 +52,57 @@ dist: install
 
 ifeq ($(root-make-done),)
 # section to run before calling Rules.mk, but only once.
+
+# Beautify output
+# ---
+#
+# Normally, we echo the whole command before executing it. By making
+# that echo $($(quiet)$(cmd)), we now have the possibility to set
+# $(quiet) to choose other forms of output instead, e.g.
+#
+# quiet_cmd_cc_o_c = Compiling $(RELDIR)/$@
+# cmd_cc_o_c   = $(CC) $(c_flags) -c -o $@ $<
+#
+# If $(quiet) is empty, the whole command will be printed.
+# If it is set to "quiet_", only the short version will be printed.
+# If it is set to "silent_", nothing will be printed at all, since
+# the variable $(silent_cmd_cc_o_c) doesn't exist.
+#
+# A simple variant is to prefix commands with $(Q) - that's useful
+# for commands that shall be hidden in non-verbose mode.
 #
+#  $(Q)ln $@ :<
+#
+# If KBUILD_VERBOSE equals 0 then the above command will be hidden.
+# If KBUILD_VERBOSE equals 1 then the above command is displayed.
+#
+# To put more focus on warnings, be less verbose as default
+# Use 'make V=1' to see the full commands
+
+ifeq ("$(origin V)", "command line")
+  KBUILD_VERBOSE = $(V)
+endif
+ifndef KBUILD_VERBOSE
+  KBUILD_VERBOSE = 0
+endif
+
+ifeq ($(KBUILD_VERBOSE),1)
+  quiet =
+  Q =
+else
+  quiet=quiet_
+  Q = @
+endif
+
+# If the user is running make -s (silent mode), suppress echoing of
+# commands
+
+ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),)
+  quiet=silent_
+endif
+
+export quiet Q KBUILD_VERBOSE
+
 # To make sure we do not include .config for any of the *config targets
 # catch them early, and hand them over to tools/kconfig/Makefile
 
@@ -258,7 +308,8 @@ _clean: delete-unfresh-files
$(MAKE) $(clean) arch/x86
$(MAKE) $(clean) test
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) clean
-   find . \( -name "*.o" -o -name ".*.d" -o -name ".*.d2" -o -name 
"*.gcno" \) -exec rm -f {} \;
+   find . \( -name "*.o" -o -name ".*.d" -o -name ".*.d2" \
+   -o -name "*.gcno" -o -name ".*.cmd" \) -exec rm -f {} \;
rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi 
$(TARGET).efi.map $(TARGET)-syms $(TARGET)-syms.map *~ core
rm -f include/asm-*/asm-offsets.h
rm -f .banner
diff --git a/xen/Rules.mk b/xen/Rules.mk
index f1311c45a372..8807a2e21c94 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -38,6 +38,7 @@ ALL_OBJS-y   += 
$(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(CONFIG_CRYPTO)   += $(BASEDIR)/crypto/built_in.o
 
 # Initialise some variables
+targets :=
 CFLAGS-y :=
 AFLAGS-y :=
 
@@ -6

[Xen-devel] [XEN PATCH v3 17/23] xen/build: Start using if_changed

[Anthony PERARD]

This patch start to use if_changed introduced in a previous commit.

Whenever if_changed is called, the target must have FORCE as
dependency so that if_changed can check if the command line to be
run as changed, so the macro $(real-prereqs) must be use to
discover the dependencies without "FORCE".

Whenever a target isn't in obj-y, it should be added to extra-y so the
.*.cmd dependency file associated with the target can be loaded. This
is done for xsm/flask/ and both common/lib{elf,fdt}/ and
arch/x86/Makefile.

For the targets that generates .*.d dependency files, there's going to
be two dependency files (.*.d and .*.cmd) until we can merge them
together in a later patch via fixdep from Linux.

One cleanup, libelf-relocate.o doesn't exist anymore.

We import cmd_ld and cmd_objcopy from Linux v5.4.

Signed-off-by: Anthony PERARD 
---
 xen/Rules.mk   | 68 +++---
 xen/arch/arm/Makefile  |  4 +--
 xen/arch/x86/Makefile  |  1 +
 xen/arch/x86/efi/Makefile  |  7 ++--
 xen/common/libelf/Makefile | 12 ---
 xen/common/libfdt/Makefile |  9 +++--
 xen/xsm/flask/Makefile | 17 +++---
 7 files changed, 84 insertions(+), 34 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 8807a2e21c94..bb4ced5f0dd4 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -52,6 +52,18 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
 
 include Makefile
 
+# Linking
+# ---
+
+quiet_cmd_ld = LD  $@
+cmd_ld = $(LD) $(XEN_LDFLAGS) -r -o $@ $(real-prereqs)
+
+# Objcopy
+# ---
+
+quiet_cmd_objcopy = OBJCOPY $@
+cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $< $@
+
 define gendep
 ifneq ($(1),$(subst /,:,$(1)))
 DEPS += $(dir $(1)).$(notdir $(1)).d
@@ -161,29 +173,47 @@ else
$(CC) $(c_flags) -c $< -o $@
 endif
 
-%.o: %.S Makefile
-   $(CC) $(a_flags) -c $< -o $@
+quiet_cmd_cc_o_S = CC  $@
+cmd_cc_o_S = $(CC) $(a_flags) -c $< -o $@
+
+%.o: %.S FORCE
+   $(call if_changed,cc_o_S)
+
+
+quiet_cmd_obj_init_o = INIT_O  $@
+define cmd_obj_init_o
+$(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' | while read idx name sz 
rest; do \
+case "$$name" in \
+.*.local) ;; \
+.text|.text.*|.data|.data.*|.bss) \
+test $$sz != 0 || continue; \
+echo "Error: size of $<:$$name is 0x$$sz" >&2; \
+exit $$(expr $$idx + 1);; \
+esac; \
+done; \
+$(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section 
.$(s)=.init.$(s)) $< $@
+endef
+
+$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o FORCE
+   $(call if_changed,obj_init_o)
+
+quiet_cmd_cpp_i_c = CPP $@
+cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@
+
+quiet_cmd_cc_s_c = CC  $@
+cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
 
-$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): %.init.o: %.o Makefile
-   $(OBJDUMP) -h $< | sed -n '/[0-9]/{s,00*,0,g;p;}' | while read idx name 
sz rest; do \
-   case "$$name" in \
-   .*.local) ;; \
-   .text|.text.*|.data|.data.*|.bss) \
-   test $$sz != 0 || continue; \
-   echo "Error: size of $<:$$name is 0x$$sz" >&2; \
-   exit $$(expr $$idx + 1);; \
-   esac; \
-   done
-   $(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section 
.$(s)=.init.$(s)) $< $@
+quiet_cmd_s_S = CPP $@
+cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
 
-%.i: %.c Makefile
-   $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@
+%.i: %.c FORCE
+   $(call if_changed,cpp_i_c)
 
-%.s: %.c Makefile
-   $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
+%.s: %.c FORCE
+   $(call if_changed,cc_s_c)
 
-%.s: %.S Makefile
-   $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
+%.s: %.S FORCE
+   $(call if_changed,cpp_s_S)
 
 # Add intermediate targets:
 # When building objects with specific suffix patterns, add intermediate
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 1599e2ba4058..37ca6d25c08e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -98,8 +98,8 @@ prelink_lto.o: $(ALL_OBJS)
 prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
$(LD) $(XEN_LDFLAGS) -r -o $@ $^
 else
-prelink.o: $(ALL_OBJS)
-   $(LD) $(XEN_LDFLAGS) -r -o $@ $^
+prelink.o: $(ALL_OBJS) FORCE
+   $(call if_changed,ld)
 endif
 
 $(TARGET)-syms: prelink.o xen.lds
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 5de873cf693e..6fb6cafdf47b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_TBOOT) += tboot.o
 obj-y += hpet.o
 obj-y += vm_event.o
 obj-y += xstate.o
+extra-y += asm-macros.i
 
 x86_emulate.o: x86_emulate/x86_em

[Xen-devel] [XEN PATCH v3 13/23] xen/build: include include/config/auto.conf in main Makefile

[Anthony PERARD]

We are going to generate the CFLAGS early from "xen/Makefile" instead
of in "Rules.mk", but we need to include "config/auto.conf", so
include it in "Makefile".

Before including "config/auto.conf" we check which make target a user
is calling, as some targets don't need "auto.conf". For targets that
needs auto.conf, make will generate it (and a default .config if
missing).

root-make-done is to avoid doing the calculation again once Rules.mk
takes over and is been executed with the root Makefile. When Rules.mk
is including xen/Makefile, `config-build' and `need-config' are
undefined so auto.conf will not be included again (it is already
included by Rules.mk) and kconfig target are out of reach of Rules.mk.

We are introducing a target %config to catch all targets for kconfig.
So we need an extra target %/.config to prevent make from trying to
regenerate $(XEN_ROOT)/.config that is included in Config.mk.

The way targets are filtered is inspired by Kbuild, with some code
imported from Linux. That's why there is PHONY variable that isn't
used yet, for example.

Signed-off-by: Anthony PERARD 
---

Notes:
v3:
- filter only for %config instead of both config %config
- keep the multi-target pattern rule trick for include/config/auto.conf
  instead of using Linux's newer pattern (we dont have tristate.conf so
  don't need to change it)
- use y/n for root-make-done, config-build, need-config instead of
  relying on ifdef and ifndef and on assigning an empty value meaning
  undef
- use space for indentation
- explain why %/.config is suddenly needed.

 xen/Makefile | 96 +++-
 1 file changed, 73 insertions(+), 23 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index 8267ace51b0d..a6120e577e9b 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -49,7 +49,71 @@ default: build
 .PHONY: dist
 dist: install
 
-build install:: include/config/auto.conf
+
+ifeq ($(root-make-done),)
+# section to run before calling Rules.mk, but only once.
+#
+# To make sure we do not include .config for any of the *config targets
+# catch them early, and hand them over to tools/kconfig/Makefile
+
+clean-targets := %clean
+no-dot-config-targets := $(clean-targets) \
+ uninstall debug cloc \
+ cscope TAGS tags MAP gtags \
+ xenversion
+
+config-build:= n
+need-config := y
+
+ifneq ($(filter $(no-dot-config-targets), $(MAKECMDGOALS)),)
+ifeq ($(filter-out $(no-dot-config-targets), $(MAKECMDGOALS)),)
+need-config := n
+endif
+endif
+
+ifneq ($(filter %config,$(MAKECMDGOALS)),)
+config-build := y
+endif
+
+export root-make-done := y
+endif # root-make-done
+
+ifeq ($(config-build),y)
+# ===
+# *config targets only - make sure prerequisites are updated, and descend
+# in tools/kconfig to make the *config target
+
+config: FORCE
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
+
+# Config.mk tries to include .config file, don't try to remake it
+%/.config: ;
+
+%config: FORCE
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
+
+else # !config-build
+
+ifeq ($(need-config),y)
+include include/config/auto.conf
+# Read in dependencies to all Kconfig* files, make sure to run syncconfig if
+# changes are detected.
+include include/config/auto.conf.cmd
+
+# Allow people to just run `make` as before and not force them to configure
+$(KCONFIG_CONFIG):
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" defconfig
+
+# The actual configuration files used during the build are stored in
+# include/generated/ and include/config/. Update them if .config is newer than
+# include/config/auto.conf (which mirrors .config).
+#
+# This exploits the 'multi-target pattern rule' trick.
+# The syncconfig should be executed only once to make all the targets.
+include/config/%.conf include/config/%.conf.cmd: $(KCONFIG_CONFIG)
+   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" syncconfig
+
+endif # need-config
 
 .PHONY: build install uninstall clean distclean MAP
 build install uninstall debug clean distclean MAP::
@@ -254,9 +318,6 @@ cscope:
 _MAP:
$(NM) -n $(TARGET)-syms | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] 
\)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' > System.map
 
-.PHONY: FORCE
-FORCE:
-
 %.o %.i %.s: %.c FORCE
$(MAKE) -f $(BASEDIR)/Rules.mk -C $(*D) $(@F)
 
@@ -277,25 +338,6 @@ $(foreach base,arch/x86/mm/guest_walk_% \
arch/x86/mm/shadow/guest_%, \
 $(foreach ext,o i s,$(call build-intermediate,$(base).$(ext
 
-kconfig := oldconfig config 

[Xen-devel] [XEN PATCH v3 23/23] xen/build: use if_changed to build guest_%.o

[Anthony PERARD]

Use if_changed for building all guest_%.o objects, and make use of
command that already exist.

This patch also introduces CFLAGS_$@, it is used so that flags are
applied to all .o .i and .s targets.

This patch make a change to the way guest_%.o files are built, and now
run the same commands that enforce unique symbols. But with patch
"xen,symbols: rework file symbols selection", symbols should still
select the file symbols directive intended to be used for guest_%.o
objects.

Signed-off-by: Anthony PERARD 
---
 xen/Rules.mk|  5 -
 xen/arch/x86/mm/Makefile| 15 +--
 xen/arch/x86/mm/hap/Makefile| 15 +--
 xen/arch/x86/mm/shadow/Makefile | 15 +--
 4 files changed, 31 insertions(+), 19 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 02cd37d04054..1ffb02f42914 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -115,6 +115,9 @@ endif
 # FIXME LTO broken, but we would need a different way to filter -flto out
 # $(obj-bin-y): CFLAGS := $(filter-out -flto,$(CFLAGS))
 
+# target with its suffix stripped
+target-stem = $(basename $@)
+
 # Calculation of flags, first the generic flags, then the arch specific flags,
 # and last the flags modified for a target or a directory.
 
@@ -123,7 +126,7 @@ a_flags = -MMD -MF $(@D)/.$(@F).d $(XEN_AFLAGS)
 
 include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk
 
-c_flags += $(CFLAGS-y)
+c_flags += $(CFLAGS-y) $(CFLAGS_$(target-stem).o)
 a_flags += $(CFLAGS-y) $(AFLAGS-y)
 
 quiet_cmd_ld_builtin = LD  $@
diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
index a2431fde6bb4..4750bfa0ff91 100644
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -11,11 +11,14 @@ obj-y += p2m.o p2m-pt.o
 obj-$(CONFIG_HVM) += p2m-ept.o p2m-pod.o
 obj-y += paging.o
 
-guest_walk_%.o: guest_walk.c Makefile
-   $(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+$(foreach gw,$(filter guest_walk_%.o,$(obj-y)),\
+$(eval CFLAGS_$(gw) = -DGUEST_PAGING_LEVELS=$$*))
 
-guest_walk_%.i: guest_walk.c Makefile
-   $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* 
-c $< -o $@
+guest_walk_%.o: guest_walk.c FORCE
+   $(call if_changed_rule,cc_o_c)
 
-guest_walk_%.s: guest_walk.c Makefile
-   $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S 
$< -o $@
+guest_walk_%.i: guest_walk.c FORCE
+   $(call if_changed,cpp_i_c)
+
+guest_walk_%.s: guest_walk.c FORCE
+   $(call if_changed,cc_s_c)
diff --git a/xen/arch/x86/mm/hap/Makefile b/xen/arch/x86/mm/hap/Makefile
index 22e7ad54bd33..8cd31e9cdc5e 100644
--- a/xen/arch/x86/mm/hap/Makefile
+++ b/xen/arch/x86/mm/hap/Makefile
@@ -5,11 +5,14 @@ obj-y += guest_walk_4level.o
 obj-y += nested_hap.o
 obj-y += nested_ept.o
 
-guest_walk_%level.o: guest_walk.c Makefile
-   $(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+$(foreach gw,$(filter guest_walk_%level.o,$(obj-y)),\
+$(eval CFLAGS_$(gw) = -DGUEST_PAGING_LEVELS=$$*))
 
-guest_walk_%level.i: guest_walk.c Makefile
-   $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* 
-c $< -o $@
+guest_walk_%level.o: guest_walk.c FORCE
+   $(call if_changed_rule,cc_o_c)
 
-guest_walk_%level.s: guest_walk.c Makefile
-   $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S 
$< -o $@
+guest_walk_%level.i: guest_walk.c FORCE
+   $(call if_changed,cpp_i_c)
+
+guest_walk_%level.s: guest_walk.c FORCE
+   $(call if_changed,cc_s_c)
diff --git a/xen/arch/x86/mm/shadow/Makefile b/xen/arch/x86/mm/shadow/Makefile
index 23d3ff10802c..d11e9e2fac08 100644
--- a/xen/arch/x86/mm/shadow/Makefile
+++ b/xen/arch/x86/mm/shadow/Makefile
@@ -6,11 +6,14 @@ else
 obj-y += none.o
 endif
 
-guest_%.o: multi.c Makefile
-   $(CC) $(c_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
+$(foreach gw,$(filter guest_%.o,$(obj-y)),\
+$(eval CFLAGS_$(gw) = -DGUEST_PAGING_LEVELS=$$*))
 
-guest_%.i: multi.c Makefile
-   $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* 
-c $< -o $@
+guest_%.o: multi.c FORCE
+   $(call if_changed_rule,cc_o_c)
 
-guest_%.s: multi.c Makefile
-   $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -DGUEST_PAGING_LEVELS=$* -S 
$< -o $@
+guest_%.i: multi.c FORCE
+   $(call if_changed,cpp_i_c)
+
+guest_%.s: multi.c FORCE
+   $(call if_changed,cc_s_c)
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [XEN PATCH v3 21/23] xen/build: Use if_changed for prelink*.o

[Anthony PERARD]

We change the dependencies of prelink-efi.o so that we can use the
same command line. The dependency on efi/built_in.o isn't needed
because, we already have:
efi/*.o: efi/built_in.o
to build efi/*.o files that prelink-efi.o needs.

Signed-off-by: Anthony PERARD 
---
 xen/arch/x86/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 1be94846e11f..55c6ae8ce0d2 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -131,11 +131,11 @@ prelink.o: $(patsubst 
%/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
 prelink-efi.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) 
prelink-efi_lto.o efi/boot.init.o
$(LD) $(XEN_LDFLAGS) -r -o $@ $^
 else
-prelink.o: $(ALL_OBJS)
-   $(LD) $(XEN_LDFLAGS) -r -o $@ $^
+prelink.o: $(ALL_OBJS) FORCE
+   $(call if_changed,ld)
 
-prelink-efi.o: $(ALL_OBJS) efi/boot.init.o efi/runtime.o efi/compat.o
-   $(LD) $(XEN_LDFLAGS) -r -o $@ $(filter-out %/efi/built_in.o,$^)
+prelink-efi.o: $(filter-out %/efi/built_in.o,$(ALL_OBJS)) efi/boot.init.o 
efi/runtime.o efi/compat.o FORCE
+   $(call if_changed,ld)
 endif
 
 $(TARGET)-syms: prelink.o xen.lds
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[Jan Beulich]

On 26.02.2020 12:33, Julien Grall wrote:
> On 25/02/2020 09:53, Paul Durrant wrote:
>> --- a/xen/common/time.c
>> +++ b/xen/common/time.c
>> @@ -99,6 +99,9 @@ void update_domain_wallclock_time(struct domain *d)
>>   uint32_t *wc_version;
>>   uint64_t sec;
>>   
>> +if ( d->is_dying )
>> +return;
> 
> This is another instance where I think the use of d->is_dying is not 
> safe. I looked at how other places in Xen dealt with d->is_dying.
> 
> We don't seem to have a common way to deal with it:
> 1) It may be checked under domain_lock() -> No issue with that
> 2) It may be checked under d->page_alloc_lock (e.g assign_pages()). 
> The assign_pages() case is fine because it will act as a full barrier. 
> So if we call happen after relinquish_memory() then we will surely have 
> observed d->is_dying. I haven't checked the others.
> 
> Some of the instances user neither the 2 locks above. We probably ought 
> to investigate them (I will add a TODO in my list).
> 
> Regarding the two cases here, domain_lock() might be the solution. If we 
> are concern about the contention (it is a spinlock), then we could 
> switch the domain_lock() from spinlock to rwlock.

That's an option, yes, but even better would be to avoid spreading
use of this lock (we did try to remove as many of the uses as
possible several years ago). For d->is_dying I think it is a case-
by-case justification of why a use is safe (the main point, after
all being that whatever code comes after the check must work
correctly if on some other CPU the flag is about to be / being set.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[Andrew Cooper]

On 25/02/2020 09:53, Paul Durrant wrote:
> There's no particular reason shared_info need use a xenheap page.

?

There are a number of ABI-critical reasons, not least the evtchn_pending
field which Xen needs to write.

I can see what you're trying to do, and it looks fine in principle, but
the commit message isn't remotely accurate.  Remember that you are in
the process of changing the meaning/usage of the xenheap - preexiting
uses conform to the old meaning, where the sole distinction between
domheap and xenheap pages was whether Xen required a virtual mapping or
not.  The answer is "absolutely yes" for the shared info page.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [XEN PATCH v3 03/23] xen/build: Remove confusing comment on the %.s:%.S rule

[Wei Liu]

On Wed, Feb 26, 2020 at 11:33:35AM +, Anthony PERARD wrote:
> That comment was introduce by 3943db776371 ("[XEN] Can be built
> -std=gnu99 (except for .S files).") to explain why CFLAGS was removed
> from the command line. The comment is already written where the
> -std=gnu flags gets remove from AFLAGS, no need to repeat it.
> 
> Signed-off-by: Anthony PERARD 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/mm: switch to new APIs in arch_init_memory

[Jan Beulich]

On 21.02.2020 11:42, Hongyan Xia wrote:
> From: Wei Liu 
> 
> Since we now map and unmap Xen PTE pages, we would like to track the
> lifetime of mappings so that 1) we do not dereference memory through a
> variable after it is unmapped, 2) we do not unmap more than once.
> Therefore, we introduce the UNMAP_DOMAIN_PAGE macro to nullify the
> variable after unmapping, and ignore NULL in unmap_domain_page.

To me this reads as if it was a 2nd paragraph explaining what needs
doing in order to achieve the main goal of the patch (supposedly
described in a 1st paragraph).

> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -181,7 +181,7 @@ void unmap_domain_page(const void *ptr)
>  unsigned long va = (unsigned long)ptr, mfn, flags;
>  struct vcpu_maphash_entry *hashent;
>  
> -if ( va >= DIRECTMAP_VIRT_START )
> +if ( !va || va >= DIRECTMAP_VIRT_START )
>  return;

If we are to go with this, then I agree with Julien that this needs
mirroring to Arm, allowing common code to assume this behavior.
However, an alternative to this is to make ...

> --- a/xen/include/xen/domain_page.h
> +++ b/xen/include/xen/domain_page.h
> @@ -72,4 +72,9 @@ static inline void unmap_domain_page_global(const void *va) 
> {};
>  
>  #endif /* !CONFIG_DOMAIN_PAGE */
>  
> +#define UNMAP_DOMAIN_PAGE(p) do {   \
> +unmap_domain_page(p);   \
> +(p) = NULL; \
> +} while ( false )

... this avoid the call, leaving the function itself untouched.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2.1 15/17] tools/libx[cl]: Plumb 'missing' through static_data_done() up into libxl

[Ian Jackson]

Andrew Cooper writes ("[PATCH v2.1 15/17] tools/libx[cl]: Plumb 'missing' 
through static_data_done() up into libxl"):
> Pre Xen-4.14 streams will not contain any CPUID/MSR information.  There is
> nothing libxc can do about this, and will have to rely on the higher level
> toolstack to provide backwards compatibility.
> 
> To facilitate this, extend the static_data_done() callback, highlighting the
> missing information, and modify libxl to use it.  At the libxc level, this
> requires an arch-specific hook which, for now, always reports CPUID and MSR as
> missing.  This will be adjusted in a later change.
> 
> No overall functional change - this is just plumbing.

Thanks for the additional explanation and the explanation on IRC.
I'm now convinced that this is the best way to do it.

Acked-by: Ian Jackson 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[Durrant, Paul]

> -Original Message-
> From: Andrew Cooper 
> Sent: 26 February 2020 11:46
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Volodymyr Babchuk ; George
> Dunlap ; Ian Jackson
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Wei Liu 
> Subject: Re: [PATCH 2/2] domain: use PGC_extra domheap page for
> shared_info
> 
> On 25/02/2020 09:53, Paul Durrant wrote:
> > There's no particular reason shared_info need use a xenheap page.
> 

Ok, 'particular' is too vague, agreed. I'll elaborate.

> ?
> 
> There are a number of ABI-critical reasons, not least the evtchn_pending
> field which Xen needs to write.
> 

I do address this specifically in the commit comment.

"ASSERTions are added before apparently vulnerable dereferences in the
event channel code. These should not be hit because domain_kill() calls
evtchn_destroy() before calling domain_relinquish_resources() but are
added to catch any future re-ordering."

> I can see what you're trying to do, and it looks fine in principle, but
> the commit message isn't remotely accurate.  Remember that you are in
> the process of changing the meaning/usage of the xenheap - preexiting
> uses conform to the old meaning, where the sole distinction between
> domheap and xenheap pages was whether Xen required a virtual mapping or
> not.  The answer is "absolutely yes" for the shared info page.
> 

Was that the case? I haven't mined to find when map_domain_page() was 
introduced. At that point, of course, any strict 'being virtually mapped' 
distinction between xenheap and domheap was rendered inaccurate.

  Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[Durrant, Paul]

> -Original Message-
> From: Julien Grall 
> Sent: 26 February 2020 11:33
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Volodymyr Babchuk
> ; Andrew Cooper ;
> George Dunlap ; Ian Jackson
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Wei Liu 
> Subject: Re: [PATCH 2/2] domain: use PGC_extra domheap page for
> shared_info
> 
> Hi Paul,
> 
> On 25/02/2020 09:53, Paul Durrant wrote:
> > There's no particular reason shared_info need use a xenheap page.
> 
> AFAICT, a side-effect of this change is the shared_info is now going to
> be part of the migration stream. One issue with this is on the restore
> side, they will be accounted in number of pages allocated to the domain.
> 
> I am fairly certain dirty logging on page with PGC_extra set would not
> work properly as well.

True, those two do need fixing before expanding the use of PGC_extra. I guess 
this may already be a problem with the current VMX use case.

> 
> As the pages will be recreated in the restore side, I would suggest to
> skip them in XEN_DOMCTL_getpageframeinfo3.
>

At some point in future I guess it may be useful to migrate PGC_extra pages, 
but they would need to be marked as such in the stream. Skipping sounds like 
the right approach for now.

> > It's
> > only purpose is to be mapped by the guest so use a PGC_extra domheap
> page
> > instead. This does entail freeing shared_info during
> > domain_relinquish_resources() rather than domain_destroy() so care is
> > needed to avoid de-referencing a NULL shared_info pointer hence some
> > extra checks of 'is_dying' are needed.
> > ASSERTions are added before apparently vulnerable dereferences in the
> > event channel code. These should not be hit because domain_kill() calls
> > evtchn_destroy() before calling domain_relinquish_resources() but are
> > added to catch any future re-ordering.
> 
> IHMO, the ASSERTions in the event channel pending/mask/... helpers will
> not protect against re-ordering. You may never hit them even if there is
> a re-ordering. It would be better to add an ASSERT()/BUG_ON() in
> evtchn_destroy() and possibly a comment in domain_kill() to mention
> ordering.

I'm not sure about that. Why would they not be hit?

> 
> > For Arm, the call to free_shared_info() in arch_domain_destroy() is left
> > in place since it called in the error path for arch_domain_create().
> >
> > NOTE: A modification in p2m_alloc_table() is required to avoid a false
> >positive when checking for domain memory.
> >A fix is also needed in dom0_construct_pv() to avoid
> automatically
> >adding PGC_extra pages to the physmap.
> 
> I am not entirely sure how this is related to this patch. Was it a
> latent bug? If so, I think it would make sense to split it from this
> patch.
> 

It's related because the check relies on the fact that no PGC_extra pages are 
created before it is called. This is indeed true until this patch is applied.

> >
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Stefano Stabellini 
> > Cc: Julien Grall 
> > Cc: Volodymyr Babchuk 
> > Cc: Andrew Cooper 
> > Cc: George Dunlap 
> > Cc: Ian Jackson 
> > Cc: Jan Beulich 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Wei Liu 
> > ---
> >   xen/arch/arm/domain.c|  2 ++
> >   xen/arch/x86/domain.c|  3 ++-
> >   xen/arch/x86/mm/p2m.c|  3 +--
> >   xen/arch/x86/pv/dom0_build.c |  4 
> >   xen/common/domain.c  | 25 +++--
> >   xen/common/event_2l.c|  4 
> >   xen/common/event_fifo.c  |  1 +
> >   xen/common/time.c|  3 +++
> >   8 files changed, 36 insertions(+), 9 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index 2cbcdaac08..3904519256 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -1006,6 +1006,8 @@ int domain_relinquish_resources(struct domain *d)
> >   BUG();
> >   }
> >
> > +free_shared_info(d);
> > +
> >   return 0;
> >   }
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index eb7b0fc51c..3ad532eccf 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -691,7 +691,6 @@ void arch_domain_destroy(struct domain *d)
> >   pv_domain_destroy(d);
> >   free_perdomain_mappings(d);
> >
> > -free_shared_info(d);
> >   cleanup_domain_irq_mapping(d);
> >
> >   psr_domain_free(d);
> > @@ -2246,6 +2245,8 @@ int domain_relinquish_resources(struct domain *d)
> >   if ( is_hvm_domain(d) )
> >   hvm_domain_relinquish_resources(d);
> >
> > +free_shared_info(d);
> > +
> >   return 0;
> >   }
> >
> > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> > index c5f428d67c..787d97d85e 100644
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -695,8 +695,7 @@ int p2m_alloc_table(struct p2m_domain *p2m)
> >
> >   p2m_lock(p2m);
> >
> > -if ( p2m_is_hostp2m(p2m)
> > - && !page_list_empty(&d->page_l

[Xen-devel] [PATCH v4 1/4] x86: introduce a nmi_count tracking variable

[Roger Pau Monne]

This is modeled after the irq_count variable, and is used to account
for all the NMIs handled by the system.

This will allow to repurpose the nmi_count() helper so it can be used
in a similar manner as local_irq_count(): account for the NMIs
currently in service.

Signed-off-by: Roger Pau Monné 
---
Changes since v3:
 - Remove nmi_count macro and __nmi_count field in irq_cpustat_t.
---
 xen/arch/x86/nmi.c| 11 +--
 xen/arch/x86/traps.c  |  4 +++-
 xen/include/asm-x86/hardirq.h |  1 -
 xen/include/asm-x86/nmi.h |  2 ++
 xen/include/xen/irq_cpustat.h |  1 -
 5 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index a69b91a924..c3f92ed231 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -151,15 +151,14 @@ int nmi_active;
 
 static void __init wait_for_nmis(void *p)
 {
-unsigned int cpu = smp_processor_id();
-unsigned int start_count = nmi_count(cpu);
+unsigned int start_count = this_cpu(nmi_count);
 unsigned long ticks = 10 * 1000 * cpu_khz / nmi_hz;
 unsigned long s, e;
 
 s = rdtsc();
 do {
 cpu_relax();
-if ( nmi_count(cpu) >= start_count + 2 )
+if ( this_cpu(nmi_count) >= start_count + 2 )
 break;
 e = rdtsc();
 } while( e - s < ticks );
@@ -177,7 +176,7 @@ void __init check_nmi_watchdog(void)
 printk("Testing NMI watchdog on all CPUs:");
 
 for_each_online_cpu ( cpu )
-prev_nmi_count[cpu] = nmi_count(cpu);
+prev_nmi_count[cpu] = per_cpu(nmi_count, cpu);
 
 /*
  * Wait at most 10 ticks for 2 watchdog NMIs on each CPU.
@@ -188,7 +187,7 @@ void __init check_nmi_watchdog(void)
 
 for_each_online_cpu ( cpu )
 {
-if ( nmi_count(cpu) - prev_nmi_count[cpu] < 2 )
+if ( per_cpu(nmi_count, cpu) - prev_nmi_count[cpu] < 2 )
 {
 printk(" %d", cpu);
 ok = false;
@@ -593,7 +592,7 @@ static void do_nmi_stats(unsigned char key)
 
 printk("CPU\tNMI\n");
 for_each_online_cpu ( cpu )
-printk("%3u\t%3u\n", cpu, nmi_count(cpu));
+printk("%3u\t%3u\n", cpu, per_cpu(nmi_count, cpu));
 
 if ( !hardware_domain || !(v = domain_vcpu(hardware_domain, 0)) )
 return;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 56067f85d1..3dbc66bb64 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1683,13 +1683,15 @@ static int dummy_nmi_callback(const struct 
cpu_user_regs *regs, int cpu)
 
 static nmi_callback_t *nmi_callback = dummy_nmi_callback;
 
+DEFINE_PER_CPU(unsigned int, nmi_count);
+
 void do_nmi(const struct cpu_user_regs *regs)
 {
 unsigned int cpu = smp_processor_id();
 unsigned char reason = 0;
 bool handle_unknown = false;
 
-++nmi_count(cpu);
+this_cpu(nmi_count)++;
 
 if ( nmi_callback(regs, cpu) )
 return;
diff --git a/xen/include/asm-x86/hardirq.h b/xen/include/asm-x86/hardirq.h
index 34e1b49260..802f91cfdf 100644
--- a/xen/include/asm-x86/hardirq.h
+++ b/xen/include/asm-x86/hardirq.h
@@ -7,7 +7,6 @@
 typedef struct {
unsigned int __softirq_pending;
unsigned int __local_irq_count;
-   unsigned int __nmi_count;
bool_t __mwait_wakeup;
 } __cacheline_aligned irq_cpustat_t;
 
diff --git a/xen/include/asm-x86/nmi.h b/xen/include/asm-x86/nmi.h
index f9dfca6afb..a288f02a50 100644
--- a/xen/include/asm-x86/nmi.h
+++ b/xen/include/asm-x86/nmi.h
@@ -31,5 +31,7 @@ nmi_callback_t *set_nmi_callback(nmi_callback_t *callback);
  * Remove the handler previously set.
  */
 void unset_nmi_callback(void);
+
+DECLARE_PER_CPU(unsigned int, nmi_count);
  
 #endif /* ASM_NMI_H */
diff --git a/xen/include/xen/irq_cpustat.h b/xen/include/xen/irq_cpustat.h
index 73629f6ec8..b9629f25c2 100644
--- a/xen/include/xen/irq_cpustat.h
+++ b/xen/include/xen/irq_cpustat.h
@@ -24,7 +24,6 @@ extern irq_cpustat_t irq_stat[];
   /* arch independent irq_stat fields */
 #define softirq_pending(cpu)   __IRQ_STAT((cpu), __softirq_pending)
 #define local_irq_count(cpu)   __IRQ_STAT((cpu), __local_irq_count)
-#define nmi_count(cpu) __IRQ_STAT((cpu), __nmi_count)
 #define mwait_wakeup(cpu)  __IRQ_STAT((cpu), __mwait_wakeup)
 
 #endif /* __irq_cpustat_h */
-- 
2.25.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 3/4] x86: track when in #MC context

[Roger Pau Monne]

Add helpers to track when executing in #MC handler context. This is
modeled after the in_irq helpers.

Note that there are no users of in_mce_handler() introduced by the
change, further users will be added by followup changes.

Signed-off-by: Roger Pau Monné 
---
Changes since v3:
 - Rename to in_mce_handler.
 - Drop parentheses around cpu in macro.

Changes since v2:
 - Move definition of mc_count to x86 hardirq.h.
---
 xen/arch/x86/cpu/mcheck/mce.c | 2 ++
 xen/include/asm-x86/hardirq.h | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index d61e582af3..e5bd4f542c 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -93,7 +93,9 @@ void x86_mce_vector_register(x86_mce_vector_t hdlr)
 
 void do_machine_check(const struct cpu_user_regs *regs)
 {
+mce_enter();
 _machine_check_vector(regs);
+mce_exit();
 }
 
 /*
diff --git a/xen/include/asm-x86/hardirq.h b/xen/include/asm-x86/hardirq.h
index 069e48fce9..276e3419d7 100644
--- a/xen/include/asm-x86/hardirq.h
+++ b/xen/include/asm-x86/hardirq.h
@@ -8,6 +8,7 @@ typedef struct {
unsigned int __softirq_pending;
unsigned int __local_irq_count;
unsigned int nmi_count;
+   unsigned int mce_count;
bool_t __mwait_wakeup;
 } __cacheline_aligned irq_cpustat_t;
 
@@ -23,6 +24,11 @@ typedef struct {
 #define nmi_enter()(nmi_count(smp_processor_id())++)
 #define nmi_exit() (nmi_count(smp_processor_id())--)
 
+#define mce_count(cpu) __IRQ_STAT(cpu, mce_count)
+#define in_mce_handler()   (mce_count(smp_processor_id()) != 0)
+#define mce_enter()(mce_count(smp_processor_id())++)
+#define mce_exit() (mce_count(smp_processor_id())--)
+
 void ack_bad_irq(unsigned int irq);
 
 extern void apic_intr_init(void);
-- 
2.25.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 0/4] x86/smp: fix send_IPI_mask usage of scratch_cpumask

[Roger Pau Monne]

Hello,

Commit:

5500d265a2a8fa63d60c08beb549de8ec82ff7a5
x86/smp: use APIC ALLBUT destination shorthand when possible

Introduced a bogus usage of the scratch cpumask: it was used in a
function that could be called from interrupt context, and hence using
the scratch cpumask there is not safe. Patch #4 is a fix for that usage,
together with also preventing the usage of any per-CPU variables when
send_IPI_mask is called from #MC or NMI context. Previous patches are
preparatory changes.

Thanks, Roger.

Roger Pau Monne (4):
  x86: introduce a nmi_count tracking variable
  x86: track when in NMI context
  x86: track when in #MC context
  x86/smp: do not use scratch_cpumask when in interrupt or exception
context

 xen/arch/x86/cpu/mcheck/mce.c |  2 ++
 xen/arch/x86/nmi.c| 11 +--
 xen/arch/x86/smp.c| 12 
 xen/arch/x86/traps.c  | 10 +-
 xen/include/asm-x86/hardirq.h | 13 -
 xen/include/asm-x86/nmi.h |  2 ++
 xen/include/xen/irq_cpustat.h |  1 -
 7 files changed, 42 insertions(+), 9 deletions(-)

-- 
2.25.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context

[Roger Pau Monne]

Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
context because it can nest, and hence send_IPI_mask could be
overwriting another user scratch cpumask data when used in such
contexts.

Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while using it.

Fallback to not using the scratch cpumask (and hence not attemping to
optimize IPI sending by using a shorthand) when in IRQ or exception
context. Note that the scratch cpumask cannot be used when
non-maskable interrupts are being serviced (NMI or #MC) and hence
fallback to not using the shorthand in that case, like it was done
previously.

Fixes: 5500d265a2a8 ('x86/smp: use APIC ALLBUT destination shorthand when 
possible')
Reported-by: Sander Eikelenboom 
Signed-off-by: Roger Pau Monné 
---
Changes since v3:
 - Do not use a dedicated cpumask, and instead prevent usage when in
   IRQ context.

Changes since v2:
 - Fallback to the previous IPI sending mechanism in #MC or #NMI
   context.

Changes since v1:
 - Don't use the shorthand when in #MC or #NMI context.
---
 xen/arch/x86/smp.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 55d08c9d52..fa9bfe4d54 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -69,6 +69,18 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
 bool cpus_locked = false;
 cpumask_t *scratch = this_cpu(scratch_cpumask);
 
+if ( in_irq() || in_mce() || in_nmi() )
+{
+/*
+ * When in IRQ, NMI or #MC context fallback to the old (and simpler)
+ * IPI sending routine, and avoid doing any performance optimizations
+ * (like using a shorthand) in order to avoid using the scratch
+ * cpumask which cannot be used in interrupt context.
+ */
+alternative_vcall(genapic.send_IPI_mask, mask, vector);
+return;
+}
+
 /*
  * This can only be safely used when no CPU hotplug or unplug operations
  * are taking place, there are no offline CPUs (unless those have been
-- 
2.25.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 2/4] x86: track when in NMI context

[Roger Pau Monne]

Add helpers to track when running in NMI handler context. This is
modeled after the in_irq helpers.

The SDM states that no NMI can be delivered while handling a NMI
until the processor has executed an iret instruction. It's possible
however that another fault is received while handling the NMI (a #MC
for example), and thus the iret from that fault would allow further
NMIs to be injected while still processing the previous one, and
hence an integer is needed in order to keep track of in service NMIs.
The added macros only track when the execution context is in the NMI
handler, but that doesn't mean NMIs are blocked for the reasons listed
above.

Note that there are no users of in_nmi_handler() introduced by the
change, further users will be added by followup changes.

Signed-off-by: Roger Pau Monné 
---
Changes since v3:
 - Rename to in_nmi_context.
 - Drop parentheses around cpu in nmi_count.

Changes since v2:
 - Use an integer instead of a boolean to keep track of in service
   #NMIs.
 - Move nmi_count into x86 specific header.
 - Drop leading underscores from __nmi_count field.
---
 xen/arch/x86/traps.c  | 6 ++
 xen/include/asm-x86/hardirq.h | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 3dbc66bb64..f4f2c13ae9 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1692,9 +1692,13 @@ void do_nmi(const struct cpu_user_regs *regs)
 bool handle_unknown = false;
 
 this_cpu(nmi_count)++;
+nmi_enter();
 
 if ( nmi_callback(regs, cpu) )
+{
+nmi_exit();
 return;
+}
 
 /*
  * Accessing port 0x61 may trap to SMM which has been actually
@@ -1720,6 +1724,8 @@ void do_nmi(const struct cpu_user_regs *regs)
 if ( !(reason & 0xc0) && handle_unknown )
 unknown_nmi_error(regs, reason);
 }
+
+nmi_exit();
 }
 
 nmi_callback_t *set_nmi_callback(nmi_callback_t *callback)
diff --git a/xen/include/asm-x86/hardirq.h b/xen/include/asm-x86/hardirq.h
index 802f91cfdf..069e48fce9 100644
--- a/xen/include/asm-x86/hardirq.h
+++ b/xen/include/asm-x86/hardirq.h
@@ -7,6 +7,7 @@
 typedef struct {
unsigned int __softirq_pending;
unsigned int __local_irq_count;
+   unsigned int nmi_count;
bool_t __mwait_wakeup;
 } __cacheline_aligned irq_cpustat_t;
 
@@ -17,6 +18,11 @@ typedef struct {
 #define irq_enter()(local_irq_count(smp_processor_id())++)
 #define irq_exit() (local_irq_count(smp_processor_id())--)
 
+#define nmi_count(cpu) __IRQ_STAT(cpu, nmi_count)
+#define in_nmi_handler()   (nmi_count(smp_processor_id()) != 0)
+#define nmi_enter()(nmi_count(smp_processor_id())++)
+#define nmi_exit() (nmi_count(smp_processor_id())--)
+
 void ack_bad_irq(unsigned int irq);
 
 extern void apic_intr_init(void);
-- 
2.25.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context

[Roger Pau Monné]

On Wed, Feb 26, 2020 at 01:19:21PM +0100, Roger Pau Monne wrote:
> Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
> context because it can nest, and hence send_IPI_mask could be
> overwriting another user scratch cpumask data when used in such
> contexts.
> 
> Instead introduce a new cpumask to be used by send_IPI_mask, and
> disable interrupts while using it.
> 
> Fallback to not using the scratch cpumask (and hence not attemping to
> optimize IPI sending by using a shorthand) when in IRQ or exception
> context. Note that the scratch cpumask cannot be used when
> non-maskable interrupts are being serviced (NMI or #MC) and hence
> fallback to not using the shorthand in that case, like it was done
> previously.
> 
> Fixes: 5500d265a2a8 ('x86/smp: use APIC ALLBUT destination shorthand when 
> possible')
> Reported-by: Sander Eikelenboom 
> Signed-off-by: Roger Pau Monné 
> ---
> Changes since v3:
>  - Do not use a dedicated cpumask, and instead prevent usage when in
>IRQ context.
> 
> Changes since v2:
>  - Fallback to the previous IPI sending mechanism in #MC or #NMI
>context.
> 
> Changes since v1:
>  - Don't use the shorthand when in #MC or #NMI context.
> ---
>  xen/arch/x86/smp.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
> index 55d08c9d52..fa9bfe4d54 100644
> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -69,6 +69,18 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
>  bool cpus_locked = false;
>  cpumask_t *scratch = this_cpu(scratch_cpumask);
>  
> +if ( in_irq() || in_mce() || in_nmi() )

Sorry, sent and old version, will send 4.1 with this fixed.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v5 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context

[Roger Pau Monne]

Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
context because it can nest, and hence send_IPI_mask could be
overwriting another user scratch cpumask data when used in such
contexts.

Instead introduce a new cpumask to be used by send_IPI_mask, and
disable interrupts while using it.

Fallback to not using the scratch cpumask (and hence not attemping to
optimize IPI sending by using a shorthand) when in IRQ or exception
context. Note that the scratch cpumask cannot be used when
non-maskable interrupts are being serviced (NMI or #MC) and hence
fallback to not using the shorthand in that case, like it was done
previously.

Fixes: 5500d265a2a8 ('x86/smp: use APIC ALLBUT destination shorthand when 
possible')
Reported-by: Sander Eikelenboom 
Signed-off-by: Roger Pau Monné 
---
Changes since v4:
 - Add _handler suffix to in_nmi/in_mce calls.

Changes since v3:
 - Do not use a dedicated cpumask, and instead prevent usage when in
   IRQ context.

Changes since v2:
 - Fallback to the previous IPI sending mechanism in #MC or #NMI
   context.

Changes since v1:
 - Don't use the shorthand when in #MC or #NMI context.
---
 xen/arch/x86/smp.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 55d08c9d52..0461812cf6 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -69,6 +69,18 @@ void send_IPI_mask(const cpumask_t *mask, int vector)
 bool cpus_locked = false;
 cpumask_t *scratch = this_cpu(scratch_cpumask);
 
+if ( in_irq() || in_mce_handler() || in_nmi_handler() )
+{
+/*
+ * When in IRQ, NMI or #MC context fallback to the old (and simpler)
+ * IPI sending routine, and avoid doing any performance optimizations
+ * (like using a shorthand) in order to avoid using the scratch
+ * cpumask which cannot be used in interrupt context.
+ */
+alternative_vcall(genapic.send_IPI_mask, mask, vector);
+return;
+}
+
 /*
  * This can only be safely used when no CPU hotplug or unplug operations
  * are taking place, there are no offline CPUs (unless those have been
-- 
2.25.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v6 02/12] xen: add a generic way to include binary files as variables

[Juergen Gross]

Add a new script xen/tools/binfile for including a binary file at build
time being usable via a pointer and a size variable in the hypervisor.

Make use of that generic tool in xsm.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
Reviewed-by: Wei Liu 
---
V3:
- new patch

V4:
- add alignment parameter (Jan Beulich)
- use .Lend instead of . (Jan Beulich)
---
 .gitignore   |  1 +
 xen/tools/binfile| 41 +
 xen/xsm/flask/Makefile   |  5 -
 xen/xsm/flask/flask-policy.S | 16 
 4 files changed, 46 insertions(+), 17 deletions(-)
 create mode 100755 xen/tools/binfile
 delete mode 100644 xen/xsm/flask/flask-policy.S

diff --git a/.gitignore b/.gitignore
index 4ca679ddbc..b2624df79a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -313,6 +313,7 @@ xen/test/livepatch/*.livepatch
 xen/tools/kconfig/.tmp_gtkcheck
 xen/tools/kconfig/.tmp_qtcheck
 xen/tools/symbols
+xen/xsm/flask/flask-policy.S
 xen/xsm/flask/include/av_perm_to_string.h
 xen/xsm/flask/include/av_permissions.h
 xen/xsm/flask/include/class_to_string.h
diff --git a/xen/tools/binfile b/xen/tools/binfile
new file mode 100755
index 00..7bb35a5178
--- /dev/null
+++ b/xen/tools/binfile
@@ -0,0 +1,41 @@
+#!/bin/sh
+# usage: binfile [-i] [-a ]   
+# -a   align data at 2^ boundary (default: byte alignment)
+# -i  add to .init.rodata (default: .rodata) section
+
+section=""
+align=0
+
+OPTIND=1
+while getopts "ia:" opt; do
+case "$opt" in
+i)
+section=".init"
+;;
+a)
+align=$OPTARG
+;;
+esac
+done
+
+target=$1
+binsource=$2
+varname=$3
+
+cat <$target
+#include 
+
+.section $section.rodata, "a", %progbits
+
+.p2align $align
+.global $varname
+$varname:
+.incbin "$binsource"
+.Lend:
+
+.type $varname, %object
+.size $varname, .Lend - $varname
+
+.global ${varname}_size
+ASM_INT(${varname}_size, .Lend - $varname)
+EOF
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index 7c3f381287..a807521235 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -30,6 +30,9 @@ $(AV_H_FILES): $(AV_H_DEPEND)
 obj-bin-$(CONFIG_XSM_FLASK_POLICY) += flask-policy.o
 flask-policy.o: policy.bin
 
+flask-policy.S: $(XEN_ROOT)/xen/tools/binfile
+   $(XEN_ROOT)/xen/tools/binfile -i $@ policy.bin xsm_flask_init_policy
+
 FLASK_BUILD_DIR := $(CURDIR)
 POLICY_SRC := $(FLASK_BUILD_DIR)/xenpolicy-$(XEN_FULLVERSION)
 
@@ -39,4 +42,4 @@ policy.bin: FORCE
 
 .PHONY: clean
 clean::
-   rm -f $(ALL_H_FILES) *.o $(DEPS_RM) policy.* $(POLICY_SRC)
+   rm -f $(ALL_H_FILES) *.o $(DEPS_RM) policy.* $(POLICY_SRC) 
flask-policy.S
diff --git a/xen/xsm/flask/flask-policy.S b/xen/xsm/flask/flask-policy.S
deleted file mode 100644
index d38aa39964..00
--- a/xen/xsm/flask/flask-policy.S
+++ /dev/null
@@ -1,16 +0,0 @@
-#include 
-
-.section .init.rodata, "a", %progbits
-
-/* const unsigned char xsm_flask_init_policy[] __initconst */
-.global xsm_flask_init_policy
-xsm_flask_init_policy:
-.incbin "policy.bin"
-.Lend:
-
-.type xsm_flask_init_policy, %object
-.size xsm_flask_init_policy, . - xsm_flask_init_policy
-
-/* const unsigned int __initconst xsm_flask_init_policy_size */
-.global xsm_flask_init_policy_size
-ASM_INT(xsm_flask_init_policy_size, .Lend - xsm_flask_init_policy)
-- 
2.16.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v6 06/12] tools: add xenfs tool

[Juergen Gross]

Add the xenfs tool for accessing the hypervisor filesystem.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
---
V1:
- rename to xenhypfs
- don't use "--" for subcommands
- add write support

V2:
- escape non-printable characters per default with cat subcommand
  (Ian Jackson)
- add -b option to cat subcommand (Ian Jackson)
- add man page

V3:
- adapt to new hypfs interface
---
 .gitignore  |   1 +
 docs/man/xenhypfs.1.pod |  61 
 tools/misc/Makefile |   6 ++
 tools/misc/xenhypfs.c   | 189 
 4 files changed, 257 insertions(+)
 create mode 100644 docs/man/xenhypfs.1.pod
 create mode 100644 tools/misc/xenhypfs.c

diff --git a/.gitignore b/.gitignore
index e98c3f056d..fd5610718d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -367,6 +367,7 @@ tools/libxl/test_timedereg
 tools/libxl/test_fdderegrace
 tools/firmware/etherboot/eb-roms.h
 tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
+tools/misc/xenhypfs
 tools/misc/xenwatchdogd
 tools/misc/xen-hvmcrash
 tools/misc/xen-lowmemd
diff --git a/docs/man/xenhypfs.1.pod b/docs/man/xenhypfs.1.pod
new file mode 100644
index 00..37aa488fcc
--- /dev/null
+++ b/docs/man/xenhypfs.1.pod
@@ -0,0 +1,61 @@
+=head1 NAME
+
+xenhypfs - Xen tool to access Xen hypervisor file system
+
+=head1 SYNOPSIS
+
+B I [I] [I]
+
+=head1 DESCRIPTION
+
+The B program is used to access the Xen hypervisor file system.
+It can be used to show the available entries, to show their contents and
+(if allowed) to modify their contents.
+
+=head1 SUBCOMMANDS
+
+=over 4
+
+=item B I
+
+List the available entries below I.
+
+=item B [I<-b>] I
+
+Show the contents of the entry specified by I. Non-printable characters
+other than white space characters (like tab, new line) will be shown as
+B<\xnn> (B being a two digit hex number) unless the option B<-b> is
+specified.
+
+=item B I I
+
+Set the contents of the entry specified by I to I.
+
+=item B
+
+Show all the entries of the file system as a tree.
+
+=back
+
+=head1 RETURN CODES
+
+=over 4
+
+=item B<0>
+
+Success
+
+=item B<1>
+
+Invalid usage (e.g. unknown subcommand, unknown option, missing parameter).
+
+=item B<2>
+
+Entry not found while traversing the tree.
+
+=item B<3>
+
+Access right violation.
+
+=back
+
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 63947bfadc..9fdb13597f 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -24,6 +24,7 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
 INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
 INSTALL_SBIN-$(CONFIG_X86) += xen-ucode
 INSTALL_SBIN   += xencov
+INSTALL_SBIN   += xenhypfs
 INSTALL_SBIN   += xenlockprof
 INSTALL_SBIN   += xenperf
 INSTALL_SBIN   += xenpm
@@ -86,6 +87,9 @@ xenperf: xenperf.o
 xenpm: xenpm.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
+xenhypfs: xenhypfs.o
+   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenhypfs) $(APPEND_LDFLAGS)
+
 xenlockprof: xenlockprof.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -94,6 +98,8 @@ xen-hptool.o: CFLAGS += -I$(XEN_ROOT)/tools/libxc 
$(CFLAGS_libxencall)
 xen-hptool: xen-hptool.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
+xenhypfs.o: CFLAGS += $(CFLAGS_libxenhypfs)
+
 # xen-mfndump incorrectly uses libxc internals
 xen-mfndump.o: CFLAGS += -I$(XEN_ROOT)/tools/libxc $(CFLAGS_libxencall)
 xen-mfndump: xen-mfndump.o
diff --git a/tools/misc/xenhypfs.c b/tools/misc/xenhypfs.c
new file mode 100644
index 00..0b834bf4fa
--- /dev/null
+++ b/tools/misc/xenhypfs.c
@@ -0,0 +1,189 @@
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct xenhypfs_handle *hdl;
+
+static int usage(void)
+{
+fprintf(stderr, "usage: xenhypfs ls \n");
+fprintf(stderr, "   xenhypfs cat [-b] \n");
+fprintf(stderr, "   xenhypfs write  \n");
+fprintf(stderr, "   xenhypfs tree\n");
+
+return 1;
+}
+
+static void xenhypfs_print_escaped(char *string)
+{
+char *c;
+
+for (c = string; *c; c++) {
+if (isgraph(*c) || isspace(*c))
+printf("%c", *c);
+else
+printf("\\x%02x", *c);
+}
+printf("\n");
+}
+
+static int xenhypfs_cat(int argc, char *argv[])
+{
+int ret = 0;
+char *result;
+char *path;
+bool bin = false;
+
+switch (argc) {
+case 1:
+path = argv[0];
+break;
+
+case 2:
+if (strcmp(argv[0], "-b"))
+return usage();
+bin = true;
+path = argv[1];
+break;
+
+default:
+return usage();
+}
+
+result = xenhypfs_read(hdl, path);
+if (!result) {
+perror("could not read");
+ret = 3;
+} else {
+if (!bin)
+printf("%s\n", result);
+else
+xenhypfs_p

[Xen-devel] [PATCH v6 08/12] xen: add /buildinfo/config entry to hypervisor filesystem

[Juergen Gross]

Add the /buildinfo/config entry to the hypervisor filesystem. This
entry contains the .config file used to build the hypervisor.

Signed-off-by: Juergen Gross 
---
V3:
- store data in gzip format
- use binfile mechanism to create data file
- move code to kernel.c

V6:
- add config item for the /buildinfo/config (Jan Beulich)
- make config related variables const in kernel.h (Jan Beulich)
---
 .gitignore   |  2 ++
 docs/misc/hypfs-paths.pandoc |  4 
 xen/common/Kconfig   | 10 ++
 xen/common/Makefile  | 12 
 xen/common/kernel.c  | 15 +++
 xen/include/xen/kernel.h |  3 +++
 6 files changed, 46 insertions(+)

diff --git a/.gitignore b/.gitignore
index fd5610718d..bc8e053ccb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -297,6 +297,8 @@ xen/arch/*/efi/boot.c
 xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
 xen/arch/*/efi/runtime.c
+xen/common/config_data.S
+xen/common/config.gz
 xen/include/headers*.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index e392feff27..1faebcccbc 100644
--- a/docs/misc/hypfs-paths.pandoc
+++ b/docs/misc/hypfs-paths.pandoc
@@ -133,6 +133,10 @@ Information about the compile domain.
 
 The compiler used to build Xen.
 
+ /buildinfo/config = STRING
+
+The contents of the `xen/.config` file at the time of the hypervisor build.
+
  /buildinfo/version/
 
 A directory containing version information of the hypervisor.
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index a6914fcae9..c3303c8dfe 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -353,6 +353,16 @@ config DOM0_MEM
 
  Leave empty if you are not sure what to specify.
 
+config HYPFS_CONFIG
+   bool "Provide hypervisor .config via hypfs entry"
+   default y
+   ---help---
+ When enabled the contents of the .config file used to build the
+ hypervisor are provided via the hypfs entry /buildinfo/config.
+
+ Disable this option in case you want to spare some memory or you
+ want to hide the .config contents from dom0.
+
 config TRACEBUFFER
bool "Enable tracing infrastructure" if EXPERT = "y"
default y
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 3a2c1ae690..100babc446 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,6 +1,7 @@
 obj-$(CONFIG_ARGO) += argo.o
 obj-y += bitmap.o
 obj-y += bsearch.o
+obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
 obj-$(CONFIG_CORE_PARKING) += core_parking.o
 obj-y += cpu.o
 obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
@@ -73,3 +74,14 @@ subdir-$(CONFIG_UBSAN) += ubsan
 
 subdir-$(CONFIG_NEEDS_LIBELF) += libelf
 subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
+
+config.gz: ../.config
+   gzip -c $< >$@
+
+config_data.o: config.gz
+
+config_data.S: $(XEN_ROOT)/xen/tools/binfile
+   $(XEN_ROOT)/xen/tools/binfile $@ config.gz xen_config_data
+
+clean::
+   rm config_data.S config.gz 2>/dev/null || true
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index da6e4b..4b7bc28afb 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -389,6 +389,16 @@ static HYPFS_STRING_INIT(compile_date, "compile_date");
 static HYPFS_STRING_INIT(compile_domain, "compile_domain");
 static HYPFS_STRING_INIT(extra, "extra");
 
+#ifdef CONFIG_HYPFS_CONFIG
+static struct hypfs_entry_leaf config = {
+.e.type = XEN_HYPFS_TYPE_STRING,
+.e.encoding = XEN_HYPFS_ENC_GZIP,
+.e.name = "config",
+.e.read = hypfs_read_leaf,
+.content = &xen_config_data
+};
+#endif
+
 static int __init buildinfo_init(void)
 {
 hypfs_add_dir(&hypfs_root, &buildinfo, true);
@@ -414,6 +424,11 @@ static int __init buildinfo_init(void)
 hypfs_add_leaf(&version, &major, true);
 hypfs_add_leaf(&version, &minor, true);
 
+#ifdef CONFIG_HYPFS_CONFIG
+config.e.size = xen_config_data_size;
+hypfs_add_leaf(&buildinfo, &config, true);
+#endif
+
 return 0;
 }
 __initcall(buildinfo_init);
diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
index 548b64da9f..02e3281f52 100644
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -100,5 +100,8 @@ extern enum system_state {
 
 bool_t is_active_kernel_text(unsigned long addr);
 
+extern const char xen_config_data;
+extern const unsigned int xen_config_data_size;
+
 #endif /* _LINUX_KERNEL_H */
 
-- 
2.16.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v6 10/12] tools/libxl: use libxenhypfs for setting xen runtime parameters

[Juergen Gross]

Instead of xc_set_parameters() use xenhypfs_write() for setting
parameters of the hypervisor.

Signed-off-by: Juergen Gross 
---
V6:
- new patch
---
 tools/Rules.mk   |  2 +-
 tools/libxl/Makefile |  3 ++-
 tools/libxl/libxl.c  | 53 +++-
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/xenlight.pc.in   |  2 +-
 tools/xl/xl_misc.c   |  1 -
 6 files changed, 52 insertions(+), 10 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index a04697a33c..4b3fcef90b 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -180,7 +180,7 @@ CFLAGS += -O2 -fomit-frame-pointer
 endif
 
 CFLAGS_libxenlight = -I$(XEN_XENLIGHT) $(CFLAGS_libxenctrl) 
$(CFLAGS_xeninclude)
-SHDEPS_libxenlight = $(SHLIB_libxenctrl) $(SHLIB_libxenstore)
+SHDEPS_libxenlight = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) 
$(SHLIB_libxenhypfs)
 LDLIBS_libxenlight = $(SHDEPS_libxenlight) 
$(XEN_XENLIGHT)/libxenlight$(libextension)
 SHLIB_libxenlight  = $(SHDEPS_libxenlight) -Wl,-rpath-link=$(XEN_XENLIGHT)
 
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 69fcf21577..a89ebab0b4 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -20,7 +20,7 @@ LIBUUID_LIBS += -luuid
 endif
 
 LIBXL_LIBS =
-LIBXL_LIBS = $(LDLIBS_libxentoollog) $(LDLIBS_libxenevtchn) 
$(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) 
$(LDLIBS_libxentoolcore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
+LIBXL_LIBS = $(LDLIBS_libxentoollog) $(LDLIBS_libxenevtchn) 
$(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenhypfs) 
$(LDLIBS_libxenstore) $(LDLIBS_libxentoolcore) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 ifeq ($(CONFIG_LIBNL),y)
 LIBXL_LIBS += $(LIBNL3_LIBS)
 endif
@@ -33,6 +33,7 @@ CFLAGS_LIBXL += $(CFLAGS_libxentoolcore)
 CFLAGS_LIBXL += $(CFLAGS_libxenevtchn)
 CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
 CFLAGS_LIBXL += $(CFLAGS_libxenguest)
+CFLAGS_LIBXL += $(CFLAGS_libxenhypfs)
 CFLAGS_LIBXL += $(CFLAGS_libxenstore)
 ifeq ($(CONFIG_LIBNL),y)
 CFLAGS_LIBXL += $(LIBNL3_CFLAGS)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f60fd3e4fd..621acc88f3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -663,15 +663,56 @@ int libxl_set_parameters(libxl_ctx *ctx, char *params)
 {
 int ret;
 GC_INIT(ctx);
+char *par, *val, *end, *path;
+xenhypfs_handle *hypfs;
 
-ret = xc_set_parameters(ctx->xch, params);
-if (ret < 0) {
-LOGEV(ERROR, ret, "setting parameters");
-GC_FREE;
-return ERROR_FAIL;
+hypfs = xenhypfs_open(ctx->lg, 0);
+if (!hypfs) {
+LOGE(ERROR, "opening Xen hypfs");
+ret = ERROR_FAIL;
+goto out;
 }
+
+while (isblank(*params))
+params++;
+
+for (par = params; *par; par = end) {
+end = strchr(par, ' ');
+if (!end)
+end = par + strlen(par);
+
+val = strchr(par, '=');
+if (val > end)
+val = NULL;
+if (!val && !strncmp(par, "no", 2)) {
+path = libxl__sprintf(gc, "/params/%s", par + 2);
+path[end - par - 2 + 8] = 0;
+val = "no";
+par += 2;
+} else {
+path = libxl__sprintf(gc, "/params/%s", par);
+path[val - par + 8] = 0;
+val = libxl__strndup(gc, val + 1, end - val - 1);
+}
+
+   LOG(DEBUG, "setting node \"%s\" to value \"%s\"", path, val);
+ret = xenhypfs_write(hypfs, path, val);
+if (ret < 0) {
+LOGE(ERROR, "setting parameters");
+ret = ERROR_FAIL;
+goto out;
+}
+
+while (isblank(*end))
+end++;
+}
+
+ret = 0;
+
+out:
+xenhypfs_close(hypfs);
 GC_FREE;
-return 0;
+return ret;
 }
 
 static int fd_set_flags(libxl_ctx *ctx, int fd,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 43e5885d1e..d970e91ca0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -56,6 +56,7 @@
 #define XC_WANT_COMPAT_MAP_FOREIGN_API
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/tools/libxl/xenlight.pc.in b/tools/libxl/xenlight.pc.in
index c0f769fd20..6b351ba096 100644
--- a/tools/libxl/xenlight.pc.in
+++ b/tools/libxl/xenlight.pc.in
@@ -9,4 +9,4 @@ Description: The Xenlight library for Xen hypervisor
 Version: @@version@@
 Cflags: -I${includedir}
 Libs: @@libsflag@@${libdir} -lxenlight
-Requires.private: xentoollog,xenevtchn,xencontrol,xenguest,xenstore
+Requires.private: xentoollog,xenevtchn,xencontrol,xenguest,xenstore,xenhypfs
diff --git a/tools/xl/xl_misc.c b/tools/xl/xl_misc.c
index 20ed605f4f..08f0fb6dc9 100644
--- a/tools/xl/xl_misc.c
+++ b/tools/xl/xl_misc.c
@@ -168,7 +168,6 @@ int main_set_parameters(int argc, char **argv)
 
 if (libxl_set_parameters(ctx, params)) {
 fprintf(stderr, "cannot set parameters: %s\n", params);
-fprintf(stderr, "Use \"xl dmesg\" to look for possible reason.\n");
 return EXIT_FAILURE

[Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param()

[Juergen Gross]

Support of other variable sizes than that of normal bool ones for
boolean_parameter() don't make sense, so catch any other sized
variables at build time.

Fix the one parameter using a plain int instead of bool.

Signed-off-by: Juergen Gross 
---
V6:
- new patch
---
 xen/arch/x86/hvm/asid.c | 2 +-
 xen/include/xen/param.h | 8 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c
index 8e00a28443..8b5bb86dfd 100644
--- a/xen/arch/x86/hvm/asid.c
+++ b/xen/arch/x86/hvm/asid.c
@@ -25,7 +25,7 @@
 #include 
 
 /* Xen command-line option to enable ASIDs */
-static int opt_asid_enabled = 1;
+static bool opt_asid_enabled = true;
 boolean_param("asid", opt_asid_enabled);
 
 /*
diff --git a/xen/include/xen/param.h b/xen/include/xen/param.h
index 75471eb4ad..d4578cd27f 100644
--- a/xen/include/xen/param.h
+++ b/xen/include/xen/param.h
@@ -2,6 +2,8 @@
 #define _XEN_PARAM_H
 
 #include 
+#include 
+#include 
 
 /*
  * Used for kernel command line parameter setup
@@ -46,7 +48,8 @@ extern const struct kernel_param __param_start[], 
__param_end[];
 __kparam __setup_##_var = \
 { .name = __setup_str_##_var, \
   .type = OPT_BOOL, \
-  .len = sizeof(_var), \
+  .len = sizeof(_var) + \
+ BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
   .par.var = &_var }
 #define integer_param(_name, _var) \
 __setup_str __setup_str_##_var[] = _name; \
@@ -86,7 +89,8 @@ extern const struct kernel_param __param_start[], 
__param_end[];
 __rtparam __rtpar_##_var = \
 { .name = _name, \
   .type = OPT_BOOL, \
-  .len = sizeof(_var), \
+  .len = sizeof(_var) + \
+ BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
   .par.var = &_var }
 #define integer_runtime_only_param(_name, _var) \
 __rtparam __rtpar_##_var = \
-- 
2.16.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v6 05/12] libs: add libxenhypfs

[Juergen Gross]

Add the new library libxenhypfs for access to the hypervisor filesystem.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
---
V1:
- rename to libxenhypfs
- add xenhypfs_write()

V3:
- major rework due to new hypervisor interface
- add decompression capability

V4:
- add dependency to libz in pkgconfig file (Wei Liu)
---
 .gitignore  |   2 +
 tools/Rules.mk  |   6 +
 tools/libs/Makefile |   1 +
 tools/libs/hypfs/Makefile   |  16 ++
 tools/libs/hypfs/core.c | 540 
 tools/libs/hypfs/include/xenhypfs.h |  75 +
 tools/libs/hypfs/libxenhypfs.map|  10 +
 tools/libs/hypfs/xenhypfs.pc.in |  10 +
 8 files changed, 660 insertions(+)
 create mode 100644 tools/libs/hypfs/Makefile
 create mode 100644 tools/libs/hypfs/core.c
 create mode 100644 tools/libs/hypfs/include/xenhypfs.h
 create mode 100644 tools/libs/hypfs/libxenhypfs.map
 create mode 100644 tools/libs/hypfs/xenhypfs.pc.in

diff --git a/.gitignore b/.gitignore
index b2624df79a..e98c3f056d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -109,6 +109,8 @@ tools/libs/evtchn/headers.chk
 tools/libs/evtchn/xenevtchn.pc
 tools/libs/gnttab/headers.chk
 tools/libs/gnttab/xengnttab.pc
+tools/libs/hypfs/headers.chk
+tools/libs/hypfs/xenhypfs.pc
 tools/libs/call/headers.chk
 tools/libs/call/xencall.pc
 tools/libs/foreignmemory/headers.chk
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 52f47be3f8..a04697a33c 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -19,6 +19,7 @@ XEN_LIBXENGNTTAB   = $(XEN_ROOT)/tools/libs/gnttab
 XEN_LIBXENCALL = $(XEN_ROOT)/tools/libs/call
 XEN_LIBXENFOREIGNMEMORY = $(XEN_ROOT)/tools/libs/foreignmemory
 XEN_LIBXENDEVICEMODEL = $(XEN_ROOT)/tools/libs/devicemodel
+XEN_LIBXENHYPFS= $(XEN_ROOT)/tools/libs/hypfs
 XEN_LIBXC  = $(XEN_ROOT)/tools/libxc
 XEN_XENLIGHT   = $(XEN_ROOT)/tools/libxl
 # Currently libxlutil lives in the same directory as libxenlight
@@ -134,6 +135,11 @@ SHDEPS_libxendevicemodel = $(SHLIB_libxentoollog) 
$(SHLIB_libxentoolcore) $(SHLI
 LDLIBS_libxendevicemodel = $(SHDEPS_libxendevicemodel) 
$(XEN_LIBXENDEVICEMODEL)/libxendevicemodel$(libextension)
 SHLIB_libxendevicemodel  = $(SHDEPS_libxendevicemodel) 
-Wl,-rpath-link=$(XEN_LIBXENDEVICEMODEL)
 
+CFLAGS_libxenhypfs = -I$(XEN_LIBXENHYPFS)/include $(CFLAGS_xeninclude)
+SHDEPS_libxenhypfs = $(SHLIB_libxentoollog) $(SHLIB_libxentoolcore) 
$(SHLIB_xencall)
+LDLIBS_libxenhypfs = $(SHDEPS_libxenhypfs) 
$(XEN_LIBXENHYPFS)/libxenhypfs$(libextension)
+SHLIB_libxenhypfs  = $(SHDEPS_libxenhypfs) -Wl,-rpath-link=$(XEN_LIBXENHYPFS)
+
 # code which compiles against libxenctrl get __XEN_TOOLS__ and
 # therefore sees the unstable hypercall interfaces.
 CFLAGS_libxenctrl = -I$(XEN_LIBXC)/include $(CFLAGS_libxentoollog) 
$(CFLAGS_libxenforeignmemory) $(CFLAGS_libxendevicemodel) $(CFLAGS_xeninclude) 
-D__XEN_TOOLS__
diff --git a/tools/libs/Makefile b/tools/libs/Makefile
index 88901e7341..69cdfb5975 100644
--- a/tools/libs/Makefile
+++ b/tools/libs/Makefile
@@ -9,6 +9,7 @@ SUBDIRS-y += gnttab
 SUBDIRS-y += call
 SUBDIRS-y += foreignmemory
 SUBDIRS-y += devicemodel
+SUBDIRS-y += hypfs
 
 ifeq ($(CONFIG_RUMP),y)
 SUBDIRS-y := toolcore
diff --git a/tools/libs/hypfs/Makefile b/tools/libs/hypfs/Makefile
new file mode 100644
index 00..06dd449929
--- /dev/null
+++ b/tools/libs/hypfs/Makefile
@@ -0,0 +1,16 @@
+XEN_ROOT = $(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+MAJOR= 1
+MINOR= 0
+LIBNAME  := hypfs
+USELIBS  := toollog toolcore call
+
+APPEND_LDFLAGS += -lz
+
+SRCS-y += core.c
+
+include ../libs.mk
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENHYPFS)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
diff --git a/tools/libs/hypfs/core.c b/tools/libs/hypfs/core.c
new file mode 100644
index 00..6d14023f88
--- /dev/null
+++ b/tools/libs/hypfs/core.c
@@ -0,0 +1,540 @@
+/*
+ * Copyright (c) 2019 SUSE Software Solutions Germany GmbH
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; If not, see .
+ */
+
+#define __XEN_TOOLS__ 1
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define BUF_SIZE 4096
+
+struct xenhypfs_handle {
+xentoollog_logger *logger, *logger_tofree;
+unsigned int flags;
+  

[Xen-devel] [PATCH v6 03/12] docs: add feature document for Xen hypervisor sysfs-like support

[Juergen Gross]

On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.

In the beginning there should only be basic support: entries can be
added from the hypervisor itself only, there is a simple hypercall
interface to read the data.

Add a feature document for setting the base of a discussion regarding
the desired functionality and the entries to add.

Signed-off-by: Juergen Gross 
---
V1:
- remove the "--" prefixes of the sub-commands of the user tool
  (Jan Beulich)
- rename xenfs to xenhypfs (Jan Beulich)
- add "tree" and "write" options to user tool

V2:
- move example tree to the paths description (Ian Jackson)
- specify allowed characters for keys and values (Ian Jackson)

V3:
- correct introduction (writable entries)

V4:
- add list specification
- add entry example (Julien Grall)
- correct date and Xen version (Julien Grall)
- add ARM64 as possible architecture (Julien Grall)
- add version description to the feature doc (Jan Beulich)
---
 docs/features/hypervisorfs.pandoc |  92 +
 docs/misc/hypfs-paths.pandoc  | 105 ++
 2 files changed, 197 insertions(+)
 create mode 100644 docs/features/hypervisorfs.pandoc
 create mode 100644 docs/misc/hypfs-paths.pandoc

diff --git a/docs/features/hypervisorfs.pandoc 
b/docs/features/hypervisorfs.pandoc
new file mode 100644
index 00..a0a0ead057
--- /dev/null
+++ b/docs/features/hypervisorfs.pandoc
@@ -0,0 +1,92 @@
+% Hypervisor FS
+% Revision 1
+
+\clearpage
+
+# Basics
+ -
+ Status: **Supported**
+
+  Architectures: all
+
+ Components: Hypervisor, toolstack
+ -
+
+# Overview
+
+The Hypervisor FS is a hierarchical name-value store for reporting
+information to guests, especially dom0. It is similar to the Linux
+kernel's sysfs. Entries and directories are created by the hypervisor,
+while the toolstack is able to use a hypercall to query the entry
+values or (if allowed by the hypervisor) to modify them.
+
+# User details
+
+With:
+
+xenhypfs ls 
+
+the user can list the entries of a specific path of the FS. Using:
+
+xenhypfs cat 
+
+the content of an entry can be retrieved. Using:
+
+xenhypfs write  
+
+a writable entry can be modified. With:
+
+xenhypfs tree
+
+the complete Hypervisor FS entry tree can be printed.
+
+The FS paths are documented in `docs/misc/hypfs-paths.pandoc`.
+
+# Technical details
+
+Access to the hypervisor filesystem is done via the stable new hypercall
+__HYPERVISOR_filesystem_op. This hypercall supports a sub-command
+XEN_HYPFS_OP_get_version which will return the highest version of the
+interface supported by the hypervisor. Additions to the interface need
+to bump the interface version. The hypervisor is required to support the
+previous interface versions, too (this implies that additions will always
+require new sub-commands in order to allow the hypervisor to decide which
+version of the interface to use).
+
+* hypercall interface specification
+* `xen/include/public/hypfs.h`
+* hypervisor internal files
+* `xen/include/xen/hypfs.h`
+* `xen/common/hypfs.c`
+* `libxenhypfs`
+* `tools/libs/libxenhypfs/*`
+* `xenhypfs`
+* `tools/misc/xenhypfs.c`
+* path documentation
+* `docs/misc/hypfs-paths.pandoc`
+
+# Testing
+
+Any new parameters or hardware mitigations should be verified to show up
+correctly in the filesystem.
+
+# Areas for improvement
+
+* More detailed access rights
+* Entries per domain and/or per cpupool
+
+# Known issues
+
+* None
+
+# References
+
+* None
+
+# History
+
+
+Date   Revision Version  Notes
+--   ---
+2020-01-23 1Xen 4.14 Document written
+--   ---
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
new file mode 100644
index 00..b9f50f6998
--- /dev/null
+++ b/docs/misc/hypfs-paths.pandoc
@@ -0,0 +1,105 @@
+# Xenhypfs Paths
+
+This document attempts to define all the paths which are available
+in the Xen hypervisor file system (hypfs).
+
+The hypervisor file system can be accessed via the xenhypfs tool.
+
+## Notation
+
+The hypervisor file system is similar to the Linux kernel's sysfs.
+In this document directories are always specified with a trailing "/".
+
+The following notation conventions apply:
+
+DIRECTORY/
+
+PATH = VALUES [TAGS]
+
+The first syntax defines a directory. It normally contains related
+entries and the general scope of the directory is described.
+
+The second syntax defines a file entry containing values which are
+either set by the hypervisor or, if the file is writable, can be set
+by the user.
+
+PATH can contain simple regex cons

[Xen-devel] [PATCH v6 00/12] Add hypervisor sysfs-like support

[Juergen Gross]

On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.

This is a first implementation of that idea adding the basic
functionality to hypervisor and tools side. The interface to any
user program making use of that "xen-hypfs" is a new library
"libxenhypfs" with a stable interface.

The series adds read-only nodes with buildinfo data and writable
nodes with runtime parameters. xl is switched to use the new file
system for modifying the runtime parameters and the old sysctl
interface for that purpose is dropped.

Changes in V6:
- added new patches 1, 10, 11, 12
- addressed review comments
- modified interface for creating nodes for runtime parameters

Changes in V5:
- switched to xsm for privilege check

Changes in V4:
- former patch 2 removed as already committed
- addressed review comments

Changes in V3:
- major rework, especially by supporting binary contents of entries
- added several new patches (1, 2, 7)
- full support of all runtime parameters
- support of writing entries (especially runtime parameters)

Changes in V2:
- all comments to V1 addressed
- added man-page for xenhypfs tool
- added runtime parameter read access for string parameters

Changes in V1:
- renamed xenfs ->xenhypfs
- added writable entries support at the interface level and in the
  xenhypfs tool
- added runtime parameter read access (integer type only for now)
- added docs/misc/hypfs-paths.pandoc for path descriptions

Juergen Gross (12):
  xen: allow only sizeof(bool) variables for boolean_param()
  xen: add a generic way to include binary files as variables
  docs: add feature document for Xen hypervisor sysfs-like support
  xen: add basic hypervisor filesystem support
  libs: add libxenhypfs
  tools: add xenfs tool
  xen: provide version information in hypfs
  xen: add /buildinfo/config entry to hypervisor filesystem
  xen: add runtime parameter access support to hypfs
  tools/libxl: use libxenhypfs for setting xen runtime parameters
  tools/libxc: remove xc_set_parameters()
  xen: remove XEN_SYSCTL_set_parameter support

 .gitignore  |   6 +
 docs/features/hypervisorfs.pandoc   |  92 ++
 docs/man/xenhypfs.1.pod |  61 
 docs/misc/hypfs-paths.pandoc| 163 +++
 tools/Rules.mk  |   8 +-
 tools/flask/policy/modules/dom0.te  |   4 +-
 tools/libs/Makefile |   1 +
 tools/libs/hypfs/Makefile   |  16 ++
 tools/libs/hypfs/core.c | 540 
 tools/libs/hypfs/include/xenhypfs.h |  75 +
 tools/libs/hypfs/libxenhypfs.map|  10 +
 tools/libs/hypfs/xenhypfs.pc.in |  10 +
 tools/libxc/include/xenctrl.h   |   1 -
 tools/libxc/xc_misc.c   |  21 --
 tools/libxl/Makefile|   3 +-
 tools/libxl/libxl.c |  53 +++-
 tools/libxl/libxl_internal.h|   1 +
 tools/libxl/xenlight.pc.in  |   2 +-
 tools/misc/Makefile |   6 +
 tools/misc/xenhypfs.c   | 189 +
 tools/xl/xl_misc.c  |   1 -
 xen/arch/arm/traps.c|   1 +
 xen/arch/arm/xen.lds.S  |  10 +-
 xen/arch/x86/hvm/asid.c |   2 +-
 xen/arch/x86/hvm/hypercall.c|   1 +
 xen/arch/x86/hvm/vmx/vmcs.c |  30 +-
 xen/arch/x86/hypercall.c|   1 +
 xen/arch/x86/pv/domain.c|  26 +-
 xen/arch/x86/pv/hypercall.c |   1 +
 xen/arch/x86/xen.lds.S  |  10 +-
 xen/common/Kconfig  |  10 +
 xen/common/Makefile |  13 +
 xen/common/grant_table.c|  37 ++-
 xen/common/hypfs.c  | 377 +
 xen/common/kernel.c |  84 +-
 xen/common/sysctl.c |  36 ---
 xen/drivers/char/console.c  |  66 -
 xen/include/Makefile|   1 +
 xen/include/public/hypfs.h  | 127 +
 xen/include/public/sysctl.h |  18 --
 xen/include/public/xen.h|   1 +
 xen/include/xen/hypercall.h |   8 +
 xen/include/xen/hypfs.h | 105 +++
 xen/include/xen/kernel.h|   3 +
 xen/include/xen/lib.h   |   1 -
 xen/include/xen/param.h |  96 ---
 xen/include/xlat.lst|   2 +
 xen/include/xsm/dummy.h |   6 +
 xen/include/xsm/xsm.h   |   6 +
 xen/tools/binfile   |  41 +++
 xen/xsm/dummy.c |   1 +
 xen/xsm/flask/Makefile  |   5 +-
 xen/xsm/flask/flask-policy.S|  16 --
 xen/xsm/flask/hooks.c   |   9 +-
 xen/xsm/flask/policy/access_vectors |   4 +-
 55 files changed, 2243 insertions(+), 175 deletions(-)
 create mode 100644 docs/features/hypervisorfs.pandoc
 create mode 100644 docs/man/xenhypfs.1.pod
 create mode 100644 docs/misc/hypfs-paths.pandoc
 create mode 100644 to

[Xen-devel] [PATCH v6 11/12] tools/libxc: remove xc_set_parameters()

[Juergen Gross]

There is no user of xc_set_parameters() left, so remove it.

Signed-off-by: Juergen Gross 
---
V6:
- new patch
---
 tools/libxc/include/xenctrl.h |  1 -
 tools/libxc/xc_misc.c | 21 -
 2 files changed, 22 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 99552a5f73..8677433c5f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1226,7 +1226,6 @@ int xc_readconsolering(xc_interface *xch,
int clear, int incremental, uint32_t *pindex);
 
 int xc_send_debug_keys(xc_interface *xch, char *keys);
-int xc_set_parameters(xc_interface *xch, char *params);
 
 typedef struct xen_sysctl_physinfo xc_physinfo_t;
 typedef struct xen_sysctl_cputopo xc_cputopo_t;
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 093fa44081..9b66330082 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -187,27 +187,6 @@ int xc_send_debug_keys(xc_interface *xch, char *keys)
 return ret;
 }
 
-int xc_set_parameters(xc_interface *xch, char *params)
-{
-int ret, len = strlen(params);
-DECLARE_SYSCTL;
-DECLARE_HYPERCALL_BOUNCE(params, len, XC_HYPERCALL_BUFFER_BOUNCE_IN);
-
-if ( xc_hypercall_bounce_pre(xch, params) )
-return -1;
-
-sysctl.cmd = XEN_SYSCTL_set_parameter;
-set_xen_guest_handle(sysctl.u.set_parameter.params, params);
-sysctl.u.set_parameter.size = len;
-memset(sysctl.u.set_parameter.pad, 0, sizeof(sysctl.u.set_parameter.pad));
-
-ret = do_sysctl(xch, &sysctl);
-
-xc_hypercall_bounce_post(xch, params);
-
-return ret;
-}
-
 int xc_physinfo(xc_interface *xch,
 xc_physinfo_t *put_info)
 {
-- 
2.16.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v6 07/12] xen: provide version information in hypfs

[Juergen Gross]

Provide version and compile information in /buildinfo/ node of the
Xen hypervisor file system. As this information is accessible by dom0
only no additional security problem arises.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich 
---
V3:
- new patch

V4:
- add __read_mostly annotations (Jan Beulich)
---
 docs/misc/hypfs-paths.pandoc | 45 
 xen/common/kernel.c  | 45 
 2 files changed, 90 insertions(+)

diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index b9f50f6998..e392feff27 100644
--- a/docs/misc/hypfs-paths.pandoc
+++ b/docs/misc/hypfs-paths.pandoc
@@ -103,3 +103,48 @@ A populated Xen hypervisor file system might look like the 
following example:
  /
 
 The root of the hypervisor file system.
+
+ /buildinfo/
+
+A directory containing static information generated while building the
+hypervisor.
+
+ /buildinfo/changeset = STRING
+
+Git commit of the hypervisor.
+
+ /buildinfo/compileinfo/
+
+A directory containing information about compilation of Xen.
+
+ /buildinfo/compileinfo/compile_by = STRING
+
+Information who compiled the hypervisor.
+
+ /buildinfo/compileinfo/compile_date = STRING
+
+Date of the hypervisor compilation.
+
+ /buildinfo/compileinfo/compile_domain = STRING
+
+Information about the compile domain.
+
+ /buildinfo/compileinfo/compiler = STRING
+
+The compiler used to build Xen.
+
+ /buildinfo/version/
+
+A directory containing version information of the hypervisor.
+
+ /buildinfo/version/extra = STRING
+
+Extra version information.
+
+ /buildinfo/version/major = INTEGER
+
+The major version of Xen.
+
+ /buildinfo/version/minor = INTEGER
+
+The minor version of Xen.
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 22941cec94..da6e4b 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -373,6 +374,50 @@ void __init do_initcalls(void)
 (*call)();
 }
 
+static unsigned int __read_mostly major_version;
+static unsigned int __read_mostly minor_version;
+
+static HYPFS_DIR_INIT(buildinfo, "buildinfo");
+static HYPFS_DIR_INIT(compileinfo, "compileinfo");
+static HYPFS_DIR_INIT(version, "version");
+static HYPFS_UINT_INIT(major, "major", major_version);
+static HYPFS_UINT_INIT(minor, "minor", minor_version);
+static HYPFS_STRING_INIT(changeset, "changeset");
+static HYPFS_STRING_INIT(compiler, "compiler");
+static HYPFS_STRING_INIT(compile_by, "compile_by");
+static HYPFS_STRING_INIT(compile_date, "compile_date");
+static HYPFS_STRING_INIT(compile_domain, "compile_domain");
+static HYPFS_STRING_INIT(extra, "extra");
+
+static int __init buildinfo_init(void)
+{
+hypfs_add_dir(&hypfs_root, &buildinfo, true);
+
+hypfs_string_set_reference(&changeset, xen_changeset());
+hypfs_add_leaf(&buildinfo, &changeset, true);
+
+hypfs_add_dir(&buildinfo, &compileinfo, true);
+hypfs_string_set_reference(&compiler, xen_compiler());
+hypfs_string_set_reference(&compile_by, xen_compile_by());
+hypfs_string_set_reference(&compile_date, xen_compile_date());
+hypfs_string_set_reference(&compile_domain, xen_compile_domain());
+hypfs_add_leaf(&compileinfo, &compiler, true);
+hypfs_add_leaf(&compileinfo, &compile_by, true);
+hypfs_add_leaf(&compileinfo, &compile_date, true);
+hypfs_add_leaf(&compileinfo, &compile_domain, true);
+
+major_version = xen_major_version();
+minor_version = xen_minor_version();
+hypfs_add_dir(&buildinfo, &version, true);
+hypfs_string_set_reference(&extra, xen_extra_version());
+hypfs_add_leaf(&version, &extra, true);
+hypfs_add_leaf(&version, &major, true);
+hypfs_add_leaf(&version, &minor, true);
+
+return 0;
+}
+__initcall(buildinfo_init);
+
 # define DO(fn) long do_##fn
 
 #endif
-- 
2.16.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/vPMU: don't blindly assume IA32_PERF_CAPABILITIES MSR exists

[Chen, Farrah]

I applied this patch to Xen and retested, Xen on KVM booted up successfully, 
thanks a lot.

Thanks,
Fan

-Original Message-
From: Andrew Cooper  
Sent: Wednesday, February 26, 2020 6:56 PM
To: Jan Beulich ; Roger Pau Monné 
Cc: xen-devel@lists.xenproject.org; Chen, Farrah ; Hao, 
Xudong ; Gao, Chao ; Wei Liu 

Subject: Re: [PATCH] x86/vPMU: don't blindly assume IA32_PERF_CAPABILITIES MSR 
exists

On 26/02/2020 10:39, Jan Beulich wrote:
> On 26.02.2020 11:09, Roger Pau Monné wrote:
>> On Wed, Feb 26, 2020 at 10:19:19AM +0100, Jan Beulich wrote:
>>> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit 
>>> should be consulted first.
>>>
>>> Reported-by: Farrah Chen 
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/cpu/vpmu_intel.c
>>> +++ b/xen/arch/x86/cpu/vpmu_intel.c
>>> @@ -900,7 +900,6 @@ int vmx_vpmu_initialise(struct vcpu *v)
>>>  
>>>  int __init core2_vpmu_init(void)
>>>  {
>>> -u64 caps;
>>>  unsigned int version = 0;
>>>  unsigned int i;
>>>  
>>> @@ -932,8 +931,14 @@ int __init core2_vpmu_init(void)
>>>  
>>>  arch_pmc_cnt = core2_get_arch_pmc_count();
>>>  fixed_pmc_cnt = core2_get_fixed_pmc_count();
>>> -rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
>>> -full_width_write = (caps >> 13) & 1;
>>> +
>>> +if ( cpu_has_pdcm )
>>> +{
>>> +uint64_t caps;
>>> +
>>> +rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
>>> +full_width_write = (caps >> 13) & 1;
>> Will PMU work without PDCM?

The performance counter interface in CPUs predate the introduction of PERF_CAPS.

>> I've been grepping the Intel SDMs, but the only mention is that PDCM 
>> signal the availability of MSR_IA32_PERF_CAPABILITIES.
> Well, there's no other use of the MSR afaics except for getting the 
> one bit here, so I assume it'll work.

It is an off-by-default, outside security support area of functionality with 
known functional bugs outstanding against it.

"not crash" is a fine improvement on the status quo.

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v6 04/12] xen: add basic hypervisor filesystem support

[Juergen Gross]

Add the infrastructure for the hypervisor filesystem.

This includes the hypercall interface and the base functions for
entry creation, deletion and modification.

In order not to have to repeat the same pattern multiple times in case
adding a new node should BUG_ON() failure, the helpers for adding a
node (hypfs_add_dir() and hypfs_add_leaf()) get a nofault parameter
causing the BUG() in case of a failure.

When supporting writable leafs the entry's write pointer will need to
be set to the function performing the write to the variable holding the
content. In case there are no special constraints this will be
hypfs_write_bool() for type XEN_HYPFS_TYPE_BOOL and hypfs_write_leaf()
for the other entry types.

Signed-off-by: Juergen Gross 
---
V1:
- rename files from filesystem.* to hypfs.*
- add dummy write entry support
- rename hypercall filesystem_op to hypfs_op
- add support for unsigned integer entries

V2:
- test new entry name to be valid

V3:
- major rework, especially by supporting binary contents of entries
- addressed all comments

V4:
- sort #includes alphabetically (Wei Liu)
- add public interface structures to xlat.lst (Jan Beulich)
- let DIRENTRY_SIZE() add 1 for trailing nul byte (Jan Beulich)
- remove hypfs_add_entry() (Jan Beulich)
- len -> ulen (Jan Beulich)
- switch sequence of tests in hypfs_get_entry_rel() (Jan Beulich)
- add const qualifier (Jan Beulich)
- return -ENOBUFS if only direntry but no entry contents are returned
  (Jan Beulich)
- use xmalloc() instead of xzalloc() (Jan Beulich)
- better error handling in hypfs_write_leaf() (Jan Beulich)
- return -EOPNOTSUPP for unknown sub-command (Jan Beulich)
- use plain integers for enum-like constants in public interface
  (Jan Beulich)
- rename XEN_HYPFS_OP_read_contents to XEN_HYPFS_OP_read (Jan Beulich)
- add some comments in include/public/hypfs.h (Jan Beulich)
- use const_char for user parameter path (Jan Beulich)
- add helpers for XEN_HYPFS_TYPE_BOOL and XEN_HYPFS_TYPE_INT entry
  definitions (Jan Beulich)
- make statically defined entries __read_mostly (Jan Beulich)

V5:
- switch to xsm for privilege check

V6:
- use memchr() for testing correct string length (Jan Beulich)
- reject writing to non-string leafs with wrong length (Jan Beulich)
- only support bools of natural size (Julien Grall)
- adjust blank padding in header (Jan Beulich)
- adjust comments in public header (Jan Beulich)
- rename hypfs_string_set() and add comment (Jan Beulich)
- add common HYPFS_INIT helper macro (Jan Beulich)
- really check structures added to xlat.lst (Jan Beulich)
- add missing xsm parts (Jan Beulich)
---
 tools/flask/policy/modules/dom0.te  |   2 +-
 xen/arch/arm/traps.c|   1 +
 xen/arch/x86/hvm/hypercall.c|   1 +
 xen/arch/x86/hypercall.c|   1 +
 xen/arch/x86/pv/hypercall.c |   1 +
 xen/common/Makefile |   1 +
 xen/common/hypfs.c  | 349 
 xen/include/Makefile|   1 +
 xen/include/public/hypfs.h  | 127 +
 xen/include/public/xen.h|   1 +
 xen/include/xen/hypercall.h |   8 +
 xen/include/xen/hypfs.h | 103 +++
 xen/include/xlat.lst|   2 +
 xen/include/xsm/dummy.h |   6 +
 xen/include/xsm/xsm.h   |   6 +
 xen/xsm/dummy.c |   1 +
 xen/xsm/flask/hooks.c   |   6 +
 xen/xsm/flask/policy/access_vectors |   2 +
 18 files changed, 618 insertions(+), 1 deletion(-)
 create mode 100644 xen/common/hypfs.c
 create mode 100644 xen/include/public/hypfs.h
 create mode 100644 xen/include/xen/hypfs.h

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index 272f6a4f75..20925e38a2 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -11,7 +11,7 @@ allow dom0_t xen_t:xen {
mtrr_del mtrr_read microcode physinfo quirk writeconsole readapic
writeapic privprofile nonprivprofile kexec firmware sleep frequency
getidle debug getcpuinfo heap pm_op mca_op lockprof cpupool_op
-   getscheduler setscheduler
+   getscheduler setscheduler hypfs_op
 };
 allow dom0_t xen_t:xen2 {
resource_op psr_cmt_op psr_alloc pmu_ctrl get_symbol
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6f9bec22d3..87af810667 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1382,6 +1382,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
 #ifdef CONFIG_ARGO
 HYPERCALL(argo_op, 5),
 #endif
+HYPERCALL(hypfs_op, 5),
 };
 
 #ifndef NDEBUG
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index 33dd2d99d2..210dda4f38 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -144,6 +144,7 @@ static const hypercall_table_t hvm_hypercall_table[] = {
 #endif
 HYPERCALL(xenpmu_op),
 COMPAT_CALL(dm_op),
+HYPERCALL(hypfs_op),
 HYPERCALL(arch_1)
 };
 
dif

[Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs

[Juergen Gross]

Add support to read and modify values of hypervisor runtime parameters
via the hypervisor file system.

As runtime parameters can be modified via a sysctl, too, this path has
to take the hypfs rw_lock as writer.

For custom runtime parameters the connection between the parameter
value and the file system is done via an init function which will set
the initial value (if needed) and the leaf properties.

Signed-off-by: Juergen Gross 
---
V3:
- complete rework
- support custom parameters, too
- support parameter writing

V6:
- rewording in docs/misc/hypfs-paths.pandoc (Jan Beulich)
- use memchr() (Jan Beulich)
- use strlcat() (Jan Beulich)
- rework to use a custom parameter init function instead of a reference
  to a content variable, allowing to drop default strings
- style correction (Jan Beulich)
- dropping param_append_str() in favor of a custom function at its only
  use site
---
 docs/misc/hypfs-paths.pandoc |  9 +
 xen/arch/arm/xen.lds.S   |  5 +++
 xen/arch/x86/hvm/vmx/vmcs.c  | 30 -
 xen/arch/x86/pv/domain.c | 26 +--
 xen/arch/x86/xen.lds.S   |  5 +++
 xen/common/grant_table.c | 37 -
 xen/common/hypfs.c   | 38 +
 xen/common/kernel.c  | 27 ++-
 xen/drivers/char/console.c   | 66 +
 xen/include/xen/hypfs.h  |  4 +++
 xen/include/xen/param.h  | 78 +++-
 11 files changed, 299 insertions(+), 26 deletions(-)

diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index 1faebcccbc..b4a5b6086e 100644
--- a/docs/misc/hypfs-paths.pandoc
+++ b/docs/misc/hypfs-paths.pandoc
@@ -152,3 +152,12 @@ The major version of Xen.
  /buildinfo/version/minor = INTEGER
 
 The minor version of Xen.
+
+ /params/
+
+A directory of runtime parameters.
+
+ /params/*
+
+The individual parameters. The description of the different parameters can be
+found in `docs/misc/xen-command-line.pandoc`.
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index a497f6a48d..0061a8dfea 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -89,6 +89,11 @@ SECTIONS
__start_schedulers_array = .;
*(.data.schedulers)
__end_schedulers_array = .;
+
+   . = ALIGN(8);
+   __paramhypfs_start = .;
+   *(.data.paramhypfs)
+   __paramhypfs_end = .;
*(.data.rel)
*(.data.rel.*)
CONSTRUCTORS
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 65445afeb0..3b690b05ed 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -70,6 +70,30 @@ integer_param("ple_window", ple_window);
 static bool __read_mostly opt_ept_pml = true;
 static s8 __read_mostly opt_ept_ad = -1;
 int8_t __read_mostly opt_ept_exec_sp = -1;
+static char opt_ept_setting[16];
+
+static void update_ept_param_append(const char *str, int val)
+{
+char *pos = opt_ept_setting + strlen(opt_ept_setting);
+
+snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting),
+ ",%s=%d", str, val);
+}
+
+static void update_ept_param(void)
+{
+snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", opt_ept_pml);
+if ( opt_ept_ad >= 0 )
+update_ept_param_append("ad", opt_ept_ad);
+if ( opt_ept_exec_sp >= 0 )
+update_ept_param_append("exec-sp", opt_ept_exec_sp);
+}
+
+static void __init init_ept_param(struct param_hypfs *par)
+{
+custom_runtime_set_var(par, opt_ept_setting);
+update_ept_param();
+}
 
 static int __init parse_ept_param(const char *s)
 {
@@ -93,6 +117,8 @@ static int __init parse_ept_param(const char *s)
 s = ss + 1;
 } while ( *ss );
 
+update_ept_param();
+
 return rc;
 }
 custom_param("ept", parse_ept_param);
@@ -115,6 +141,8 @@ static int parse_ept_param_runtime(const char *s)
 
 opt_ept_exec_sp = val;
 
+update_ept_param();
+
 rcu_read_lock(&domlist_read_lock);
 for_each_domain ( d )
 {
@@ -144,7 +172,7 @@ static int parse_ept_param_runtime(const char *s)
 
 return 0;
 }
-custom_runtime_only_param("ept", parse_ept_param_runtime);
+custom_runtime_only_param("ept", parse_ept_param_runtime, init_ept_param);
 
 /* Dynamic (run-time adjusted) execution control flags. */
 u32 vmx_pin_based_exec_control __read_mostly;
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 0b37653b12..96fae68409 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -20,8 +20,27 @@ static __read_mostly enum {
 PCID_OFF,
 PCID_ALL,
 PCID_XPTI,
-PCID_NOXPTI
+PCID_NOXPTI,
+PCID_END
 } opt_pcid = PCID_XPTI;
+static const char *opt_pcid_2_string[PCID_END] = {
+[PCID_OFF] = "off",
+[PCID_ALL] = "on",
+[PCID_XPTI] = "xpti",
+[PCID_NOXPTI] = "noxpti"
+};
+static char opt_pcid_val[7];
+
+static void update_opt_pcid(void)
+{
+strlcpy(opt_pcid_val, opt_pcid_2_string[opt_pcid], sizeof(opt_pcid_

[Xen-devel] [PATCH v6 12/12] xen: remove XEN_SYSCTL_set_parameter support

[Juergen Gross]

The functionality of XEN_SYSCTL_set_parameter is available via hypfs
now, so it can be removed.

This allows to remove the kernel_param structure for runtime parameters
by putting the now only used structure element into the hypfs node
structure of the runtime parameters.

Signed-off-by: Juergen Gross 
---
V6:
- new patch
---
 tools/flask/policy/modules/dom0.te  |  2 +-
 xen/arch/arm/xen.lds.S  |  5 
 xen/arch/x86/xen.lds.S  |  5 
 xen/common/hypfs.c  | 12 +
 xen/common/kernel.c | 11 
 xen/common/sysctl.c | 36 --
 xen/include/public/sysctl.h | 18 -
 xen/include/xen/hypfs.h |  2 --
 xen/include/xen/lib.h   |  1 -
 xen/include/xen/param.h | 50 +++--
 xen/xsm/flask/hooks.c   |  3 ---
 xen/xsm/flask/policy/access_vectors |  2 --
 12 files changed, 11 insertions(+), 136 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index 20925e38a2..0a63ce15b6 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -16,7 +16,7 @@ allow dom0_t xen_t:xen {
 allow dom0_t xen_t:xen2 {
resource_op psr_cmt_op psr_alloc pmu_ctrl get_symbol
get_cpu_levelling_caps get_cpu_featureset livepatch_op
-   coverage_op set_parameter
+   coverage_op
 };
 
 # Allow dom0 to use all XENVER_ subops that have checks.
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 0061a8dfea..8bd971bd57 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -54,11 +54,6 @@ SECTIONS
*(.data.rel.ro)
*(.data.rel.ro.*)
 
-   . = ALIGN(POINTER_ALIGN);
-   __param_start = .;
-   *(.data.param)
-   __param_end = .;
-
__proc_info_start = .;
*(.proc.info)
__proc_info_end = .;
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 21a37f0f57..88f14e5e59 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -128,11 +128,6 @@ SECTIONS
*(.ex_table.pre)
__stop___pre_ex_table = .;
 
-   . = ALIGN(POINTER_ALIGN);
-   __param_start = .;
-   *(.data.param)
-   __param_end = .;
-
 #if defined(CONFIG_HAS_VPCI) && defined(CONFIG_LATE_HWDOM)
. = ALIGN(POINTER_ALIGN);
__start_vpci_array = .;
diff --git a/xen/common/hypfs.c b/xen/common/hypfs.c
index 9503ef0731..f2e86e4632 100644
--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -302,7 +302,7 @@ int hypfs_write_custom(struct hypfs_entry_leaf *leaf,
 goto out;
 
 p = container_of(leaf, struct param_hypfs, hypfs);
-ret = p->param->par.func(buf);
+ret = p->func(buf);
 
  out:
 xfree(buf);
@@ -375,13 +375,3 @@ long do_hypfs_op(unsigned int cmd,
 
 return ret;
 }
-
-void hypfs_write_lock(void)
-{
-write_lock(&hypfs_lock);
-}
-
-void hypfs_write_unlock(void)
-{
-write_unlock(&hypfs_lock);
-}
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 7516242337..876830f5fa 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -196,17 +196,6 @@ static void __init _cmdline_parse(const char *cmdline)
 parse_params(cmdline, __setup_start, __setup_end);
 }
 
-int runtime_parse(const char *line)
-{
-int ret;
-
-hypfs_write_lock();
-ret = parse_params(line, __param_start, __param_end);
-hypfs_write_unlock();
-
-return ret;
-}
-
 /**
  *cmdline_parse -- parses the xen command line.
  * If CONFIG_CMDLINE is set, it would be parsed prior to @cmdline.
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 1c6a817476..ec916424e5 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -471,42 +471,6 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 copyback = 1;
 break;
 
-case XEN_SYSCTL_set_parameter:
-{
-#define XEN_SET_PARAMETER_MAX_SIZE 1023
-char *params;
-
-if ( op->u.set_parameter.pad[0] || op->u.set_parameter.pad[1] ||
- op->u.set_parameter.pad[2] )
-{
-ret = -EINVAL;
-break;
-}
-if ( op->u.set_parameter.size > XEN_SET_PARAMETER_MAX_SIZE )
-{
-ret = -E2BIG;
-break;
-}
-params = xmalloc_bytes(op->u.set_parameter.size + 1);
-if ( !params )
-{
-ret = -ENOMEM;
-break;
-}
-if ( copy_from_guest(params, op->u.set_parameter.params,
- op->u.set_parameter.size) )
-ret = -EFAULT;
-else
-{
-params[op->u.set_parameter.size] = 0;
-ret = runtime_parse(params);
-}
-
-xfree(params);
-
-break;
-}
-
 default:
 ret = arch_do_sysctl(op, u_sysctl);
 copyback = 0;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 7e43bfe1bd..0d

Re: [Xen-devel] [XEN PATCH v3 04/23] xen/build: remove use of AFLAGS-y

[Jan Beulich]

On 26.02.2020 12:33, Anthony PERARD wrote:
> And simply add directly to AFLAGS.
> 
> Signed-off-by: Anthony PERARD 

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 v4 1/4] x86: introduce a nmi_count tracking variable

[Jan Beulich]

On 26.02.2020 13:19, Roger Pau Monne wrote:
> This is modeled after the irq_count variable, and is used to account
> for all the NMIs handled by the system.
> 
> This will allow to repurpose the nmi_count() helper so it can be used
> in a similar manner as local_irq_count(): account for the NMIs
> currently in service.
> 
> Signed-off-by: Roger Pau Monné 

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 v4 2/4] x86: track when in NMI context

[Jan Beulich]

On 26.02.2020 13:19, Roger Pau Monne wrote:
> Add helpers to track when running in NMI handler context. This is
> modeled after the in_irq helpers.
> 
> The SDM states that no NMI can be delivered while handling a NMI
> until the processor has executed an iret instruction. It's possible
> however that another fault is received while handling the NMI (a #MC
> for example), and thus the iret from that fault would allow further
> NMIs to be injected while still processing the previous one, and
> hence an integer is needed in order to keep track of in service NMIs.
> The added macros only track when the execution context is in the NMI
> handler, but that doesn't mean NMIs are blocked for the reasons listed
> above.
> 
> Note that there are no users of in_nmi_handler() introduced by the
> change, further users will be added by followup changes.
> 
> Signed-off-by: Roger Pau Monné 

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 v4 3/4] x86: track when in #MC context

[Jan Beulich]

On 26.02.2020 13:19, Roger Pau Monne wrote:
> Add helpers to track when executing in #MC handler context. This is
> modeled after the in_irq helpers.
> 
> Note that there are no users of in_mce_handler() introduced by the
> change, further users will be added by followup changes.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

FTR I'm not finally certain this doesn't go a little too far.
#MC handling paths have to be very careful anyway in what they
call or do.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context

[Jan Beulich]

On 26.02.2020 13:38, Roger Pau Monne wrote:
> Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
> context because it can nest, and hence send_IPI_mask could be
> overwriting another user scratch cpumask data when used in such
> contexts.
> 
> Instead introduce a new cpumask to be used by send_IPI_mask, and
> disable interrupts while using it.

With this now apparently stale sentence dropped (easily done
while committing)

> Fallback to not using the scratch cpumask (and hence not attemping to
> optimize IPI sending by using a shorthand) when in IRQ or exception
> context. Note that the scratch cpumask cannot be used when
> non-maskable interrupts are being serviced (NMI or #MC) and hence
> fallback to not using the shorthand in that case, like it was done
> previously.
> 
> Fixes: 5500d265a2a8 ('x86/smp: use APIC ALLBUT destination shorthand when 
> possible')
> Reported-by: Sander Eikelenboom 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH V5] x86/altp2m: Hypercall to set altp2m view visibility

[Alexandru Stefan ISAILA]

At this moment a guest can call vmfunc to change the altp2m view. This
should be limited in order to avoid any unwanted view switch.

The new xc_altp2m_set_visibility() solves this by making views invisible
to vmfunc.
This is done by having a separate arch.altp2m_working_eptp that is
populated and made invalid in the same places as altp2m_eptp. This is
written to EPTP_LIST_ADDR.
The views are made in/visible by marking them with INVALID_MFN or
copying them back from altp2m_eptp.
To have consistency the visibility also applies to
p2m_switch_domain_altp2m_by_id().

Note: If altp2m mode is set to mixed the guest is able to change the view
visibility and then call vmfunc.

Signed-off-by: Alexandru Isaila 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: George Dunlap 
CC: Jan Beulich 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: "Roger Pau Monné" 
CC: Jun Nakajima 
CC: Kevin Tian 
---
Changes since V4:
- Move p2m specific things from hvm to p2m.c
- Add comment for altp2m_idx bounds check
- Add altp2m_list_lock/unlock().

Changes since V3:
- Change var name form altp2m_idx to idx to shorten line length
- Add bounds check for idx
- Update commit message
- Add comment in xenctrl.h.

Changes since V2:
- Drop hap_enabled() check
- Reduce the indentation depth in hvm.c
- Fix assignment indentation
- Drop pad2.

Changes since V1:
- Drop double view from title.
---
 tools/libxc/include/xenctrl.h   |  7 +++
 tools/libxc/xc_altp2m.c | 24 ++
 xen/arch/x86/hvm/hvm.c  | 14 +
 xen/arch/x86/hvm/vmx/vmx.c  |  2 +-
 xen/arch/x86/mm/hap/hap.c   | 15 ++
 xen/arch/x86/mm/p2m-ept.c   |  1 +
 xen/arch/x86/mm/p2m.c   | 36 +++--
 xen/include/asm-x86/domain.h|  1 +
 xen/include/asm-x86/p2m.h   |  4 
 xen/include/public/hvm/hvm_op.h |  9 +
 10 files changed, 110 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 99552a5f73..b26fccc989 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1943,6 +1943,13 @@ int xc_altp2m_change_gfn(xc_interface *handle, uint32_t 
domid,
  xen_pfn_t new_gfn);
 int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, uint32_t domid,
uint32_t vcpuid, uint16_t *p2midx);
+/*
+ * Set view visibility for xc_altp2m_switch_to_view and vmfunc.
+ * Note: If altp2m mode is set to mixed the guest is able to change the view
+ * visibility and then call vmfunc.
+ */
+int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, bool visible);
 
 /** 
  * Mem paging operations.
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index 46fb725806..6987c9541f 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -410,3 +410,27 @@ int xc_altp2m_get_vcpu_p2m_idx(xc_interface *handle, 
uint32_t domid,
 xc_hypercall_buffer_free(handle, arg);
 return rc;
 }
+
+int xc_altp2m_set_visibility(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, bool visible)
+{
+int rc;
+
+DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+
+arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+arg->cmd = HVMOP_altp2m_set_visibility;
+arg->domain = domid;
+arg->u.set_visibility.altp2m_idx = view_id;
+arg->u.set_visibility.visible = visible;
+
+rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+  HYPERCALL_BUFFER_AS_ARG(arg));
+
+xc_hypercall_buffer_free(handle, arg);
+return rc;
+}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a339b36a0d..25a65f6e25 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4563,6 +4563,7 @@ static int do_altp2m_op(
 case HVMOP_altp2m_get_mem_access:
 case HVMOP_altp2m_change_gfn:
 case HVMOP_altp2m_get_p2m_idx:
+case HVMOP_altp2m_set_visibility:
 break;
 
 default:
@@ -4840,6 +4841,19 @@ static int do_altp2m_op(
 break;
 }
 
+case HVMOP_altp2m_set_visibility:
+{
+uint16_t idx = a.u.set_visibility.altp2m_idx;
+
+if ( a.u.set_visibility.pad )
+rc = -EINVAL;
+else if ( !altp2m_active(d) )
+rc = -EOPNOTSUPP;
+else
+rc = p2m_set_altp2m_view_visibility(d, idx,
+a.u.set_visibility.visible);
+}
+
 default:
 ASSERT_UNREACHABLE();
 }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index d265ed46ad..bb44ef39a1 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2140,7 +2140,7 

[Xen-devel] [PATCH] libxl: add initializers for libxl__domid_history

[Paul Durrant]

This patch fixes Coverity issue CID 1459006 (Insecure data handling
(INTEGER_OVERFLOW)).

The problem is that the error paths for libxl__mark_domid_recent() and
libxl__is_domid_recent() check the 'f' field in struct libxl__domid_history
when it may not have been initialized.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Anthony PERARD 
---
 tools/libxl/libxl_domain.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 8937aeb260..41d08394f3 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1390,7 +1390,7 @@ static int libxl__read_recent(libxl__gc *gc,
 static int libxl__mark_domid_recent(libxl__gc *gc, uint32_t domid)
 {
 libxl__flock *lock;
-struct libxl__domid_history ctxt;
+struct libxl__domid_history ctxt = {};
 char *new;
 FILE *nf = NULL;
 int r, rc;
@@ -1461,7 +1461,7 @@ out:
 
 int libxl__is_domid_recent(libxl__gc *gc, uint32_t domid, bool *recent)
 {
-struct libxl__domid_history ctxt;
+struct libxl__domid_history ctxt = {};
 int rc;
 
 rc = libxl__open_domid_history(gc, &ctxt);
-- 
2.20.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-linus test] 147541: regressions - FAIL

[osstest service owner]

flight 147541 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147541/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-shadow12 guest-start  fail REGR. vs. 133580
 test-amd64-amd64-xl-shadow   12 guest-start  fail REGR. vs. 133580
 test-amd64-amd64-xl-credit2  12 guest-start  fail REGR. vs. 133580
 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 133580
 test-amd64-amd64-xl-credit1  12 guest-start  fail REGR. vs. 133580
 test-arm64-arm64-xl-credit1  12 guest-start  fail REGR. vs. 133580
 test-arm64-arm64-xl-credit2  12 guest-start  fail REGR. vs. 133580
 test-armhf-armhf-xl-multivcpu 12 guest-start fail REGR. vs. 133580
 test-armhf-armhf-xl-credit2  12 guest-start  fail REGR. vs. 133580
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
133580
 test-armhf-armhf-xl-credit1  12 guest-start  fail REGR. vs. 133580
 test-arm64-arm64-xl-xsm 16 guest-start/debian.repeat fail REGR. vs. 133580
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
133580
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 133580

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 12 guest-start  fail REGR. vs. 133580
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 133580

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-seattle 16 guest-start/debian.repeat fail baseline untested
 test-arm64-arm64-xl-thunderx 15 guest-stop  fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 133580
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 133580
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133580
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 133580
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580
 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  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linuxf8788d86ab28f61f7b46eb6be375f8a726

[Xen-devel] [xen-unstable-smoke test] 147633: tolerable all pass - PUSHED

[osstest service owner]

flight 147633 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147633/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  102b439f910e761bf92eed9fdf45d49bc6fba5d4
baseline version:
 xen  d90bcb5f10995c52d080274d66bfdc362b22598e

Last test of basis   147605  2020-02-25 20:01:10 Z0 days
Testing same since   147633  2020-02-26 10:00:47 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 
  Roger Pau Monné 
  Wei Xu 

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-amd64pass
 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
   d90bcb5f10..102b439f91  102b439f910e761bf92eed9fdf45d49bc6fba5d4 -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [qemu-mainline test] 147546: regressions - FAIL

[osstest service owner]

flight 147546 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147546/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386 14 guest-saverestore  fail REGR. vs. 144861
 test-amd64-i386-freebsd10-amd64 14 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 
144861
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 13 guest-saverestore fail REGR. 
vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 13 guest-saverestore fail REGR. 
vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 
144861
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail REGR. vs. 144861

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail  like 144861
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144861
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144861
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pa

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[Jan Beulich]

On 25.02.2020 10:53, Paul Durrant wrote:
> There's no particular reason shared_info need use a xenheap page. It's
> only purpose is to be mapped by the guest so use a PGC_extra domheap page
> instead.

Since the cover letter also doesn't give any background - is there a
problem with the current arrangements? Are there any further plans
depending on this being changed? Or is this simply "let's do it
because now we can"?

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context

[Roger Pau Monné]

On Wed, Feb 26, 2020 at 02:10:44PM +0100, Jan Beulich wrote:
> On 26.02.2020 13:38, Roger Pau Monne wrote:
> > Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception
> > context because it can nest, and hence send_IPI_mask could be
> > overwriting another user scratch cpumask data when used in such
> > contexts.
> > 
> > Instead introduce a new cpumask to be used by send_IPI_mask, and
> > disable interrupts while using it.
> 
> With this now apparently stale sentence dropped (easily done
> while committing)

Uh, I thought I fixed the commit message, but looks like I missed that
bit.

Thanks.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen: do live patching only from main idle loop

[Jürgen Groß]

On 24.02.20 23:25, Julien Grall wrote:

Hi Juergen,

On 11/02/2020 09:31, Juergen Gross wrote:

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6f9bec22d3..30c4c1830b 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -23,7 +23,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
@@ -2239,11 +2238,6 @@ static void check_for_pcpu_work(void)
  {
  local_irq_enable();
  do_softirq();
-    /*
- * Must be the last one - as the IPI will trigger us to come 
here

- * and we want to patch the hypervisor with almost no stack.
- */
-    check_for_livepatch_work();


The check here was meant to match the x86 counterpart in 
reset_stack_and_jump(). I suspect you also need to remove it.


Not really, as on x86 all relevant non-idle cases are being switched
to use reset_stack_and_jump_nolp().


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[Durrant, Paul]

> -Original Message-
> From: Jan Beulich 
> Sent: 26 February 2020 13:58
> To: Durrant, Paul 
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Julien Grall ; Volodymyr Babchuk
> ; Andrew Cooper ;
> George Dunlap ; Ian Jackson
> ; Konrad Rzeszutek Wilk
> ; Wei Liu 
> Subject: Re: [PATCH 2/2] domain: use PGC_extra domheap page for
> shared_info
> 
> On 25.02.2020 10:53, Paul Durrant wrote:
> > There's no particular reason shared_info need use a xenheap page. It's
> > only purpose is to be mapped by the guest so use a PGC_extra domheap
> page
> > instead.
> 
> Since the cover letter also doesn't give any background - is there a
> problem with the current arrangements? Are there any further plans
> depending on this being changed? Or is this simply "let's do it
> because now we can"?
> 

The general direction is to get rid of shared xenheap pages. Knowing that a 
xenheap page is not shared with a guest makes dealing with live update much 
easier, and also allows a chunk of code to be removed from 
domain_relinquish_resoureses() (the shared xenheap walk which de-assigns them 
from the dying guest).
The only xenheap pages shared with a normal domU (as opposed to a system 
domain, which would be re-created on live update anyway) are AFAICT shared-info 
and grant table/status frames. This series deals with shared-info but I do have 
proto-patches for the grant table code too.

  Paul
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[Julien Grall]

On 26/02/2020 12:03, Durrant, Paul wrote:

-Original Message-
From: Julien Grall 
Sent: 26 February 2020 11:33
To: Durrant, Paul ; xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ; Volodymyr Babchuk
; Andrew Cooper ;
George Dunlap ; Ian Jackson
; Jan Beulich ; Konrad
Rzeszutek Wilk ; Wei Liu 
Subject: Re: [PATCH 2/2] domain: use PGC_extra domheap page for
shared_info

Hi Paul,

On 25/02/2020 09:53, Paul Durrant wrote:

There's no particular reason shared_info need use a xenheap page.


AFAICT, a side-effect of this change is the shared_info is now going to
be part of the migration stream. One issue with this is on the restore
side, they will be accounted in number of pages allocated to the domain.

I am fairly certain dirty logging on page with PGC_extra set would not
work properly as well.


True, those two do need fixing before expanding the use of PGC_extra. I guess 
this may already be a problem with the current VMX use case.



As the pages will be recreated in the restore side, I would suggest to
skip them in XEN_DOMCTL_getpageframeinfo3.



At some point in future I guess it may be useful to migrate PGC_extra pages, 
but they would need to be marked as such in the stream. Skipping sounds like 
the right approach for now.


It's
only purpose is to be mapped by the guest so use a PGC_extra domheap

page

instead. This does entail freeing shared_info during
domain_relinquish_resources() rather than domain_destroy() so care is
needed to avoid de-referencing a NULL shared_info pointer hence some
extra checks of 'is_dying' are needed.
ASSERTions are added before apparently vulnerable dereferences in the
event channel code. These should not be hit because domain_kill() calls
evtchn_destroy() before calling domain_relinquish_resources() but are
added to catch any future re-ordering.


IHMO, the ASSERTions in the event channel pending/mask/... helpers will
not protect against re-ordering. You may never hit them even if there is
a re-ordering. It would be better to add an ASSERT()/BUG_ON() in
evtchn_destroy() and possibly a comment in domain_kill() to mention
ordering.


I'm not sure about that. Why would they not be hit?


A developper may never touch the event channels after during the domain 
destruction in debug build. So the re-ordering would become unnoticed.


This would become quite a problem if the production build end up to 
touch event channels during the domain destruction.







For Arm, the call to free_shared_info() in arch_domain_destroy() is left
in place since it called in the error path for arch_domain_create().

NOTE: A modification in p2m_alloc_table() is required to avoid a false
positive when checking for domain memory.
A fix is also needed in dom0_construct_pv() to avoid

automatically

adding PGC_extra pages to the physmap.


I am not entirely sure how this is related to this patch. Was it a
latent bug? If so, I think it would make sense to split it from this
patch.



It's related because the check relies on the fact that no PGC_extra pages are 
created before it is called. This is indeed true until this patch is applied.


I would prefer if they are fixed in separate patches as this pach 
already quite a lot. But I will leave that up to Andrew and Jan.




Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Volodymyr Babchuk 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Wei Liu 
---
   xen/arch/arm/domain.c|  2 ++
   xen/arch/x86/domain.c|  3 ++-
   xen/arch/x86/mm/p2m.c|  3 +--
   xen/arch/x86/pv/dom0_build.c |  4 
   xen/common/domain.c  | 25 +++--
   xen/common/event_2l.c|  4 
   xen/common/event_fifo.c  |  1 +
   xen/common/time.c|  3 +++
   8 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2cbcdaac08..3904519256 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1006,6 +1006,8 @@ int domain_relinquish_resources(struct domain *d)
   BUG();
   }

+free_shared_info(d);
+
   return 0;
   }

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index eb7b0fc51c..3ad532eccf 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -691,7 +691,6 @@ void arch_domain_destroy(struct domain *d)
   pv_domain_destroy(d);
   free_perdomain_mappings(d);

-free_shared_info(d);
   cleanup_domain_irq_mapping(d);

   psr_domain_free(d);
@@ -2246,6 +2245,8 @@ int domain_relinquish_resources(struct domain *d)
   if ( is_hvm_domain(d) )
   hvm_domain_relinquish_resources(d);

+free_shared_info(d);
+
   return 0;
   }

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c5f428d67c..787d97d85e 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -695,8 +695,7 @@ int p2m_alloc_table(struct p2m_domain *p2m)

  

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[Jan Beulich]

On 26.02.2020 15:22, Julien Grall wrote:
> On 26/02/2020 12:03, Durrant, Paul wrote:
>>> From: Julien Grall 
>>> Sent: 26 February 2020 11:33
>>>
>>> On 25/02/2020 09:53, Paul Durrant wrote:
 For Arm, the call to free_shared_info() in arch_domain_destroy() is left
 in place since it called in the error path for arch_domain_create().

 NOTE: A modification in p2m_alloc_table() is required to avoid a false
 positive when checking for domain memory.
 A fix is also needed in dom0_construct_pv() to avoid
>>> automatically
 adding PGC_extra pages to the physmap.
>>>
>>> I am not entirely sure how this is related to this patch. Was it a
>>> latent bug? If so, I think it would make sense to split it from this
>>> patch.
>>>
>>
>> It's related because the check relies on the fact that no PGC_extra pages 
>> are created before it is called. This is indeed true until this patch is 
>> applied.
> 
> I would prefer if they are fixed in separate patches as this pach 
> already quite a lot. But I will leave that up to Andrew and Jan.

I agree with Julien (if splitting is sensibly possible), fwiw.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v10 1/3] xen/mem_sharing: VM forking

[Roger Pau Monné]

On Tue, Feb 25, 2020 at 11:17:55AM -0800, Tamas K Lengyel wrote:
> VM forking is the process of creating a domain with an empty memory space and 
> a
> parent domain specified from which to populate the memory when necessary. For
> the new domain to be functional the VM state is copied over as part of the 
> fork
> operation (HVM params, hap allocation, etc).
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> v10: setup vcpu_info pages for vCPUs in the fork if the parent has them
>  setup pages for special HVM PFNs if the parent has them
>  minor adjustments based on Roger's comments
> ---
>  xen/arch/x86/domain.c |  11 ++
>  xen/arch/x86/hvm/hvm.c|   4 +-
>  xen/arch/x86/mm/hap/hap.c |   3 +-
>  xen/arch/x86/mm/mem_sharing.c | 287 ++
>  xen/arch/x86/mm/p2m.c |   9 +-
>  xen/common/domain.c   |   3 +
>  xen/include/asm-x86/hap.h |   1 +
>  xen/include/asm-x86/hvm/hvm.h |   2 +
>  xen/include/asm-x86/mem_sharing.h |  17 ++
>  xen/include/public/memory.h   |   5 +
>  xen/include/xen/sched.h   |   5 +
>  11 files changed, 342 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index fe63c23676..1ab0ca0942 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2203,6 +2203,17 @@ int domain_relinquish_resources(struct domain *d)
>  ret = relinquish_shared_pages(d);
>  if ( ret )
>  return ret;
> +
> +/*
> + * If the domain is forked, decrement the parent's pause count
> + * and release the domain.
> + */
> +if ( d->parent )
> +{
> +domain_unpause(d->parent);
> +put_domain(d->parent);
> +d->parent = NULL;
> +}
>  }
>  #endif
>  
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index a339b36a0d..c284f3cf5f 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1915,7 +1915,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
> long gla,
>  }
>  #endif
>  
> -/* Spurious fault? PoD and log-dirty also take this path. */
> +/* Spurious fault? PoD, log-dirty and VM forking also take this path. */
>  if ( p2m_is_ram(p2mt) )
>  {
>  rc = 1;
> @@ -4429,7 +4429,7 @@ static int hvm_allow_get_param(struct domain *d,
>  return rc;
>  }
>  
> -static int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value)
> +int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value)
>  {
>  int rc;
>  
> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> index 3d93f3451c..c7c7ff6e99 100644
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -321,8 +321,7 @@ static void hap_free_p2m_page(struct domain *d, struct 
> page_info *pg)
>  }
>  
>  /* Return the size of the pool, rounded up to the nearest MB */
> -static unsigned int
> -hap_get_allocation(struct domain *d)
> +unsigned int hap_get_allocation(struct domain *d)
>  {
>  unsigned int pg = d->arch.paging.hap.total_pages
>  + d->arch.paging.hap.p2m_pages;
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 3835bc928f..8ee37e6943 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -22,6 +22,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -36,6 +37,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  #include "mm-locks.h"
> @@ -1444,6 +1447,263 @@ static inline int mem_sharing_control(struct domain 
> *d, bool enable)
>  return 0;
>  }
>  
> +/*
> + * Forking a page only gets called when the VM faults due to no entry being
> + * in the EPT for the access. Depending on the type of access we either
> + * populate the physmap with a shared entry for read-only access or
> + * fork the page if its a write access.
> + *
> + * The client p2m is already locked so we only need to lock
> + * the parent's here.
> + */
> +int mem_sharing_fork_page(struct domain *d, gfn_t gfn, bool unsharing)
> +{
> +int rc = -ENOENT;
> +shr_handle_t handle;
> +struct domain *parent = d->parent;
> +struct p2m_domain *p2m;
> +unsigned long gfn_l = gfn_x(gfn);
> +mfn_t mfn, new_mfn;
> +p2m_type_t p2mt;
> +struct page_info *page;
> +
> +if ( !mem_sharing_is_fork(d) )
> +return -ENOENT;
> +
> +if ( !unsharing )
> +{
> +/* For read-only accesses we just add a shared entry to the physmap 
> */
> +while ( parent )
> +{
> +if ( !(rc = nominate_page(parent, gfn, 0, &handle)) )
> +break;
> +
> +parent = parent->parent;
> +}
> +
> +if ( !rc )
> +{
> +/* The client's p2m is already locked */
> +struct p2m_domain *pp2m = p2m

[Xen-devel] [PATCH 2/2] Linux/locking.sh: Use cmp-fd-file-inode for lock check

[Jason Andryuk]

Replace perl with cmp-fd-file-inode when checking that the lock file
descriptor and lockfile inodes match.

Signed-off-by: Jason Andryuk 
---
 tools/hotplug/Linux/locking.sh | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/tools/hotplug/Linux/locking.sh b/tools/hotplug/Linux/locking.sh
index c6a7e96ff9..de468c4bb5 100644
--- a/tools/hotplug/Linux/locking.sh
+++ b/tools/hotplug/Linux/locking.sh
@@ -50,14 +50,8 @@ claim_lock()
 # actually a synthetic symlink in /proc and we aren't
 # guaranteed that our stat(2) won't lose the race with an
 # rm(1) between reading the synthetic link and traversing the
-# file system to find the inum.  Perl is very fast so use that.
-rightfile=$( perl -e '
-open STDIN, "<&'$_lockfd'" or die $!;
-my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
-my $file_inum = (stat $ARGV[0])[1];
-print "y\n" if $fd_inum eq $file_inum;
- ' "$_lockfile" )
-if [ x$rightfile = xy ]; then break; fi
+# file system to find the inum.
+if cmp-fd-file-inode $_lockfd $_lockfile ; then break; fi
# Some versions of bash appear to be buggy if the same
# $_lockfile is opened repeatedly. Close the current fd here.
 eval "exec $_lockfd<&-"
-- 
2.24.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 0/2] Remove locking.sh dependency on perl

[Jason Andryuk]

Perl is a large dependency for locking.sh's single use of comparing a
file descriptor's and a file's inodes.  Many systems don't otherwise
require perl, so dropping this use eliminates the dependency.

Replace the open-coded perl with an equivalent C implementation.

Jason Andryuk (2):
  tools/helpers: Introduce cmp-fd-file-inode utility
  Linux/locking.sh: Use cmp-fd-file-inode for lock check

 .gitignore|  1 +
 tools/helpers/Makefile|  3 +++
 tools/helpers/cmp-fd-file-inode.c | 43 +++
 tools/hotplug/Linux/locking.sh| 10 ++-
 4 files changed, 49 insertions(+), 8 deletions(-)
 create mode 100644 tools/helpers/cmp-fd-file-inode.c

-- 
2.24.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/2] tools/helpers: Introduce cmp-fd-file-inode utility

[Jason Andryuk]

This is a C implementation of the perl code inside of locking.sh to
check that the locked file descriptor and lock file share the same inode
and therefore match.  One change from the perl version is replacing
printing "y" on success with exit values of 0 (shell True) and 1 (shell
False).

Requiring perl is a large dependency for the single use, so a dedicated
utility removes that dependency for systems that otherwise would not
install perl.

Signed-off-by: Jason Andryuk 
---
 .gitignore|  1 +
 tools/helpers/Makefile|  3 +++
 tools/helpers/cmp-fd-file-inode.c | 43 +++
 3 files changed, 47 insertions(+)
 create mode 100644 tools/helpers/cmp-fd-file-inode.c

diff --git a/.gitignore b/.gitignore
index 4ca679ddbc..897f878eef 100644
--- a/.gitignore
+++ b/.gitignore
@@ -164,6 +164,7 @@ tools/fuzz/x86_instruction_emulator/x86-emulate.[ch]
 tools/helpers/_paths.h
 tools/helpers/init-xenstore-domain
 tools/helpers/xen-init-dom0
+tools/helpers/cmp-fd-file-inode
 tools/hotplug/common/hotplugpath.sh
 tools/hotplug/FreeBSD/rc.d/xencommons
 tools/hotplug/FreeBSD/rc.d/xendriverdomain
diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
index f759528322..7daf5c46ca 100644
--- a/tools/helpers/Makefile
+++ b/tools/helpers/Makefile
@@ -8,6 +8,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 PROGS += xen-init-dom0
 ifeq ($(CONFIG_Linux),y)
 PROGS += init-xenstore-domain
+PROGS += cmp-fd-file-inode
 endif
 
 XEN_INIT_DOM0_OBJS = xen-init-dom0.o init-dom-json.o
@@ -40,12 +41,14 @@ install: all
$(INSTALL_PROG) xen-init-dom0 $(DESTDIR)$(LIBEXEC_BIN)
 ifeq ($(CONFIG_Linux),y)
$(INSTALL_PROG) init-xenstore-domain $(DESTDIR)$(LIBEXEC_BIN)
+   $(INSTALL_PROG) cmp-fd-file-inode $(DESTDIR)$(LIBEXEC_BIN)
 endif
 
 .PHONY: uninstall
 uninstall:
 ifeq ($(CONFIG_Linux),y)
rm -f $(DESTDIR)$(LIBEXEC_BIN)/init-xenstore-domain
+   rm -f $(DESTDIR)$(LIBEXEC_BIN)/cmp-fd-file-inode
 endif
rm -f $(DESTDIR)$(LIBEXEC_BIN)/xen-init-dom0
 
diff --git a/tools/helpers/cmp-fd-file-inode.c 
b/tools/helpers/cmp-fd-file-inode.c
new file mode 100644
index 00..886ea888ed
--- /dev/null
+++ b/tools/helpers/cmp-fd-file-inode.c
@@ -0,0 +1,43 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void usage(const char * prog)
+{
+fprintf(stderr,
+"%s  \n"
+"Checks that the open file descriptor (referenced by number) has the same\n"
+"inode as the filename.\n"
+"Returns 0 on match and 1 on non-match\n", prog);
+}
+
+int main(int argc, char *argv[])
+{
+struct stat fd_statbuf, file_statbuf;
+int ret;
+int fd;
+
+if (argc < 3) {
+usage(argv[0]);
+return 1;
+}
+
+fd = strtoul(argv[1], NULL, 0);
+
+ret = fstat(fd, &fd_statbuf);
+if (ret) {
+return 1;
+}
+
+ret = stat(argv[2], &file_statbuf);
+if (ret) {
+return 1;
+}
+
+if (fd_statbuf.st_ino == file_statbuf.st_ino)
+return 0;
+else
+return 1;
+}
-- 
2.24.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v10 1/3] xen/mem_sharing: VM forking

[Tamas K Lengyel]

> > +if ( (ret = cpupool_move_domain(cd, d->cpupool)) )
> > +return ret;
>
> You can join both ifs into a single one, since both return ret.

Sure.

> > +
> > +for ( i = 0; i < cd->max_vcpus; i++ )
> > +{
> > +mfn_t vcpu_info_mfn;
> > +
> > +if ( !d->vcpu[i] || cd->vcpu[i] )
> > +continue;
> > +
> > +if ( !vcpu_create(cd, i) )
> > +return -EINVAL;
> > +
> > +/*
> > + * Map in a page for the vcpu_info if the guest uses one to the 
> > exact
> > + * same spot.
> > + */
> > +vcpu_info_mfn = d->vcpu[i]->vcpu_info_mfn;
> > +if ( !mfn_eq(vcpu_info_mfn, INVALID_MFN) )
> > +{
> > +struct page_info *page;
> > +mfn_t new_mfn;
> > +gfn_t gfn = mfn_to_gfn(d, vcpu_info_mfn);
> > +unsigned long gfn_l = gfn_x(gfn);
> > +
> > +if ( !(page = alloc_domheap_page(cd, 0)) )
> > +return -ENOMEM;
> > +
> > +new_mfn = page_to_mfn(page);
> > +set_gpfn_from_mfn(mfn_x(new_mfn), gfn_l);
> > +
> > +if ( !(ret = p2m->set_entry(p2m, gfn, new_mfn, PAGE_ORDER_4K,
> > +p2m_ram_rw, p2m->default_access, 
> > -1)) )
> > +return ret;
> > +
> > +if ( !(ret = map_vcpu_info(cd->vcpu[i], gfn_l,
> > +   d->vcpu[i]->vcpu_info_offset)) )
> > +return ret;
>
> I think you also need to copy the contents from the parent into those
> vcpu_info areas, or else you might discard pending event channels
> contained in the evtchn_* fields? (and the masked channels if any).
>
> The runtime area should be handled in a similar way AFAICT (albeit
> there's no need to copy the parent's data in that case), see
> VCPUOP_register_runstate_memory_area.

Will do.


> > +static int populate_special_pages(struct domain *cd)
> > +{
> > +struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> > +static const unsigned int params[] =
> > +{
> > +HVM_PARAM_STORE_PFN,
> > +HVM_PARAM_IOREQ_PFN,
> > +HVM_PARAM_BUFIOREQ_PFN,
> > +HVM_PARAM_CONSOLE_PFN
> > +};
> > +unsigned int i;
> > +
> > +for ( i=0; i<4; i++ )
>
> Nit: can you please add some spaces around the operators?

Sure.

>
> > +{
> > +uint64_t value = 0;
> > +mfn_t new_mfn;
> > +struct page_info *page;
> > +
> > +if ( hvm_get_param(cd, params[i], &value) || !value )
> > +continue;
> > +
> > +if ( !(page = alloc_domheap_page(cd, 0)) )
> > +return -ENOMEM;
> > +
> > +new_mfn = page_to_mfn(page);
> > +set_gpfn_from_mfn(mfn_x(new_mfn), value);
> > +
> > +return p2m->set_entry(p2m, _gfn(value), new_mfn, PAGE_ORDER_4K,
> > +  p2m_ram_rw, p2m->default_access, -1);
>
> I think you also need to copy the contents from the parent page here.

The toolstack simply clears these pages during restore so I'm not sure
(see 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxc/xc_sr_restore_x86_hvm.c;h=3f78248f32fec239db77b0e483b0195211e6b974;hb=HEAD#l61).
I don't see why you would have to clear the pages first if they get
overwritten by saved versions later. Or these pages are expected to be
torn-down by the save/restore aware guests?

> > +static int fork(struct domain *d, struct domain *cd)
> > +{
> > +int rc = -EBUSY;
> > +
> > +if ( !cd->controller_pause_count )
> > +return rc;
> > +
> > +/*
> > + * We only want to get and pause the parent once, not each time this
> > + * operation is restarted due to preemption.
> > + */
> > +if ( !cd->parent_paused )
> > +{
> > +if ( !get_domain(d) )
> > +{
> > +ASSERT_UNREACHABLE();
> > +return -EBUSY;
> > +}
> > +
> > +domain_pause(d);
> > +cd->parent_paused = true;
> > +cd->max_pages = d->max_pages;
> > +cd->max_vcpus = d->max_vcpus;
> > +}
> > +
> > +/* this is preemptible so it's the first to get done */
> > +if ( (rc = fork_hap_allocation(cd, d)) )
> > +goto done;
> > +
> > +if ( (rc = bring_up_vcpus(cd, d)) )
> > +goto done;
> > +
> > +if ( (rc = hvm_copy_context_and_params(cd, d)) )
> > +goto done;
> > +
> > +if ( (rc = populate_special_pages(cd)) )
> > +goto done;
> > +
> > +fork_tsc(cd, d);
>
> I think you need to copy the contents of the shared info page from the
> parent into the child, or else you are discarding any pending event
> channels. You should also map such shared info page into the same gfn
> as the parent.
>

I'll look into it, thanks!

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

[Jan Beulich]

On 26.02.2020 15:05, Durrant, Paul wrote:
>> From: Jan Beulich 
>> Sent: 26 February 2020 13:58
>>
>> On 25.02.2020 10:53, Paul Durrant wrote:
>>> There's no particular reason shared_info need use a xenheap page. It's
>>> only purpose is to be mapped by the guest so use a PGC_extra domheap
>> page
>>> instead.
>>
>> Since the cover letter also doesn't give any background - is there a
>> problem with the current arrangements? Are there any further plans
>> depending on this being changed? Or is this simply "let's do it
>> because now we can"?
>>
> 
> The general direction is to get rid of shared xenheap pages. Knowing
> that a xenheap page is not shared with a guest makes dealing with
> live update much easier,

I may not be seeing enough of the overall picture, but it would seem
to me that the special treatment of shared Xen heap pages would then
be replaced by special treatment of PGC_extra ones.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v10 2/3] x86/mem_sharing: reset a fork

[Roger Pau Monné]

On Tue, Feb 25, 2020 at 11:17:56AM -0800, Tamas K Lengyel wrote:
> Implement hypercall that allows a fork to shed all memory that got allocated
> for it during its execution and re-load its vCPU context from the parent VM.
> This allows the forked VM to reset into the same state the parent VM is in a
> faster way then creating a new fork would be. Measurements show about a 2x
> speedup during normal fuzzing operations. Performance may vary depending how
> much memory got allocated for the forked VM. If it has been completely
> deduplicated from the parent VM then creating a new fork would likely be more
> performant.
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> v10: implemented hypercall continuation similar to the existing range_share op
> ---
>  xen/arch/x86/mm/mem_sharing.c | 126 +-
>  xen/include/public/memory.h   |   4 ++
>  2 files changed, 129 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 8ee37e6943..aa4358aae4 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1673,7 +1673,6 @@ static int fork(struct domain *d, struct domain *cd)
>  domain_pause(d);
>  cd->parent_paused = true;
>  cd->max_pages = d->max_pages;
> -cd->max_vcpus = d->max_vcpus;
>  }
>  
>  /* this is preemptible so it's the first to get done */
> @@ -1704,6 +1703,91 @@ static int fork(struct domain *d, struct domain *cd)
>  return rc;
>  }
>  
> +/*
> + * The fork reset operation is intended to be used on short-lived forks only.
> + */
> +static int fork_reset(struct domain *d, struct domain *cd,
> +  struct mem_sharing_op_fork_reset *fr)
> +{
> +int rc = 0;
> +struct p2m_domain* p2m = p2m_get_hostp2m(cd);
> +struct page_info *page, *tmp;
> +unsigned long list_position = 0, preempt_count = 0, start = fr->opaque;
> +
> +domain_pause(cd);
> +
> +page_list_for_each_safe(page, tmp, &cd->page_list)
> +{
> +p2m_type_t p2mt;
> +p2m_access_t p2ma;
> +gfn_t gfn;
> +mfn_t mfn;
> +bool shared = false;
> +
> +list_position++;
> +
> +/* Resume were we left of before preemption */
> +if ( start && list_position < start )
> +continue;
> +
> +mfn = page_to_mfn(page);
> +if ( mfn_valid(mfn) )
> +{
> +
> +gfn = mfn_to_gfn(cd, mfn);
> +mfn = __get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
> +0, NULL, false);
> +
> +if ( p2m_is_ram(p2mt) && !p2m_is_shared(p2mt) )
> +{
> +/* take an extra reference, must work for a shared page */
> +if( !get_page(page, cd) )
> +{
> +ASSERT_UNREACHABLE();
> +return -EINVAL;
> +}
> +
> +shared = true;
> +preempt_count += 0x10;
> +
> +/*
> + * Must succeed, it's a shared page that exists and
> + * thus its size is guaranteed to be 4k so we are not 
> splitting
> + * large pages.
> + */
> +rc = p2m->set_entry(p2m, gfn, INVALID_MFN, PAGE_ORDER_4K,
> +p2m_invalid, p2m_access_rwx, -1);
> +ASSERT(!rc);
> +
> +put_page_alloc_ref(page);
> +put_page(page);
> +}
> +}
> +
> +if ( !shared )
> +preempt_count++;
> +
> +/* Preempt every 2MiB (shared) or 32MiB (unshared) - arbitrary. */
> +if ( preempt_count >= 0x2000 )
> +{
> +if ( hypercall_preempt_check() )
> +{
> +rc = -ERESTART;
> +break;
> +}
> +preempt_count = 0;
> +}
> +}
> +
> +if ( rc )
> +fr->opaque = list_position;
> +else if ( !(rc = hvm_copy_context_and_params(cd, d)) )
> +fork_tsc(cd, d);

You also need to reset the contents of the special pages, the
vcpu_info pages and the shared_info page in order to match the state
the VM was in when forking.

PV timers should also be reset to parent's state AFAICT, or else you
will get spurious timer interrupts.

In fact you should check against the state of the parent, because the
fork might have changed the position of the shared info or any other
of those magic areas, and that should be reverted to the state they
are in the parent.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v10 2/3] x86/mem_sharing: reset a fork

[Tamas K Lengyel]

> You also need to reset the contents of the special pages, the
> vcpu_info pages and the shared_info page in order to match the state
> the VM was in when forking.

Ack.

>
> PV timers should also be reset to parent's state AFAICT, or else you
> will get spurious timer interrupts.

Could you point me to the right direction here for where the timers
are located in the codebase?

> In fact you should check against the state of the parent, because the
> fork might have changed the position of the shared info or any other
> of those magic areas, and that should be reverted to the state they
> are in the parent.

Makes sense.

Thanks,
Tamas

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v10 1/3] xen/mem_sharing: VM forking

[Roger Pau Monné]

On Wed, Feb 26, 2020 at 08:20:30AM -0700, Tamas K Lengyel wrote:
> > > +static int populate_special_pages(struct domain *cd)
> > > +{
> > > +struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> > > +static const unsigned int params[] =
> > > +{
> > > +HVM_PARAM_STORE_PFN,
> > > +HVM_PARAM_IOREQ_PFN,
> > > +HVM_PARAM_BUFIOREQ_PFN,
> > > +HVM_PARAM_CONSOLE_PFN
> > > +};
> > > +unsigned int i;
> > > +
> > > +for ( i=0; i<4; i++ )
> >
> > Nit: can you please add some spaces around the operators?
> 
> Sure.
> 
> >
> > > +{
> > > +uint64_t value = 0;
> > > +mfn_t new_mfn;
> > > +struct page_info *page;
> > > +
> > > +if ( hvm_get_param(cd, params[i], &value) || !value )
> > > +continue;
> > > +
> > > +if ( !(page = alloc_domheap_page(cd, 0)) )
> > > +return -ENOMEM;
> > > +
> > > +new_mfn = page_to_mfn(page);
> > > +set_gpfn_from_mfn(mfn_x(new_mfn), value);
> > > +
> > > +return p2m->set_entry(p2m, _gfn(value), new_mfn, PAGE_ORDER_4K,
> > > +  p2m_ram_rw, p2m->default_access, -1);
> >
> > I think you also need to copy the contents from the parent page here.
> 
> The toolstack simply clears these pages during restore so I'm not sure
> (see 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxc/xc_sr_restore_x86_hvm.c;h=3f78248f32fec239db77b0e483b0195211e6b974;hb=HEAD#l61).
> I don't see why you would have to clear the pages first if they get
> overwritten by saved versions later. Or these pages are expected to be
> torn-down by the save/restore aware guests?

Guests using those pages know they are torn down during suspend/resume
and expect to find a clean state when resuming. That's not the case with
forking however, as the guest is completely unaware of the fork
happening.

One thing I'm not sure of is whether the backends (xenstored,
xenconsoled) will cope with those pages being already populated on
guest creation.

AFAICT another issue is that xenstore watches are not copied over from
the parent, so any watches the parent might have set will not fire on
the child. That would require some kind of interaction with xenstored
in order to request a guest state to be copied over to another guest.

> > > +static int fork(struct domain *d, struct domain *cd)
> > > +{
> > > +int rc = -EBUSY;
> > > +
> > > +if ( !cd->controller_pause_count )
> > > +return rc;
> > > +
> > > +/*
> > > + * We only want to get and pause the parent once, not each time this
> > > + * operation is restarted due to preemption.
> > > + */
> > > +if ( !cd->parent_paused )
> > > +{
> > > +if ( !get_domain(d) )
> > > +{
> > > +ASSERT_UNREACHABLE();
> > > +return -EBUSY;
> > > +}
> > > +
> > > +domain_pause(d);
> > > +cd->parent_paused = true;
> > > +cd->max_pages = d->max_pages;
> > > +cd->max_vcpus = d->max_vcpus;
> > > +}
> > > +
> > > +/* this is preemptible so it's the first to get done */
> > > +if ( (rc = fork_hap_allocation(cd, d)) )
> > > +goto done;
> > > +
> > > +if ( (rc = bring_up_vcpus(cd, d)) )
> > > +goto done;
> > > +
> > > +if ( (rc = hvm_copy_context_and_params(cd, d)) )
> > > +goto done;
> > > +
> > > +if ( (rc = populate_special_pages(cd)) )
> > > +goto done;
> > > +
> > > +fork_tsc(cd, d);
> >
> > I think you need to copy the contents of the shared info page from the
> > parent into the child, or else you are discarding any pending event
> > channels. You should also map such shared info page into the same gfn
> > as the parent.
> >
> 
> I'll look into it, thanks!

Oh, and the PV timer state should also be copied over, so that PV
timer interrupts are not lost.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v10 2/3] x86/mem_sharing: reset a fork

[Roger Pau Monné]

On Wed, Feb 26, 2020 at 08:28:31AM -0700, Tamas K Lengyel wrote:
> > You also need to reset the contents of the special pages, the
> > vcpu_info pages and the shared_info page in order to match the state
> > the VM was in when forking.
> 
> Ack.
> 
> >
> > PV timers should also be reset to parent's state AFAICT, or else you
> > will get spurious timer interrupts.
> 
> Could you point me to the right direction here for where the timers
> are located in the codebase?

The code paths start at VCPUOP_set_periodic_timer,
VCPUOP_stop_periodic_timer, VCPUOP_set_singleshot_timer and
VCPUOP_stop_singleshot_timer. AFAICT it's mostly a matter of copying
the state and staring the timer if it was already active on the
parent.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel