Re: [Xen-devel] [RFC PATCH 35/68] vfs: Convert xenfs to use the new mount API

[Juergen Gross]

On 28/03/2019 00:44, David Howells wrote:
> Convert the xenfs filesystem to the new internal mount API as the old
> one will be obsoleted and removed.  This allows greater flexibility in
> communication of mount parameters between userspace, the VFS and the
> filesystem.
> 
> See Documentation/filesystems/mount_api.txt for more information.
> 
> Signed-off-by: David Howells 
> cc: Boris Ostrovsky 
> cc: Juergen Gross 
> cc: Stefano Stabellini 
> cc: xen-devel@lists.xenproject.org

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH RFC 44/49] xen: round up max vcpus to scheduling granularity

[Juergen Gross]

On 01/04/2019 11:47, Juergen Gross wrote:
> On 01/04/2019 10:50, Andrew Cooper wrote:
>> On 29/03/2019 15:09, Juergen Gross wrote:
>>> Make sure the number of vcpus is always a multiple of the scheduling
>>> granularity. Note that we don't support a scheduling granularity above
>>> one on ARM.
>>
>> I'm afraid that I don't think this is a clever move.  In turn, this
>> brings into question the approach to idle handling.
>>
>> Firstly, with a proposed socket granularity, this would be 128 on some
>> systems which exist today.  Furthermore, consider the case where
>> cpupool0 has a granularity of 1, and a second pool has a granularity of
>> 2.  A domain can be created with an odd number of vcpus and operate in
>> pool0 fine, but can't now be moved to pool1.
> 
> For now granularity is the same for all pools, but I plan to enhance
> that in future.
> 
> The answer to that problem might be either to allow for later addition
> of dummy vcpus (e.g. by sizing only the vcpu pointer array to the needed
> number), or to really disallow moving such a domain between pools.
> 
>> If at all possible, I think it would be better to try and reuse the idle
>> cpus for holes like this.  Seeing as you've been playing with this code
>> a lot, what is your assessment?
> 
> This would be rather complicated. I'd either need to switch vcpus
> dynamically in schedule items, or I'd need to special case the idle
> vcpus in _lots_ of places.

I have thought more about this and maybe I have found a way to make that
less intrusive as I thought in the beginning.

I'll give it a try...


Juergen

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

Re: [Xen-devel] [PATCH 0/4] More python fixes

[Wei Liu]

On Mon, Apr 01, 2019 at 08:36:44PM +, YOUNG, MICHAEL A. wrote:
> On Mon, 1 Apr 2019, Wei Liu wrote:
> 
> > Wei Liu (4):
> >  pygrub: fix message in grub parser
> >  pygrub/grub: always use integer for default entry
> >  pygrub: decode string in Python 3
> >  tools/ocaml: make python scripts 2 and 3 compatible
> >
> > tools/ocaml/libs/xentoollog/genlevels.py |  5 -
> > tools/ocaml/libs/xl/genwrap.py   | 17 ++---
> > tools/pygrub/src/GrubConf.py |  8 ++--
> > tools/pygrub/src/pygrub  |  5 -
> > 4 files changed, 24 insertions(+), 11 deletions(-)
> 
> There is a bit missing compared to my original patch which is to convert 
> the string back to bytes for the final write out and avoid the error
> 
> Traceback (most recent call last):
>File "/tmp/xencode/usr/libexec/xen/bin/pygrub", line 967, in 
>  os.write(fd, ostring)
> TypeError: a bytes-like object is required, not 'str'
> 
> The attached patch works for me in a quick test on python3 though I 
> haven't tested it on python2 yet.
> 
>   Michael Young

> --- xen-4.12.0/tools/pygrub/src/pygrub.orig   2019-04-01 21:25:33.206405995 
> +0100
> +++ xen-4.12.0/tools/pygrub/src/pygrub2019-04-01 21:27:36.179929105 
> +0100
> @@ -963,5 +963,8 @@
>  ostring = format_simple(bootcfg["kernel"], bootcfg["ramdisk"], args, 
> "\0")
>  
>  sys.stdout.flush()
> -os.write(fd, ostring)
> +if sys.version_info[0] < 3:
> +os.write(fd, ostring)
> +else:
> +os.write(fd, ostring.encode())
>  


This should work. I will fold this in to the pygrub patch.

Thanks for spotting my mistake.

Wei.

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

[Xen-devel] [xen-unstable-smoke test] 134278: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  905d7340f6d0abfbf986cede6e535c51ab1de3c3
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   10 days
Failing since134068  2019-03-25 12:00:51 Z7 days   33 attempts
Testing same since   134272  2019-04-01 17:02:56 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit 905d7340f6d0abfbf986cede6e535c51ab1de3c3
Author: Andrew Cooper 
Date:   Mon Apr 1 10:08:43 2019 +

xen/sched: Remove d->is_pinned

The is_pinned field is rather odd.  It can only be activated with the
"dom0_vcpus_pin" command line option, and causes dom0 (or the late hwdom) to
have its vcpus identity pinned to pcpus.

Having dom0_vcpus_pin active disallows the use of vcpu_set_hard_affinity().
However, when a pcpu is offlined, or moved between cpupools, the affinity is
broken and reverts to cpumask_all.  This results in vcpus which are no 
longer
pinned, and cannot be adjusted.

A related bit of functionality is the is_pinned_vcpu() predicate.  This is
only used by x86 code, and permits the use of VCPUOP_get_physid and 
writeable
access to some extra MSRs.

The implementation however returns true for is_pinned (which will include
unpinned vcpus from the above scenario), *or* if the hard affinity mask only
has a single bit set (which is redundant with the intended effect of
is_pinned, but also includes other domains).

Rework the behaviour of "dom0_vcpus_pin" to only being an initial pinning
configuration, and permit full adjustment.  This allows the user to
reconfigure dom0 after the fact or fix up from the fallout of cpu hot unplug
and cpupool manipulation.

An unprivileged domain has no business using VCPUOP_get_physid, and 
shouldn't
be able to just because it happens to be pinned by admin choice.  All uses 
of
is_pinned_vcpu() should be restricted to the hardware domain, so rename it 
to
is_hwdom_pinned_vcpu() to avoid future misuse.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Reviewed-by: Dario Faggioli 

commit d96a4d6c9cb57bdc46501880c908ae85197243da
Author: Wei Liu 
Date:   Mon Apr 1 11:39:00 2019 +0100

tools/xenmon: make xenmon.py compatible with python 2 and 3

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit c37db16ccb3426e2d22ec7731649770b56984b27
Author: Jan Beulich 
Date:   Mon Apr 1 11:12:54 2019 +0200

x86/APIC: suppress redundant "Switched to ..." messages

There's no need to log anything when what we "switch to" is what is in
use already.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit f68f35fd2016e36ee30f8b3e7dfd46c554407ac1
Author: J

[Xen-devel] [linux-linus test] 134259: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64   4 host-install(4)broken REGR. vs. 133580
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 133580
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 133580
 test-armhf-armhf-xl   6 xen-install  fail REGR. vs. 133580

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail like 133580
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 133580
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133580
 test-amd64-amd64-xl-qemuu-win7-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-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail 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-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-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
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux79a3aaa7b82e3106be97842dedfd8429248896e6
baseline version:
 linux736706bee3298208343a76096370e4f6a5c55915

Last test of basis   133580  2019-03-04 19:53:09 Z   28 days
Failing since133605  2019-03-05 20:03:14 Z   27 days   17 attempts
Testing same since   134259  2019-04-01 09:51:05 Z0 days1 attempts

--

Re: [Xen-devel] [PATCH v3 1/6] xen/sched: call cpu_disable_scheduler() via cpu notifier

[Julien Grall]

Hi,

On 02/04/2019 06:34, Juergen Gross wrote:

cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the cpu notifier chain. Moving the call out of
stop_machine() context is fine, as we just need to hold the domain RCU
lock and need the scheduler percpu data to be still allocated.

Add another hook for CPU_DOWN_PREPARE to bail out early in case
cpu_disable_scheduler() would fail. This will avoid crashes in rare
cases for cpu hotplug or suspend.

Signed-off-by: Juergen Gross 
Reviewed-by: Dario Faggioli 


For the Arm bits:

Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/3] xen/arm: Add Amlogic Meson SoCs earlyprintk support

[Julien Grall]

Hi,

You don't have a cover letter, so I will comment here. I will leave Andre 
reviewing the patch series.


In the future, please include a cover letter if you send more than one patch 
together.


On 21/03/2019 10:25, Amit Singh Tomar wrote:

As I pointed out on v2, you are missing the commit message. Please read what I 
wrote in v2 to know what you need to write here.



Signed-off-by: Amit Singh Tomar 


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 7/7] x86/IOMMU: initialize iommu_ops in vendor-independent code

[Andrew Cooper]

On 29/03/2019 09:15, Jan Beulich wrote:
 On 28.03.19 at 18:50,  wrote:
>> On 28/03/2019 14:54, Jan Beulich wrote:
>>> --- a/xen/drivers/passthrough/x86/iommu.c
>>> +++ b/xen/drivers/passthrough/x86/iommu.c
>>> @@ -26,6 +26,19 @@
>>>  const struct iommu_init_ops *__initdata iommu_init_ops;
>>>  struct iommu_ops __read_mostly iommu_ops;
>>>  
>>> +int __init iommu_hardware_setup(void)
>>> +{
>>> +if ( !iommu_init_ops )
>>> +return -ENODEV;
>>> +
>>> +if ( !iommu_ops.init )
>>> +iommu_ops = *iommu_init_ops->ops;
>>> +else
>>> +ASSERT(iommu_ops.init == iommu_init_ops->ops->init);
>> What is this ASSERT() intended to catch?  We pass through this function
>> exactly once, making the else path dead.
> iommu_ops may have got set already during x2APIC IR enabling (see
> patch 6).

In which case a

/* x2apic setup may have previously initialised the IOMMU ops. */

or similar would do nicely, to explain this logic.

With that, Reviewed-by: Andrew Cooper 

~Andrew

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

Re: [Xen-devel] [PATCH 6/7] x86/IOMMU: abstract Intel-specific iommu_{en, dis}able_x2apic_IR()

[Andrew Cooper]

On 02/04/2019 04:24, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, March 29, 2019 5:13 PM
>>
> On 28.03.19 at 18:37,  wrote:
>>> On 28/03/2019 14:53, Jan Beulich wrote:
 @@ -35,6 +35,8 @@ void print_vtd_entries(struct iommu *iom
  keyhandler_fn_t vtd_dump_iommu_info;

  bool intel_iommu_supports_eim(void);
 +int intel_iommu_enable_x2apic_IR(void);
 +void intel_iommu_disable_x2apic_IR(void);
>>> Is there any particular reason why these retain their _IR suffix?
>> Well, I've too been thinking about the naming here. I decided to
>> keep the _IR suffixes because that's what the functions really
>> do: They enable/disable interrupt remapping for x2APIC mode.
>> They don't enable x2APIC itself in any way, and iirc x2APIC
>> mode could be used (without wider APIC IDs and in physical
>> mode) even without any IR enabled.
>>
>>> I'd suggest going with intel_iommu_{en,dis}able_eim() to match the
>>> supports name here, whereas...
>>>
 --- a/xen/drivers/passthrough/vtd/iommu.c
 +++ b/xen/drivers/passthrough/vtd/iommu.c
 @@ -2720,6 +2720,8 @@ const struct iommu_ops __initconstrel in
  .free_page_table = iommu_free_page_table,
  .reassign_device = reassign_device_ownership,
  .get_device_group_id = intel_iommu_group_id,
 +.enable_x2apic_IR = intel_iommu_enable_x2apic_IR,
 +.disable_x2apic_IR = intel_iommu_disable_x2apic_IR,
  .update_ire_from_apic = io_apic_write_remap_rte,
  .update_ire_from_msi = msi_msg_write_remap_rte,
  .read_apic_from_ire = io_apic_read_remap_rte,
 @@ -2736,6 +2738,7 @@ const struct iommu_ops __initconstrel in
  };

  const struct iommu_init_ops __initconstrel intel_iommu_init_ops = {
 +.ops = &intel_iommu_ops,
  .setup = vtd_setup,
  .supports_x2apic = intel_iommu_supports_eim,
  };
 --- a/xen/drivers/passthrough/x86/iommu.c
 +++ b/xen/drivers/passthrough/x86/iommu.c
 @@ -26,6 +26,24 @@
  const struct iommu_init_ops *__initdata iommu_init_ops;
  struct iommu_ops __read_mostly iommu_ops;

 +int iommu_enable_x2apic_IR(void)
>>> ... using iommu_{en,dis}able_x2apic() here to match the
>>> supports_x2apic() init hook.
>>>
>>>
>>> I don't think these shorter names are any more ambiguous, and loosing
>>> the _IR suffix does make them more consistent with the rest of Xen's
>>> function naming conventions.
>> The above said, in the end I'm not overly fussed, but before deciding
>> which route to go I'll wait to see whether in particular Kevin has an
>> opinion either way.
>>
> let's remove _IR. we have intel_iommu prefix which is sufficient
> to indicate enable_x2apic in iommu context is about IR.
>
> since renaming is small thing, here is my:
>
>   Reviewed-by: Kevin Tian 

No point posting this series a second time just for the rename.  With
the suggested adjustments, Reviewed-by: Andrew Cooper


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

Re: [Xen-devel] [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Jan Beulich]

>>> On 02.04.19 at 08:46,  wrote:
> On 2019/4/1 16:41, Jan Beulich wrote:
>> On 30.03.19 at 11:42,  wrote:
>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
>> 
>> I think it would have been nice if you had mentioned the real
>> reason why you want to bypass the MSR accesses. This way it
>> sounds as if the change was only cosmetic, and hence could be
>> left out.
> 
> Okay, how about the new description:
> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
> this MSR will stop the Xen initialization process

"... for some early Hygon steppings"(?). I'm unaware of AMD CPUs
having this issue - are you telling us otherwise?

Jan

> or produce GPF(0).
> So directly return false in the function probe_cpuid_faulting() if
> !cpu_has_hypervisor.
> 
> -- 
> Regards,
> Pu Wen





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

Re: [Xen-devel] [PATCH v4 04/15] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Jan Beulich]

>>> On 02.04.19 at 08:46,  wrote:
> On 2019/4/1 16:36, Jan Beulich wrote:
>> On 30.03.19 at 11:42,  wrote:
>>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>>> @@ -538,28 +538,12 @@ int svm_vpmu_initialise(struct vcpu *v)
>>>   return 0;
>>>   }
>>>   
>>> -int __init amd_vpmu_init(void)
>>> +static int common_init(void)
>> 
>> __init
> 
> Okay, will add it in front of int.

Why in front of int? The old line of code here shows the canonical
ordering we use.

Jan



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

Re: [Xen-devel] [PATCH 3/3] memory: restrict XENMEM_remove_from_physmap to translated guests

[Julien Grall]

Hi Jan,

Sorry I was meant to answer to this earlier on.

On 05/03/2019 13:28, Jan Beulich wrote:

The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
originally introduced it (d818f3cb7c ["hvm: Use main memory for video
memory"]) and the one then purging it again (78c3097e4f ["Remove unused
XENMEM_remove_from_physmap"]) make clear that this operation is intended
for use on HVM (i.e. translated) guests only. Restrict it at least as
much, because for PV guests documentation (in the public header) does
not even match the implementation: It talks about GPFN as input, but
get_page_from_gfn() assumes a GMFN in the non-translated case (and hands
back the value passed in).

Also lift the check in XENMEM_add_to_physmap{,_batch} handling up
directly into top level hypercall handling, and clarify things in the
public header accordingly.

Take the liberty and also replace a pointless use of "current" with a
more efficient use of an existing local variable (or function parameter
to be precise).

Signed-off-by: Jan Beulich 
---
TBD: It could be further restricted, disallowing its use by a HVM guest
  on itself.


By HVM guest, do you refer to any auto-translated guest?

The interface XENME_remove_from_physmap is used by Arm to remove foreign 
mappings from its p2m. There are potentially other space with similar case (e.g 
grant-table...).



TBD: Is using P2M_ALLOC here really appropriate? It means e.g.
  pointlessly populating a PoD slot just to unpopulate it again right
  away, with the page then free floating, i.e. no longer available
  for use to replace another PoD slot, and (afaict) no longer
  accessible by the guest in any way.
TBD: Is using guest_physmap_remove_page() here really appropriate? It
  means that e.g. MMIO pages wouldn't be removed. Going through
  guest_remove_page() (while skipping the de-allocation step) would
  seem more appropriate to me, which would address the P2M_ALLOC
  aspect above as well.


How is that an issue? Does XENMEM_add_to_physmap allows you to map MMIO pages?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Andrew Cooper]

On 01/04/2019 09:40, Jan Beulich wrote:
 On 30.03.19 at 11:42,  wrote:
>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
> I think it would have been nice if you had mentioned the real
> reason why you want to bypass the MSR accesses. This way it
> sounds as if the change was only cosmetic, and hence could be
> left out.
>
>> Signed-off-by: Pu Wen 
> Acked-by: Jan Beulich 
>
> Andrew, I'd like to ask for explicit clarification that you don't object
> to this adjustment. But if you do, please clarify why.

We deliberately emulate MSR_INTEL_PLATFORM_INFO on all systems

This is to support pv-shim, so the L1 Xen can exert faulting control
over the L2 PV guest, so L2 doesn't see L1's HVM CPUID leaves and choke.

I suppose its fine to have a !cpu_has_hypervisor exclusion for non-Intel
systems, but I also don't see much value in it.

~Andrew

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

[Xen-devel] [linux-4.14 test] 134216: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133923
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 133923
 build-arm64   4 host-install(4)broken REGR. vs. 133923
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 133923

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-install  fail in 134118 pass in 134216
 test-amd64-amd64-examine4 memdisk-try-append fail in 134118 pass in 134216
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail pass in 134118

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux1848c32fad1666bdc04d40f857284ffcb55f694a
baseline version:
 linux5726a8d0f1958af80ad8e514bc2c18d213e739b7

Last test of basis   133923  2019-03-19 12:41:11 Z   13 days
Failing since134016  2019-03-23 13:42:45 Z  

Re: [Xen-devel] [PATCH] xen/timers: Fix memory leak with cpu hot unplug

[Jan Beulich]

>>> On 01.04.19 at 18:59,  wrote:
> On 01/04/2019 09:27, Jan Beulich wrote:
> On 29.03.19 at 17:57,  wrote:
>>> --- a/xen/common/timer.c
>>> +++ b/xen/common/timer.c
>>> @@ -631,6 +631,10 @@ static int cpu_callback(
>>>  case CPU_UP_CANCELED:
>>>  case CPU_DEAD:
>>>  migrate_timers_from_cpu(cpu);
>>> +ASSERT(heap_metadata(ts->heap)->size == 0);
>>> +if ( heap_metadata(ts->heap)->limit )
>>> +xfree(ts->heap);
>>> +ts->heap = dummy_heap;
>>>  break;
>> I think it would be worthwhile to add a comment to clarify that
>> the updating of per-CPU data here is not entirely pointless,
>> despite the zeroing done when bringing a CPU back up.
> 
> What kind of comment do you think would be useful here? 
> 
> ts->heap obviously shouldn’t be left as a wild pointer, and I don't see
> why this point is worthy of comment.

Oh, I wasn't suggesting to comment the freeing. It's the storing
of dummy_heap's address which might look unnecessary when
being aware of the clearing of per-CPU data.

>> Additionally - is this really the right thing to do uniformly during
>> CPU_UP_CANCELED / CPU_DEAD? Shouldn't this be done
>> conditionally upon park_offline_cpus there, and get done for
>> CPU_REMOVE in the opposite case (like we do elsewhere, in
>> particular in cpu_percpu_callback() itself)?
> 
> Its certainly the safest course of action, and obviously needs to follow
> migrate_timers_from_cpu()
> 
> Do parked CPUs actually get entered into the online map?  It appears so.

No, they don't: It's a full cpu_down() they go through. That's
why the new CPU_REMOVE notification was introduced, for
handlers to be able to free per-CPU data at the appropriate
point in time.

> Either way, the actual semantics of park_offline_cpus are undocumented,
> and if the intended semantics are to use that bifurcated logic
> everywhere, then I think the semantics want rethinking.

Well, I don't mind finding a different, perhaps easier to use
model. Back then, when introducing parking, I couldn't think
of one.

Jan


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

Re: [Xen-devel] [PATCH] x86/msr: Fix handling of MSR_AMD_PATCHLEVEL/MSR_IA32_UCODE_REV

[Jan Beulich]

>>> On 01.04.19 at 17:35,  wrote:
> On 01/04/2019 15:55, Jan Beulich wrote:
>>
>>>  Secondly, when a guest executes CPUID, this doesn't
>>> typically result in Xen executing a CPUID instruction in practice.
>> Wait - this is true for DomU, but used to be false for (PV) Dom0,
>> until you've switched over from pv_cpuid() to guest_cpuid(). I
>> would assume it was an unintended side effect to, this way,
>> eliminate the actual CPUID access from the special ucode rev
>> reading sequence Dom0 may perform.
> 
> It certainly was an unintended side effect of the cpuid_policy work.  In
> practice, dom0 still doesn't have faulting activated (due to the domain
> builder not having switched to DOMCTL_set_cpu_policy yet), so can still
> execute real CPUID instructions.

Provided it doesn't use the forced-#UD prefix, which I don't think
the Dom0 kernel would make any effort to bypass in this special
case.

> This is not going to stay true for very much longer.

Right.

>> As to DomU, I severely doubt it's a good idea to expose the
>> ucode revision to a guest, at least as long as the guest can be
>> migrated. But yes, we can leave avoiding to do so to the guest
>> itself: We won't mislead it any worse by handing it the real
>> revision than we would by handing it some synthetized one (e.g.
>> constant 0).
> 
> All guests in practice read the current microcode version.

Not really, no. In our XenoLinux forward port I had specifically
suppressed it, for being an undue operation to do by a PV
domain.

>  As it is
> model specific, we can't #GP on read, and faking up 0 is the only other
> option.
> 
> Furthermore, the speculative sidechannels mean that guests in practice
> do need to consult the microcode version for cases where MSR_ARCH_CAPS
> isn't provided.  On Broadwell at least, it is a non-optional part of
> evaluating the safety of retpoline.

But any decisions derived from this information are of limited
applicability.

>>> This patch texturally (but not functionally) interacts with "xen/sched: 
>>> Remove
>>> d->is_pinned" but rebasing either is easy.  It would also be best applied 
>>> with
>>> Sergey's "x86/microcode: always collect_cpu_info() during boot".
>> Well, "best" is probably an understatement, as you'd supply
>> stale data if we never came through that code. So I'd call it a
>> strict prereq.
> 
> Hmm - I've missed part of the explanation.
> 
> a) This behaviour is what happens currently for HVM guests.
> 
> b) In practice, it is only the very original P6 with no microcode which
> may have a fully read/write MSR here without anything to update the
> version.  AFACIT, for all CPUs which Xen will boot on, all that matters
> is that a CPUID instruction has been executed previously, which is
> covered by the AP boot path.
> 
> i.e. I think the logic would be more consistent to follow if this patch
> was behind Sergey's, but there is no functional dependency.

Ah, yes, good point.

Jan



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

[Xen-devel] [xen-4.12-testing test] 134262: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 134262 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134262/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64  broken
 build-arm64   4 host-install(4)broken REGR. vs. 133989
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133989
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 133989
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
133989

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   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-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  18f6fb990c30dcb1a4ae87ed8db10f635afda0fc
baseline version:
 xen  07c181c83e03a860d806305369cd677c24df9b78

Last test of basis   133989  2019-03-22 13:07:13 Z   10 days
Testing same since   134262  2019-04-01 11:36:55 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

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

Re: [Xen-devel] [PATCH v3 1/6] xen/sched: call cpu_disable_scheduler() via cpu notifier

[Jan Beulich]

>>> On 02.04.19 at 07:34,  wrote:
> cpu_disable_scheduler() is being called from __cpu_disable() today.
> There is no need to execute it on the cpu just being disabled, so use
> the CPU_DEAD case of the cpu notifier chain. Moving the call out of
> stop_machine() context is fine, as we just need to hold the domain RCU
> lock and need the scheduler percpu data to be still allocated.
> 
> Add another hook for CPU_DOWN_PREPARE to bail out early in case
> cpu_disable_scheduler() would fail. This will avoid crashes in rare
> cases for cpu hotplug or suspend.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Dario Faggioli 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v3 2/6] xen: add helper for calling notifier_call_chain() to common/cpu.c

[Jan Beulich]

>>> On 02.04.19 at 07:34,  wrote:
> Add a helper cpu_notifier_call_chain() to call notifier_call_chain()
> for a cpu with a specified action, returning an errno value.
> 
> This avoids coding the same pattern multiple times.
> 
> While at it avoid side effects from using BUG_ON() by not using
> cpu_online(cpu) as a parameter.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Dario Faggioli 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v3 4/6] xen: don't free percpu areas during suspend

[Jan Beulich]

>>> On 02.04.19 at 07:34,  wrote:
> Instead of freeing percpu areas during suspend and allocating them
> again when resuming keep them. Only free an area in case a cpu didn't
> come up again when resuming.
> 
> It should be noted that there is a potential change in behaviour as
> the percpu areas are no longer zeroed out during suspend/resume. While
> I have checked the called cpu notifier hooks to cope with that there
> might be some well hidden dependency on the previous behaviour. OTOH
> a component not registering itself for cpu down/up and expecting to
> see a zeroed percpu variable after suspend/resume is kind of broken
> already. And the opposite case, where a component is not registered
> to be called for cpu down/up and is not expecting a percpu variable
> suddenly to be zero due to suspend/resume is much more probable,
> especially as the suspend/resume functionality seems not to be tested
> that often.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Dario Faggioli 

Acked-by: Jan Beulich 

Wasn't there a request though to do the same on Arm? Even if
right now Arm doesn't support suspend/resume out of the box,
I think it would be better if such relatively generic adjustments
were done in lock step.

Jan



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

Re: [Xen-devel] [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Pu Wen]

On 2019/4/2 18:20, Jan Beulich wrote:

On 02.04.19 at 08:46,  wrote:

On 2019/4/1 16:41, Jan Beulich wrote:

On 30.03.19 at 11:42,  wrote:

There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.


I think it would have been nice if you had mentioned the real
reason why you want to bypass the MSR accesses. This way it
sounds as if the change was only cosmetic, and hence could be
left out.


Okay, how about the new description:
There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
this MSR will stop the Xen initialization process


"... for some early Hygon steppings"(?). I'm unaware of AMD CPUs


Yes,for some early Hygon steppings.


having this issue - are you telling us otherwise?


I tested with an AMD CPU(Family 17h, Model 1, Stepping 1) today, and
it also stopped when reading the MSR_INTEL_PLATFORM_INFO instead of
producing #GP(0).

--
Regards,
Pu Wen


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

Re: [Xen-devel] [PATCH v4 04/15] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Pu Wen]

On 2019/4/2 18:21, Jan Beulich wrote:
> On 02.04.19 at 08:46,  wrote:
>> On 2019/4/1 16:36, Jan Beulich wrote:
>>> On 30.03.19 at 11:42,  wrote:
 --- a/xen/arch/x86/cpu/vpmu_amd.c
 +++ b/xen/arch/x86/cpu/vpmu_amd.c
 @@ -538,28 +538,12 @@ int svm_vpmu_initialise(struct vcpu *v)
return 0;
}

 -int __init amd_vpmu_init(void)
 +static int common_init(void)
>>>
>>> __init
>>
>> Okay, will add it in front of int.
> 
> Why in front of int? The old line of code here shows the canonical
> ordering we use.

Sorry, after int. :)

By the way, how about the patch 01/15 of this series?
If it's fine, could you please offer Acked-by tag for it?

-- 
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v4 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Andrew Cooper]

On 30/03/2019 10:42, Pu Wen wrote:
> +static const struct cpu_dev hygon_cpu_dev = {
> + .c_vendor   = "Hygon",
> + .c_ident= { "HygonGenuine" },
> + .c_early_init   = early_init_amd,
> + .c_init = init_hygon,
> +};
> +
> +int __init hygon_init_cpu(void)
> +{
> + cpu_devs[X86_VENDOR_HYGON] = &hygon_cpu_dev;
> + return 0;
> +}
> diff --git a/xen/include/asm-x86/x86-vendors.h 
> b/xen/include/asm-x86/x86-vendors.h
> index 38a81c3..fa1cbb4 100644
> --- a/xen/include/asm-x86/x86-vendors.h
> +++ b/xen/include/asm-x86/x86-vendors.h
> @@ -9,6 +9,7 @@
>  #define X86_VENDOR_AMD 2
>  #define X86_VENDOR_CENTAUR 3
>  #define X86_VENDOR_SHANGHAI 4
> -#define X86_VENDOR_NUM 5
> +#define X86_VENDOR_HYGON 5
> +#define X86_VENDOR_NUM 6

This change will need rebasing over
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e72309ffbe7c4e507649c74749f130cda691131c
, which has dropped the .c_ident field for a more efficient lookup
mechanism.

Hopefully the adjustments are all obvious.  If not, I can draft a patch.

~Andrew

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

Re: [Xen-devel] [PATCH v3 4/6] xen: don't free percpu areas during suspend

[Juergen Gross]

On 02/04/2019 13:57, Jan Beulich wrote:
 On 02.04.19 at 07:34,  wrote:
>> Instead of freeing percpu areas during suspend and allocating them
>> again when resuming keep them. Only free an area in case a cpu didn't
>> come up again when resuming.
>>
>> It should be noted that there is a potential change in behaviour as
>> the percpu areas are no longer zeroed out during suspend/resume. While
>> I have checked the called cpu notifier hooks to cope with that there
>> might be some well hidden dependency on the previous behaviour. OTOH
>> a component not registering itself for cpu down/up and expecting to
>> see a zeroed percpu variable after suspend/resume is kind of broken
>> already. And the opposite case, where a component is not registered
>> to be called for cpu down/up and is not expecting a percpu variable
>> suddenly to be zero due to suspend/resume is much more probable,
>> especially as the suspend/resume functionality seems not to be tested
>> that often.
>>
>> Signed-off-by: Juergen Gross 
>> Reviewed-by: Dario Faggioli 
> 
> Acked-by: Jan Beulich 
> 
> Wasn't there a request though to do the same on Arm? Even if
> right now Arm doesn't support suspend/resume out of the box,
> I think it would be better if such relatively generic adjustments
> were done in lock step.

Julien asked to include that in the ARM suspend/resume series.


Juergen


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

[Xen-devel] [PATCH] x86/IO-APIC: consolidate / complete #define-s

[Jan Beulich]

Drop redundant ones from apic.h. Add delivery mode mask. Use them in
place of open coded hex numbers.

Take the opportunity and modify a helper function's parameters to be
just unsigned int. Also drop the bogus double underscore from its name,
as it and all its callers get touched anyway.

No functional change.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -410,7 +410,8 @@ void free_ioapic_entries(struct IO_APIC_
 xfree(ioapic_entries);
 }
 
-static void __modify_IO_APIC_irq (unsigned int irq, unsigned long enable, 
unsigned long disable)
+static void modify_IO_APIC_irq(unsigned int irq, unsigned int enable,
+   unsigned int disable)
 {
 struct irq_pin_list *entry = irq_2_pin + irq;
 unsigned int pin, reg;
@@ -432,25 +433,25 @@ static void __modify_IO_APIC_irq (unsign
 /* mask = 1 */
 static void __mask_IO_APIC_irq (unsigned int irq)
 {
-__modify_IO_APIC_irq(irq, 0x0001, 0);
+modify_IO_APIC_irq(irq, IO_APIC_REDIR_MASKED, 0);
 }
 
 /* mask = 0 */
 static void __unmask_IO_APIC_irq (unsigned int irq)
 {
-__modify_IO_APIC_irq(irq, 0, 0x0001);
+modify_IO_APIC_irq(irq, 0, IO_APIC_REDIR_MASKED);
 }
 
 /* trigger = 0 */
 static void __edge_IO_APIC_irq (unsigned int irq)
 {
-__modify_IO_APIC_irq(irq, 0, 0x8000);
+modify_IO_APIC_irq(irq, 0, IO_APIC_REDIR_LEVEL_TRIGGER);
 }
 
 /* trigger = 1 */
 static void __level_IO_APIC_irq (unsigned int irq)
 {
-__modify_IO_APIC_irq(irq, 0x8000, 0);
+modify_IO_APIC_irq(irq, IO_APIC_REDIR_LEVEL_TRIGGER, 0);
 }
 
 static void mask_IO_APIC_irq(struct irq_desc *desc)
@@ -571,7 +572,7 @@ set_ioapic_affinity_irq(struct irq_desc
 io_apic_write(entry->apic, 0x10 + 1 + pin*2, dest);
 data = io_apic_read(entry->apic, 0x10 + pin*2);
 data &= ~IO_APIC_REDIR_VECTOR_MASK;
-data |= desc->arch.vector & 0xFF;
+data |= MASK_INSR(desc->arch.vector, IO_APIC_REDIR_VECTOR_MASK);
 io_apic_modify(entry->apic, 0x10 + pin*2, data);
 
 if (!entry->next)
--- a/xen/include/asm-x86/apic.h
+++ b/xen/include/asm-x86/apic.h
@@ -16,10 +16,6 @@
 
 #defineSET_APIC_LOGICAL_ID(x)  (((x)<<24))
 
-#define IO_APIC_REDIR_VECTOR_MASK  0x000FF
-#define IO_APIC_REDIR_DEST_LOGICAL 0x00800
-#define IO_APIC_REDIR_DEST_PHYSICAL0x0
-
 /* Possible APIC states */
 enum apic_mode {
 APIC_MODE_INVALID,  /* Not set yet */
--- a/xen/include/asm-x86/io_apic.h
+++ b/xen/include/asm-x86/io_apic.h
@@ -21,6 +21,7 @@
 
 /* I/O Unit Redirection Table */
 #define IO_APIC_REDIR_VECTOR_MASK   0x000FF
+#define IO_APIC_REDIR_DELIV_MODE_MASK 0x00700
 #define IO_APIC_REDIR_DEST_LOGICAL  0x00800
 #define IO_APIC_REDIR_DEST_PHYSICAL 0x0
 #define IO_APIC_REDIR_SEND_PENDING  (1 << 12)





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

[Xen-devel] [PATCH] VT-d: return full destination ID for IO-APIC reads

[Jan Beulich]

In x2APIC mode it is 32 bits wide. Not having returned the full value
was mostly benign: We never modify the ID based on its original value;
full new values get written at all times. It was "just" debug logging
which ended up wrong this way (and which will need adjustment itself as
well, to also consume the full value).

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -314,8 +314,13 @@ static int remap_entry_to_ioapic_rte(
 old_rte->dest_mode = iremap_entry->remap.dm;
 old_rte->trigger = iremap_entry->remap.tm;
 old_rte->__reserved_2 = 0;
-old_rte->dest.logical.__reserved_1 = 0;
-old_rte->dest.logical.logical_dest = iremap_entry->remap.dst >> 8;
+if ( x2apic_enabled )
+old_rte->dest.dest32 = iremap_entry->remap.dst;
+else
+{
+old_rte->dest.logical.__reserved_1 = 0;
+old_rte->dest.logical.logical_dest = iremap_entry->remap.dst >> 8;
+}
 
 unmap_vtd_domain_page(iremap_entries);
 spin_unlock_irqrestore(&ir_ctrl->iremap_lock, flags);



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

Re: [Xen-devel] [PATCH] x86/IO-APIC: consolidate / complete #define-s

[Andrew Cooper]

On 02/04/2019 13:55, Jan Beulich wrote:
> Drop redundant ones from apic.h. Add delivery mode mask. Use them in
> place of open coded hex numbers.
>
> Take the opportunity and modify a helper function's parameters to be
> just unsigned int. Also drop the bogus double underscore from its name,
> as it and all its callers get touched anyway.
>
> No functional change.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH v3] x86emul/fuzz: add a state sanity checking function

[Jan Beulich]

This is to accompany sanitize_input(). Just like for initial state we
want to have state between two emulated insns sane, at least as far as
assumptions in the main emulator go. Do minimal checking after segment
register, CR, and MSR writes, and roll back to the old value in case of
failure (raising #GP(0) at the same time).

In the particular case observed, a CR0 write clearing CR0.PE was
followed by a VEX-encoded insn, which the decoder accepts based on
guest address size, restricting things just outside of the 64-bit case
(real and virtual modes don't allow VEX-encoded insns). Subsequently
_get_fpu() would then assert that CR0.PE must be set (and EFLAGS.VM
clear) when trying to invoke YMM, ZMM, or OPMASK state.

Signed-off-by: Jan Beulich 
---
v3: Rename helper function to check_state().
v2: Correct placement of new declaration in fuzz_write_segment().

--- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
+++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
@@ -76,6 +76,8 @@ static inline bool input_read(struct fuz
 return true;
 }
 
+static bool check_state(struct x86_emulate_ctxt *ctxt);
+
 static const char* const x86emul_return_string[] = {
 [X86EMUL_OKAY] = "X86EMUL_OKAY",
 [X86EMUL_UNHANDLEABLE] = "X86EMUL_UNHANDLEABLE",
@@ -424,8 +426,19 @@ static int fuzz_write_segment(
 rc = maybe_fail(ctxt, "write_segment", true);
 
 if ( rc == X86EMUL_OKAY )
+{
+struct segment_register old = c->segments[seg];
+
 c->segments[seg] = *reg;
 
+if ( !check_state(ctxt) )
+{
+c->segments[seg] = old;
+x86_emul_hw_exception(13 /* #GP */, 0, ctxt);
+rc = X86EMUL_EXCEPTION;
+}
+}
+
 return rc;
 }
 
@@ -452,6 +465,7 @@ static int fuzz_write_cr(
 {
 struct fuzz_state *s = ctxt->data;
 struct fuzz_corpus *c = s->corpus;
+unsigned long old;
 int rc;
 
 if ( reg >= ARRAY_SIZE(c->cr) )
@@ -461,9 +475,17 @@ static int fuzz_write_cr(
 if ( rc != X86EMUL_OKAY )
 return rc;
 
+old = c->cr[reg];
 c->cr[reg] = val;
 
-return X86EMUL_OKAY;
+if ( !check_state(ctxt) )
+{
+c->cr[reg] = old;
+x86_emul_hw_exception(13 /* #GP */, 0, ctxt);
+rc = X86EMUL_EXCEPTION;
+}
+
+return rc;
 }
 
 #define fuzz_read_xcr emul_test_read_xcr
@@ -561,7 +583,16 @@ static int fuzz_write_msr(
 {
 if ( msr_index[idx] == reg )
 {
+uint64_t old = c->msr[idx];
+
 c->msr[idx] = val;
+
+if ( !check_state(ctxt) )
+{
+c->msr[idx] = old;
+break;
+}
+
 return X86EMUL_OKAY;
 }
 }
@@ -811,6 +842,30 @@ static void sanitize_input(struct x86_em
 }
 }
 
+/*
+ * Call this function from hooks potentially altering machine state into
+ * something that's not architecturally valid, yet which - as per above -
+ * the emulator relies on.
+ */
+static bool check_state(struct x86_emulate_ctxt *ctxt)
+{
+const struct fuzz_state *s = ctxt->data;
+const struct fuzz_corpus *c = s->corpus;
+const struct cpu_user_regs *regs = &c->regs;
+
+if ( long_mode_active(ctxt) && !(c->cr[0] & X86_CR0_PG) )
+return false;
+
+if ( (c->cr[0] & X86_CR0_PG) && !(c->cr[0] & X86_CR0_PE) )
+return false;
+
+if ( (regs->rflags & X86_EFLAGS_VM) &&
+ (c->segments[x86_seg_cs].db || c->segments[x86_seg_ss].db) )
+return false;
+
+return true;
+}
+
 int LLVMFuzzerInitialize(int *argc, char ***argv)
 {
 if ( !emul_test_init() )





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

Re: [Xen-devel] [PATCH] VT-d: return full destination ID for IO-APIC reads

[Andrew Cooper]

On 02/04/2019 13:56, Jan Beulich wrote:
> In x2APIC mode it is 32 bits wide. Not having returned the full value
> was mostly benign: We never modify the ID based on its original value;
> full new values get written at all times. It was "just" debug logging
> which ended up wrong this way (and which will need adjustment itself as
> well, to also consume the full value).
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH] x86/IO-APIC: dump full destination ID in x2APIC mode

[Jan Beulich]

In x2APIC mode it is 32 bits wide.

In __print_IO_APIC() drop logging of both physical and logical IDs:
The latter covers a superset of the bits of the former in the RTE, and
we write full 8-bit values anyway even in physical mode for all ordinary
interrupts, regardless of INT_DEST_MODE (see the users of SET_DEST()).

Adjust other column arrangement (and heading) a little as well.

Signed-off-by: Jan Beulich 
---
I'm sure I had found some place where the wider destination ID is
documented for physical mode, but I wasn't able to find it again when I
searched now. All Intel chipset docs I've looked at claim it's only 4
bits that are used / supposed to be stored.

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1191,21 +1191,21 @@ static void /*__init*/ __print_IO_APIC(b
 
printk(KERN_DEBUG " IRQ redirection table:\n");
 
-   printk(KERN_DEBUG " NR Log Phy Mask Trig IRR Pol"
-   " Stat Dest Deli Vect:   \n");
+   printk(KERN_DEBUG " NR %s Msk Trg IRR Pol Stat DstM DelM Vec\n",
+   x2apic_enabled ? " DestID" : "Dst");
 
for (i = 0; i <= reg_01.bits.entries; i++) {
 struct IO_APIC_route_entry entry;
 
 entry = ioapic_read_entry(apic, i, 0);
 
-printk(KERN_DEBUG " %02x %03X %02X  ",
-   i,
-   entry.dest.logical.logical_dest,
-   entry.dest.physical.physical_dest
-   );
+if ( x2apic_enabled )
+printk(KERN_DEBUG " %02x %08x", i, entry.dest.dest32);
+else
+printk(KERN_DEBUG " %02x  %02x ", i,
+   entry.dest.logical.logical_dest);
 
-printk("%1d%1d%1d   %1d   %1d%1d%1d%02X\n",
+printk(" %d   %d   %d   %d   %d%d%d%02X\n",
entry.mask,
entry.trigger,
entry.irr,
@@ -2481,12 +2481,14 @@ void dump_ioapic_irq_info(void)
 rte = ioapic_read_entry(entry->apic, pin, 0);
 
 printk("vec=%02x delivery=%-5s dest=%c status=%d "
-   "polarity=%d irr=%d trig=%c mask=%d dest_id:%d\n",
+   "polarity=%d irr=%d trig=%c mask=%d dest_id:%0*x\n",
rte.vector, delivery_mode_2_str(rte.delivery_mode),
rte.dest_mode ? 'L' : 'P',
rte.delivery_status, rte.polarity, rte.irr,
rte.trigger ? 'L' : 'E', rte.mask,
-   rte.dest.logical.logical_dest);
+   x2apic_enabled ? 8 : 2,
+   x2apic_enabled ? rte.dest.dest32
+  : rte.dest.logical.logical_dest);
 
 if ( entry->next == 0 )
 break;





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

Re: [Xen-devel] [PATCH v4 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/4/2 20:16, Andrew Cooper wrote:
> On 30/03/2019 10:42, Pu Wen wrote:
>> +static const struct cpu_dev hygon_cpu_dev = {
>> +.c_vendor   = "Hygon",
>> +.c_ident= { "HygonGenuine" },
>> +.c_early_init   = early_init_amd,
>> +.c_init = init_hygon,
>> +};
>> +
>> +int __init hygon_init_cpu(void)
>> +{
>> +cpu_devs[X86_VENDOR_HYGON] = &hygon_cpu_dev;
>> +return 0;
>> +}
>> diff --git a/xen/include/asm-x86/x86-vendors.h 
>> b/xen/include/asm-x86/x86-vendors.h
>> index 38a81c3..fa1cbb4 100644
>> --- a/xen/include/asm-x86/x86-vendors.h
>> +++ b/xen/include/asm-x86/x86-vendors.h
>> @@ -9,6 +9,7 @@
>>   #define X86_VENDOR_AMD 2
>>   #define X86_VENDOR_CENTAUR 3
>>   #define X86_VENDOR_SHANGHAI 4
>> -#define X86_VENDOR_NUM 5
>> +#define X86_VENDOR_HYGON 5
>> +#define X86_VENDOR_NUM 6
> 
> This change will need rebasing over
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e72309ffbe7c4e507649c74749f130cda691131c
> , which has dropped the .c_ident field for a more efficient lookup

Oh, this is already in the staging branch!

> mechanism.
> 
> Hopefully the adjustments are all obvious.  If not, I can draft a patch.

I'll try to rework this patch rebasing over the latest staging branch
for your review. Thanks.

-- 
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH 6/7] x86/IOMMU: abstract Intel-specific iommu_{en, dis}able_x2apic_IR()

[Jan Beulich]

>>> On 02.04.19 at 05:24,  wrote:
>>  From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, March 29, 2019 5:13 PM
>> 
>> >>> On 28.03.19 at 18:37,  wrote:
>> > On 28/03/2019 14:53, Jan Beulich wrote:
>> >> @@ -35,6 +35,8 @@ void print_vtd_entries(struct iommu *iom
>> >>  keyhandler_fn_t vtd_dump_iommu_info;
>> >>
>> >>  bool intel_iommu_supports_eim(void);
>> >> +int intel_iommu_enable_x2apic_IR(void);
>> >> +void intel_iommu_disable_x2apic_IR(void);
>> >
>> > Is there any particular reason why these retain their _IR suffix?
>> 
>> Well, I've too been thinking about the naming here. I decided to
>> keep the _IR suffixes because that's what the functions really
>> do: They enable/disable interrupt remapping for x2APIC mode.
>> They don't enable x2APIC itself in any way, and iirc x2APIC
>> mode could be used (without wider APIC IDs and in physical
>> mode) even without any IR enabled.
>> 
>> > I'd suggest going with intel_iommu_{en,dis}able_eim() to match the
>> > supports name here, whereas...
>> >
>> >> --- a/xen/drivers/passthrough/vtd/iommu.c
>> >> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> >> @@ -2720,6 +2720,8 @@ const struct iommu_ops __initconstrel in
>> >>  .free_page_table = iommu_free_page_table,
>> >>  .reassign_device = reassign_device_ownership,
>> >>  .get_device_group_id = intel_iommu_group_id,
>> >> +.enable_x2apic_IR = intel_iommu_enable_x2apic_IR,
>> >> +.disable_x2apic_IR = intel_iommu_disable_x2apic_IR,
>> >>  .update_ire_from_apic = io_apic_write_remap_rte,
>> >>  .update_ire_from_msi = msi_msg_write_remap_rte,
>> >>  .read_apic_from_ire = io_apic_read_remap_rte,
>> >> @@ -2736,6 +2738,7 @@ const struct iommu_ops __initconstrel in
>> >>  };
>> >>
>> >>  const struct iommu_init_ops __initconstrel intel_iommu_init_ops = {
>> >> +.ops = &intel_iommu_ops,
>> >>  .setup = vtd_setup,
>> >>  .supports_x2apic = intel_iommu_supports_eim,
>> >>  };
>> >> --- a/xen/drivers/passthrough/x86/iommu.c
>> >> +++ b/xen/drivers/passthrough/x86/iommu.c
>> >> @@ -26,6 +26,24 @@
>> >>  const struct iommu_init_ops *__initdata iommu_init_ops;
>> >>  struct iommu_ops __read_mostly iommu_ops;
>> >>
>> >> +int iommu_enable_x2apic_IR(void)
>> >
>> > ... using iommu_{en,dis}able_x2apic() here to match the
>> > supports_x2apic() init hook.
>> >
>> >
>> > I don't think these shorter names are any more ambiguous, and loosing
>> > the _IR suffix does make them more consistent with the rest of Xen's
>> > function naming conventions.
>> 
>> The above said, in the end I'm not overly fussed, but before deciding
>> which route to go I'll wait to see whether in particular Kevin has an
>> opinion either way.
>> 
> 
> let's remove _IR. we have intel_iommu prefix which is sufficient
> to indicate enable_x2apic in iommu context is about IR.
> 
> since renaming is small thing, here is my:
> 
>   Reviewed-by: Kevin Tian 

Thanks, but well, I'll then follow Andrew's suggestion and also
name the VT-d functions intel_iommu_{en,dis}able_eim(). I
hope that's okay with you.

Jan



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

Re: [Xen-devel] [PATCH] x86/IO-APIC: consolidate / complete #define-s

[Wei Liu]

On Tue, Apr 02, 2019 at 06:55:44AM -0600, Jan Beulich wrote:
> Drop redundant ones from apic.h. Add delivery mode mask. Use them in
> place of open coded hex numbers.
> 
> Take the opportunity and modify a helper function's parameters to be
> just unsigned int. Also drop the bogus double underscore from its name,
> as it and all its callers get touched anyway.
> 
> No functional change.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Wei Liu 

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

[Xen-devel] [distros-debian-snapshot test] 83859: trouble: blocked/broken

[Platform Team regression test user]

flight 83859 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/83859/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-i386   broken
 build-amd64-pvopsbroken
 build-armhf  broken
 build-amd64  broken
 build-i386-pvops broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-i386-daily-netboot-pygrub  1 build-check(1)   blocked n/a
 test-armhf-armhf-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-i386-i386-current-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-weekly-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-i386-amd64-weekly-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-current-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-current-netinst-pygrub  1 build-check(1)blocked n/a
 test-amd64-i386-amd64-current-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-daily-netboot-pvgrub  1 build-check(1)  blocked n/a
 test-amd64-i386-i386-daily-netboot-pvgrub  1 build-check(1)blocked n/a
 test-amd64-i386-i386-weekly-netinst-pygrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-weekly-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-daily-netboot-pygrub  1 build-check(1)   blocked n/a
 build-armhf   4 host-install(4)  broken like 83751
 build-armhf-pvops 4 host-install(4)  broken like 83751
 build-i3864 host-install(4)  broken like 83751
 build-amd64   4 host-install(4)  broken like 83751
 build-amd64-pvops 4 host-install(4)  broken like 83751
 build-i386-pvops  4 host-install(4)  broken like 83751
 build-armhf   5 capture-logs broken like 83751
 build-armhf-pvops 5 capture-logs broken like 83751

baseline version:
 flight   83751

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-daily-netboot-pvgrub  blocked 
 test-amd64-i386-i386-daily-netboot-pvgrubblocked 
 test-amd64-i386-amd64-daily-netboot-pygrub   blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  blocked 
 test-amd64-amd64-i386-daily-netboot-pygrub   blocked 
 test-amd64-amd64-amd64-current-netinst-pygrubblocked 
 test-amd64-i386-amd64-current-netinst-pygrub blocked 
 test-amd64-amd64-i386-current-netinst-pygrub blocked 
 test-amd64-i386-i386-current-netinst-pygrub  blocked 
 test-amd64-amd64-amd64-weekly-netinst-pygrub blocked 
 test-amd64-i386-amd64-weekly-netinst-pygrub  blocked 
 test-amd64-amd64-i386-weekly-netinst-pygrub  blocked 
 test-amd64-i386-i386-weekly-netinst-pygrub   blocked 



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.


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

Re: [Xen-devel] [RFC PATCH 4/6] vm_event: Use slotted channels for sync requests.

[Andrew Cooper]

On 10/01/2019 15:46, Paul Durrant wrote:
>> -Original Message-
>> From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com]
>> Sent: 10 January 2019 15:31
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Stefano Stabellini ; Wei Liu
>> ; Razvan Cojocaru ; Konrad
>> Rzeszutek Wilk ; George Dunlap
>> ; Andrew Cooper ; Ian
>> Jackson ; Tim (Xen.org) ; Julien
>> Grall ; Tamas K Lengyel ; Jan
>> Beulich ; Roger Pau Monne 
>> Subject: Re: [Xen-devel] [RFC PATCH 4/6] vm_event: Use slotted channels
>> for sync requests.
>>
>> On Thu, 2018-12-20 at 12:05 +, Paul Durrant wrote:
 -Original Message-

 The memory for the asynchronous ring and the synchronous channels
 will
 be allocated from domheap and mapped to the controlling domain
 using the
 foreignmemory_map_resource interface. Unlike the current
 implementation,
 the allocated pages are not part of the target DomU, so they will
 not be
 reclaimed when the vm_event domain is disabled.
>>> Why re-invent the wheel here? The ioreq infrastructure already does
>>> pretty much everything you need AFAICT.
>>>
>>>   Paul
>>>
>> Hi Paul,
>>
>> I'm still struggling to understand how the vm_event subsystem could be
>> integrated with an IOREQ server.
>>
>> An IOREQ server shares with the emulator 2 pages, one for ioreqs and
>> one for buffered_ioreqs. For vm_event we need to share also one or more
>> pages for the async ring and a few pages for the slotted synchronous
>> vm_events.
>> So, to my understanding, your idea to use the ioreq infrastructure for
>> vm_events is basically to replace the custom signalling (event channels
>> + ring / custom states) with ioreqs. Since the
>> vm_event_request/response structures are larger than 8 bytes, the
>> "data_is_ptr" flag should be used in conjunction with the addresses
>> (indexes) from the shared vm_event buffers.
>>
>> Is this the mechanism you had in mind?
>>
> Yes, that's roughly what I hoped might be possible. If that is too cumbersome 
> though then it should at least be feasible to mimic the ioreq code's page 
> allocation functions and code up vm_event buffers as another type of mappable 
> resource.

So, I've finally realised what has been subtly nagging at me for a while
from the suggestion to use ioreqs.  vm_event and ioreq have completely
different operations and semantics as far as the code in Xen is concerned.

The semantics for ioreq servers are "given a specific MMIO/PIO/CFG
action, which one of $N emulators should handle it".

vm_event on the other hand behaves just like the VT-x/SVM vmexit
intercepts.  It is "tell me when the guest does $X".  There isn't a
sensible case for having multiple vm_event consumers for a domain.

There is no overlap in the format of data used, or the cases where an
event would be sent.  Therefore, I think trying to implement vm_event in
terms of the ioreq server infrastructure is a short sighted move.

Beyond that, the only similarity is the slotted ring setup, which can be
entirely abstracted away behind resource mapping.  This actually comes
with a bonus in that vm_event will no longer strictly be tied to HVM
guests by virtue of its ring living in an HVMPARAM.

~Andrew

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

Re: [Xen-devel] [PATCH v4 00/15] Add support for Hygon Dhyana Family 18h processor

[Andrew Cooper]

On 30/03/2019 10:40, Pu Wen wrote:
> As a new x86 CPU vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
> is a joint venture between AMD and Haiguang Information Technology Co.,
> Ltd., aims at providing high performance x86 processors for China
> server market.
>
> The first generation Hygon processor(Dhyana) originates from AMD
> technology and shares most of the architecture with AMD's family 17h,
> but with different CPU vendor ID("HygonGenuine") and family series
> number 18h (Hygon negotiated with AMD to make sure that only Hygon
> will use family 18h).
>
> To enable support of Xen to Hygon Dhyana CPU, add a new vendor type
> (X86_VENDOR_HYGON, with value of 5), and share most of the code with
> AMD family 17h.
>
> The MSRs and CPUIDs which are used by this patch series are all defined
> in this PPR[1].
>
> This patch series have been applied and tested successfully on Hygon
> Dhyana processor, also been tested on AMD EPYC (family 17h) processor.
> It works fine and makes no harm to the existing code.
>
> Reference:
> [1] 
> https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf

One thing I don't see in this series is anything about microcode
loading.  Presumably you'll follow the AMD patchloading mechanism, with
a blob you provide yourself?

~Andrew

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

[Xen-devel] [qemu-mainline bisection] complete test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm
testid guest-saverestore

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  e60483f2f8498ae08ae79ca4c6fb03a3317f5e1e
  Bug not present: 9cd97956cfdde85d5887f2ea54ff598f615ee1b1
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/134294/


  commit e60483f2f8498ae08ae79ca4c6fb03a3317f5e1e
  Author: Markus Armbruster 
  Date:   Wed Mar 13 09:43:30 2019 +0100
  
  vl: Fix to create migration object before block backends again
  
  Recent commit cda4aa9a5a0 moved block backend creation before machine
  property evaluation.  This broke qemu-iotests 055.  Turns out we need
  to create the migration object before block backends, so block
  backends can add migration blockers.  Fix by calling
  migration_object_init() earlier, right before configure_blockdev().
  
  Fixes: cda4aa9a5a08777cf13e164c0543bd4888b8adce
  Reported-by: Kevin Wolf 
  Signed-off-by: Markus Armbruster 
  Signed-off-by: Kevin Wolf 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm.guest-saverestore
 --summary-out=tmp/134294.bisection-summary --basis-template=133909 
--blessings=real,real-bisect qemu-mainline 
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm guest-saverestore
Searching for failure / basis pass:
 133997 fail [host=elbling0] / 133909 [host=baroque0] 133872 [host=rimava1] 
133844 [host=fiano0] 133791 [host=italia1] 133750 [host=pinot1] 133703 
[host=merlot1] 133677 [host=chardonnay1] 133650 [host=albana1] 133613 
[host=fiano1] 133589 ok.
Failure / basis pass flights: 133997 / 133589
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 5726a8d0f1958af80ad8e514bc2c18d213e739b7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
d97a39d903fe33c45be83ac6943a2f82a3649a11 
59e9783ddf18e650622e0573cad4f08db65592e4
Basis pass 30921fc1e5fcf904f9afddeece1288f5b16ba017 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
b6179aaff961627fcb59d7b234297966b81ac726 
f393b82fe5ba3ed9cfe2b306ffa53368e55b75af
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#30921fc1e5fcf904f9afddeece1288f5b16ba017-5726a8d0f1958af80ad8e514bc2c18d213e739b7
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 git://git.qemu.org/qemu.git#b6179aaff961627fcb59d7b234297966b81ac7\
 26-d97a39d903fe33c45be83ac6943a2f82a3649a11 
git://xenbits.xen.org/xen.git#f393b82fe5ba3ed9cfe2b306ffa53368e55b75af-59e9783ddf18e650622e0573cad4f08db65592e4
From git://cache:9419/git://git.qemu.org/qemu
   d61d1a1fb2..436960c959  master -> origin/master
Loaded 16280 nodes in revision graph
Searching for test results:
 133589 pass 30921fc1e5fcf904f9afddeece1288f5b16ba017 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
b6179aaff961627fcb59d7b234297966b81ac726 
f393b82fe5ba3ed9cfe2b306ffa53368e55b75af
 133613 [host=fiano1]
 133677 [host=chardonnay1]
 133650 [host=albana1]
 133791 [host=italia1]
 133703 [host=merlot1]
 133750 [host=pinot1]
 133844 [host=fiano0]
 133872 [host=rimava1]
 133909 [host=baroque0]
 133939 fail irrelevant
 133975 fail irrelevant
 133997 fail 5726a8d0f1958af80ad8e514bc2c18d213e739b7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
d97a39d903fe33c45be83ac6943a2f82a3649a11 
59e9783ddf18e650622e0573cad4f08db65592e4
 134221 fail 5726a8d0f1958af80ad8e514bc2c18d213e739b7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
27e42789b7769ee9556767627542cf8fd9bfbc4d 
a892f81ddecf0ad90564a4d91d520234c542b068
 134212 fail 5726a8d0f1958af80ad8e514bc2c18d213e739b7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50

Re: [Xen-devel] [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Jan Beulich]

>>> On 02.04.19 at 12:30,  wrote:
> On 01/04/2019 09:40, Jan Beulich wrote:
> On 30.03.19 at 11:42,  wrote:
>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
>> I think it would have been nice if you had mentioned the real
>> reason why you want to bypass the MSR accesses. This way it
>> sounds as if the change was only cosmetic, and hence could be
>> left out.
>>
>>> Signed-off-by: Pu Wen 
>> Acked-by: Jan Beulich 
>>
>> Andrew, I'd like to ask for explicit clarification that you don't object
>> to this adjustment. But if you do, please clarify why.
> 
> We deliberately emulate MSR_INTEL_PLATFORM_INFO on all systems
> 
> This is to support pv-shim, so the L1 Xen can exert faulting control
> over the L2 PV guest, so L2 doesn't see L1's HVM CPUID leaves and choke.
> 
> I suppose its fine to have a !cpu_has_hypervisor exclusion for non-Intel
> systems, but I also don't see much value in it.

But you've see Pu Wen's explanation (of their CPUs hanging on that
RDMSR is attempted)? In a later reply he even claims that this also
happens on some AMD CPUs.

Jan



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

Re: [Xen-devel] [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Jan Beulich]

>>> On 02.04.19 at 13:58,  wrote:
> On 2019/4/2 18:20, Jan Beulich wrote:
>> On 02.04.19 at 08:46,  wrote:
>>> On 2019/4/1 16:41, Jan Beulich wrote:
 On 30.03.19 at 11:42,  wrote:
> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So 
> directly
> return false in the function probe_cpuid_faulting() if 
> !cpu_has_hypervisor.

 I think it would have been nice if you had mentioned the real
 reason why you want to bypass the MSR accesses. This way it
 sounds as if the change was only cosmetic, and hence could be
 left out.
>>>
>>> Okay, how about the new description:
>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
>>> this MSR will stop the Xen initialization process
>> 
>> "... for some early Hygon steppings"(?). I'm unaware of AMD CPUs
> 
> Yes,for some early Hygon steppings.
> 
>> having this issue - are you telling us otherwise?
> 
> I tested with an AMD CPU(Family 17h, Model 1, Stepping 1) today, and
> it also stopped when reading the MSR_INTEL_PLATFORM_INFO instead of
> producing #GP(0).

I've yet to try it out on my Rome system, but I have to admit I
find this hard to believe. Andrew - you've tried to boot Xen on a
Rome already. Iirc you said it crashed, but did it perhaps get to
(and past) this point?

Jan



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

Re: [Xen-devel] [PATCH v4 04/15] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Jan Beulich]

>>> On 02.04.19 at 14:11,  wrote:
> By the way, how about the patch 01/15 of this series?
> If it's fine, could you please offer Acked-by tag for it?

I've yet to look at v4 of it.

Jan



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

[Xen-devel] [ANNOUNCEMENT] Xen 4.12 is released

[Juergen Gross]

Dear community members,

I'm pleased to announce that Xen 4.12.0 is released.

Please find the tarball and its signature at:


https://xenproject.org/downloads/xen-project-archives/xen-project-4-12-series/xen-project-4-12-0/

You can also check out the tag in xen.git:

  https://xenbits.xen.org/git-http/xen.git RELEASE-4.12.0

Git checkout and build instructions can be found at:


https://wiki.xenproject.org/wiki/Xen_Project_4.12_Release_Notes#Build_Requirements

Release notes can be found at:

  https://wiki.xenproject.org/wiki/Xen_Project_4.12_Release_Notes

A summary for 4.12 release documents can be found at:

  https://wiki.xenproject.org/wiki/Category:Xen_4.12

Technical blog post for 4.12 can be found at:

  https://blog.xenproject.org/2019/04/02/whats-new-in-xen-4-12/

Thanks everyone who contributed to this release. This release would
not have happened without all the awesome contributions from around
the globe.

Regards,

Juergen Gross (on behalf of the Xen Project Hypervisor team)

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

Re: [Xen-devel] [PATCH v4 00/15] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

On 2019/4/2 23:14, Andrew Cooper wrote:

On 30/03/2019 10:40, Pu Wen wrote:

This patch series have been applied and tested successfully on Hygon
Dhyana processor, also been tested on AMD EPYC (family 17h) processor.
It works fine and makes no harm to the existing code.

Reference:
[1] 
https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf


One thing I don't see in this series is anything about microcode


Right now Hygon load microcode in BIOS.


loading.  Presumably you'll follow the AMD patchloading mechanism, with
a blob you provide yourself?


We are exploring the Hygon patchloading mechanism, which will employ 
most of the functions of AMD's. We also try to make the Hygon microcode 
blob be compatible with the AMD one.


When the Hygon patchloading mechanism is practicable and it's necessary 
to load the Hygon microcode outside of BIOS, we'll send the patchloading 
patches to Xen and Linux mailing lists.


Thx.

--
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v3 0/6] xen: simplify suspend/resume handling

[Andrew Cooper]

On 02/04/2019 06:34, Juergen Gross wrote:
> Especially in the scheduler area (schedule.c, cpupool.c) there is a
> rather complex handling involved when doing suspend and resume.
>
> This can be simplified a lot by not performing a complete cpu down and
> up cycle for the non-boot cpus, but keeping the pure software related
> state and freeing it only in case a cpu didn't come up again during
> resume.
>
> In summary not only the complexity can be reduced, but the failure
> tolerance will be even better with this series: With a dedicated hook
> for failing cpus when resuming it is now possible to survive e.g. a
> cpupool being left without any cpu after resume by moving its domains
> to cpupool0.
>
> Juergen Gross (6):
>   xen/sched: call cpu_disable_scheduler() via cpu notifier
>   xen: add helper for calling notifier_call_chain() to common/cpu.c
>   xen: add new cpu notifier action CPU_RESUME_FAILED
>   xen: don't free percpu areas during suspend
>   xen/cpupool: simplify suspend/resume handling
>   xen/sched: don't disable scheduler on cpus during suspend

So I came to try and commit this series.  However,

[root@fusebot ~]# xen-hptool cpu-offline 1
Prepare to offline CPU 1
CPU 1 offline failed (error 11: Resource temporarily unavailable)
[root@fusebot ~]# xen-hptool cpu-offline 2
Prepare to offline CPU 2
CPU 2 offline failed (error 11: Resource temporarily unavailable)
[root@fusebot ~]#

Something here has regressed all ability to hotplug.  Its not
immediately obvious what.

~Andrew

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

Re: [Xen-devel] [PATCH 3/3] memory: restrict XENMEM_remove_from_physmap to translated guests

[Jan Beulich]

>>> On 02.04.19 at 12:26,  wrote:
> On 05/03/2019 13:28, Jan Beulich wrote:
>> The commit re-introducing it (14eb3b41d0 ["xen: reinstate previously
>> unused XENMEM_remove_from_physmap hypercall"]) as well as the one having
>> originally introduced it (d818f3cb7c ["hvm: Use main memory for video
>> memory"]) and the one then purging it again (78c3097e4f ["Remove unused
>> XENMEM_remove_from_physmap"]) make clear that this operation is intended
>> for use on HVM (i.e. translated) guests only. Restrict it at least as
>> much, because for PV guests documentation (in the public header) does
>> not even match the implementation: It talks about GPFN as input, but
>> get_page_from_gfn() assumes a GMFN in the non-translated case (and hands
>> back the value passed in).
>> 
>> Also lift the check in XENMEM_add_to_physmap{,_batch} handling up
>> directly into top level hypercall handling, and clarify things in the
>> public header accordingly.
>> 
>> Take the liberty and also replace a pointless use of "current" with a
>> more efficient use of an existing local variable (or function parameter
>> to be precise).
>> 
>> Signed-off-by: Jan Beulich 
>> ---
>> TBD: It could be further restricted, disallowing its use by a HVM guest
>>   on itself.
> 
> By HVM guest, do you refer to any auto-translated guest?

Yes - sorry for using an x86 term.

> The interface XENME_remove_from_physmap is used by Arm to remove foreign 
> mappings from its p2m. There are potentially other space with similar case 
> (e.g grant-table...).

Oh, I see - this option goes away then.

>> TBD: Is using P2M_ALLOC here really appropriate? It means e.g.
>>   pointlessly populating a PoD slot just to unpopulate it again right
>>   away, with the page then free floating, i.e. no longer available
>>   for use to replace another PoD slot, and (afaict) no longer
>>   accessible by the guest in any way.
>> TBD: Is using guest_physmap_remove_page() here really appropriate? It
>>   means that e.g. MMIO pages wouldn't be removed. Going through
>>   guest_remove_page() (while skipping the de-allocation step) would
>>   seem more appropriate to me, which would address the P2M_ALLOC
>>   aspect above as well.
> 
> How is that an issue? Does XENMEM_add_to_physmap allows you to map MMIO 
> pages?

Well, there's XENMAPSPACE_dev_mmio which xatp handles. But
perhaps the MMIO example is more confusing than helpful. The
question really just is whether guest_remove_page() shouldn't
be used here instead of guest_physmap_remove_page().

But of course - first of all I'd like to get acks (or feedback what to
change) on the actual patch here. The further points would all, if
anything, result in independent patches.

Jan



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

Re: [Xen-devel] [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Andrew Cooper]

On 02/04/2019 16:46, Jan Beulich wrote:
 On 02.04.19 at 13:58,  wrote:
>> On 2019/4/2 18:20, Jan Beulich wrote:
>>> On 02.04.19 at 08:46,  wrote:
 On 2019/4/1 16:41, Jan Beulich wrote:
> On 30.03.19 at 11:42,  wrote:
>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So 
>> directly
>> return false in the function probe_cpuid_faulting() if 
>> !cpu_has_hypervisor.
> I think it would have been nice if you had mentioned the real
> reason why you want to bypass the MSR accesses. This way it
> sounds as if the change was only cosmetic, and hence could be
> left out.
 Okay, how about the new description:
 There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
 this MSR will stop the Xen initialization process
>>> "... for some early Hygon steppings"(?). I'm unaware of AMD CPUs
>> Yes,for some early Hygon steppings.
>>
>>> having this issue - are you telling us otherwise?
>> I tested with an AMD CPU(Family 17h, Model 1, Stepping 1) today, and
>> it also stopped when reading the MSR_INTEL_PLATFORM_INFO instead of
>> producing #GP(0).
> I've yet to try it out on my Rome system, but I have to admit I
> find this hard to believe. Andrew - you've tried to boot Xen on a
> Rome already. Iirc you said it crashed, but did it perhaps get to
> (and past) this point?

I've got Fam10, 15, 17 (both Naples and Rome) and haven't encountered
any problems.

Whatever is going on, it sounds like a microcode bug.

~Andrew

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

Re: [Xen-devel] [PATCH v4 00/15] Add support for Hygon Dhyana Family 18h processor

[Jan Beulich]

>>> On 02.04.19 at 18:00,  wrote:
> On 2019/4/2 23:14, Andrew Cooper wrote:
>> On 30/03/2019 10:40, Pu Wen wrote:
>>> This patch series have been applied and tested successfully on Hygon
>>> Dhyana processor, also been tested on AMD EPYC (family 17h) processor.
>>> It works fine and makes no harm to the existing code.
>>>
>>> Reference:
>>> [1] 
> https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh 
> .pdf
>> 
>> One thing I don't see in this series is anything about microcode
> 
> Right now Hygon load microcode in BIOS.
> 
>> loading.  Presumably you'll follow the AMD patchloading mechanism, with
>> a blob you provide yourself?
> 
> We are exploring the Hygon patchloading mechanism, which will employ 
> most of the functions of AMD's. We also try to make the Hygon microcode 
> blob be compatible with the AMD one.
> 
> When the Hygon patchloading mechanism is practicable and it's necessary 
> to load the Hygon microcode outside of BIOS, we'll send the patchloading 
> patches to Xen and Linux mailing lists.

I suppose both Intel and AMD had this same intention of ucode loading
being a firmware job only, and we see where we are right now. As long
as updated firmware does not become available in a timely manner (or
perhaps not at all, because of a vendor considering a certain system
EOL), there's going to be a need to be able to load it from the OS.

Jan



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

[Xen-devel] [PATCH v4 1/6] xen/sched: call cpu_disable_scheduler() via cpu notifier

[Juergen Gross]

cpu_disable_scheduler() is being called from __cpu_disable() today.
There is no need to execute it on the cpu just being disabled, so use
the CPU_DEAD case of the cpu notifier chain. Moving the call out of
stop_machine() context is fine, as we just need to hold the domain RCU
lock and need the scheduler percpu data to be still allocated.

Add another hook for CPU_DOWN_PREPARE to bail out early in case
cpu_disable_scheduler() would fail. This will avoid crashes in rare
cases for cpu hotplug or suspend.

Signed-off-by: Juergen Gross 
Acked-by: Julien Grall 
---
V4:
- correct cpu_disable_scheduler_check() for hotplug case (Andrew Cooper)

V3:
- restore smp_mb() (Julien Grall)

V2:
- add CPU_DOWN_PREPARE hook
- BUG() in case of cpu_disable_scheduler() failing in CPU_DEAD
  (Jan Beulich)
- modify ARM __cpu_disable(), too (Andrew Cooper)
---
 xen/arch/arm/smpboot.c |  2 --
 xen/arch/x86/smpboot.c |  3 ---
 xen/common/schedule.c  | 36 +---
 3 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 25cd44549c..f756444362 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -386,8 +386,6 @@ void __cpu_disable(void)
 /* It's now safe to remove this processor from the online map */
 cpumask_clear_cpu(cpu, &cpu_online_map);
 
-if ( cpu_disable_scheduler(cpu) )
-BUG();
 smp_mb();
 
 /* Return to caller; eventually the IPI mechanism will unwind and the 
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 7d1226d7bc..b7a0a4a419 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1221,9 +1221,6 @@ void __cpu_disable(void)
 cpumask_clear_cpu(cpu, &cpu_online_map);
 fixup_irqs(&cpu_online_map, 1);
 fixup_eoi();
-
-if ( cpu_disable_scheduler(cpu) )
-BUG();
 }
 
 void __cpu_die(unsigned int cpu)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 76d60785e2..86bd10945d 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -773,8 +773,9 @@ void restore_vcpu_affinity(struct domain *d)
 }
 
 /*
- * This function is used by cpu_hotplug code from stop_machine context
+ * This function is used by cpu_hotplug code via cpu notifier chain
  * and from cpupools to switch schedulers on a cpu.
+ * Caller must get domlist_read_lock.
  */
 int cpu_disable_scheduler(unsigned int cpu)
 {
@@ -789,12 +790,6 @@ int cpu_disable_scheduler(unsigned int cpu)
 if ( c == NULL )
 return ret;
 
-/*
- * We'd need the domain RCU lock, but:
- *  - when we are called from cpupool code, it's acquired there already;
- *  - when we are called for CPU teardown, we're in stop-machine context,
- *so that's not be a problem.
- */
 for_each_domain_in_cpupool ( d, c )
 {
 for_each_vcpu ( d, v )
@@ -893,6 +888,24 @@ int cpu_disable_scheduler(unsigned int cpu)
 return ret;
 }
 
+static int cpu_disable_scheduler_check(unsigned int cpu)
+{
+struct domain *d;
+struct vcpu *v;
+struct cpupool *c;
+
+c = per_cpu(cpupool, cpu);
+if ( c == NULL )
+return 0;
+
+for_each_domain_in_cpupool ( d, c )
+for_each_vcpu ( d, v )
+if ( v->affinity_broken )
+return -EADDRINUSE;
+
+return 0;
+}
+
 /*
  * In general, this must be called with the scheduler lock held, because the
  * adjust_affinity hook may want to modify the vCPU state. However, when the
@@ -1734,7 +1747,16 @@ static int cpu_schedule_callback(
 case CPU_UP_PREPARE:
 rc = cpu_schedule_up(cpu);
 break;
+case CPU_DOWN_PREPARE:
+rcu_read_lock(&domlist_read_lock);
+rc = cpu_disable_scheduler_check(cpu);
+rcu_read_unlock(&domlist_read_lock);
+break;
 case CPU_DEAD:
+rcu_read_lock(&domlist_read_lock);
+rc = cpu_disable_scheduler(cpu);
+BUG_ON(rc);
+rcu_read_unlock(&domlist_read_lock);
 SCHED_OP(sched, deinit_pdata, sd->sched_priv, cpu);
 /* Fallthrough */
 case CPU_UP_CANCELED:
-- 
2.16.4


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

[Xen-devel] [PATCH v4 4/6] xen: don't free percpu areas during suspend

[Juergen Gross]

Instead of freeing percpu areas during suspend and allocating them
again when resuming keep them. Only free an area in case a cpu didn't
come up again when resuming.

It should be noted that there is a potential change in behaviour as
the percpu areas are no longer zeroed out during suspend/resume. While
I have checked the called cpu notifier hooks to cope with that there
might be some well hidden dependency on the previous behaviour. OTOH
a component not registering itself for cpu down/up and expecting to
see a zeroed percpu variable after suspend/resume is kind of broken
already. And the opposite case, where a component is not registered
to be called for cpu down/up and is not expecting a percpu variable
suddenly to be zero due to suspend/resume is much more probable,
especially as the suspend/resume functionality seems not to be tested
that often.

Signed-off-by: Juergen Gross 
Reviewed-by: Dario Faggioli 
Acked-by: Jan Beulich 
---
 xen/arch/x86/percpu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/percpu.c b/xen/arch/x86/percpu.c
index 8be4ebddf4..5ea14b6ec3 100644
--- a/xen/arch/x86/percpu.c
+++ b/xen/arch/x86/percpu.c
@@ -76,7 +76,8 @@ static int cpu_percpu_callback(
 break;
 case CPU_UP_CANCELED:
 case CPU_DEAD:
-if ( !park_offline_cpus )
+case CPU_RESUME_FAILED:
+if ( !park_offline_cpus && system_state != SYS_STATE_suspend )
 free_percpu_area(cpu);
 break;
 case CPU_REMOVE:
-- 
2.16.4


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

[Xen-devel] [PATCH v4 5/6] xen/cpupool: simplify suspend/resume handling

[Juergen Gross]

Instead of removing cpus temporarily from cpupools during
suspend/resume only remove cpus finally which didn't come up when
resuming.

Signed-off-by: Juergen Gross 
Reviewed-by: George Dunlap 
Reviewed-by: Dario Faggioli 
---
V2:
- add comment (George Dunlap)
---
 xen/common/cpupool.c   | 131 ++---
 xen/include/xen/sched-if.h |   1 -
 2 files changed, 52 insertions(+), 80 deletions(-)

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index e89bb67e71..31ac323e40 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -47,12 +47,6 @@ static struct cpupool *alloc_cpupool_struct(void)
 xfree(c);
 c = NULL;
 }
-else if ( !zalloc_cpumask_var(&c->cpu_suspended) )
-{
-free_cpumask_var(c->cpu_valid);
-xfree(c);
-c = NULL;
-}
 
 return c;
 }
@@ -60,10 +54,7 @@ static struct cpupool *alloc_cpupool_struct(void)
 static void free_cpupool_struct(struct cpupool *c)
 {
 if ( c )
-{
-free_cpumask_var(c->cpu_suspended);
 free_cpumask_var(c->cpu_valid);
-}
 xfree(c);
 }
 
@@ -477,10 +468,6 @@ void cpupool_rm_domain(struct domain *d)
 /*
  * Called to add a cpu to a pool. CPUs being hot-plugged are added to pool0,
  * as they must have been in there when unplugged.
- *
- * If, on the other hand, we are adding CPUs because we are resuming (e.g.,
- * after ACPI S3) we put the cpu back in the pool where it was in prior when
- * we suspended.
  */
 static int cpupool_cpu_add(unsigned int cpu)
 {
@@ -490,42 +477,15 @@ static int cpupool_cpu_add(unsigned int cpu)
 cpumask_clear_cpu(cpu, &cpupool_locked_cpus);
 cpumask_set_cpu(cpu, &cpupool_free_cpus);
 
-if ( system_state == SYS_STATE_suspend || system_state == SYS_STATE_resume 
)
-{
-struct cpupool **c;
-
-for_each_cpupool(c)
-{
-if ( cpumask_test_cpu(cpu, (*c)->cpu_suspended ) )
-{
-ret = cpupool_assign_cpu_locked(*c, cpu);
-if ( ret )
-goto out;
-cpumask_clear_cpu(cpu, (*c)->cpu_suspended);
-break;
-}
-}
+/*
+ * If we are not resuming, we are hot-plugging cpu, and in which case
+ * we add it to pool0, as it certainly was there when hot-unplagged
+ * (or unplugging would have failed) and that is the default behavior
+ * anyway.
+ */
+per_cpu(cpupool, cpu) = NULL;
+ret = cpupool_assign_cpu_locked(cpupool0, cpu);
 
-/*
- * Either cpu has been found as suspended in a pool, and added back
- * there, or it stayed free (if it did not belong to any pool when
- * suspending), and we don't want to do anything.
- */
-ASSERT(cpumask_test_cpu(cpu, &cpupool_free_cpus) ||
-   cpumask_test_cpu(cpu, (*c)->cpu_valid));
-}
-else
-{
-/*
- * If we are not resuming, we are hot-plugging cpu, and in which case
- * we add it to pool0, as it certainly was there when hot-unplagged
- * (or unplugging would have failed) and that is the default behavior
- * anyway.
- */
-per_cpu(cpupool, cpu) = NULL;
-ret = cpupool_assign_cpu_locked(cpupool0, cpu);
-}
- out:
 spin_unlock(&cpupool_lock);
 
 return ret;
@@ -535,42 +495,14 @@ static int cpupool_cpu_add(unsigned int cpu)
  * Called to remove a CPU from a pool. The CPU is locked, to forbid removing
  * it from pool0. In fact, if we want to hot-unplug a CPU, it must belong to
  * pool0, or we fail.
- *
- * However, if we are suspending (e.g., to ACPI S3), we mark the CPU in such
- * a way that it can be put back in its pool when resuming.
  */
 static int cpupool_cpu_remove(unsigned int cpu)
 {
 int ret = -ENODEV;
 
 spin_lock(&cpupool_lock);
-if ( system_state == SYS_STATE_suspend )
-{
-struct cpupool **c;
-
-for_each_cpupool(c)
-{
-if ( cpumask_test_cpu(cpu, (*c)->cpu_valid ) )
-{
-cpumask_set_cpu(cpu, (*c)->cpu_suspended);
-cpumask_clear_cpu(cpu, (*c)->cpu_valid);
-break;
-}
-}
 
-/*
- * Either we found cpu in a pool, or it must be free (if it has been
- * hot-unplagged, then we must have found it in pool0). It is, of
- * course, fine to suspend or shutdown with CPUs not assigned to a
- * pool, and (in case of suspend) they will stay free when resuming.
- */
-ASSERT(cpumask_test_cpu(cpu, &cpupool_free_cpus) ||
-   cpumask_test_cpu(cpu, (*c)->cpu_suspended));
-ASSERT(cpumask_test_cpu(cpu, &cpu_online_map) ||
-   cpumask_test_cpu(cpu, cpupool0->cpu_suspended));
-ret = 0;
-}
-else if ( cpumask_test_cpu(cpu, cpupool0->cpu_valid) )
+if ( cpumask_test_cpu(cpu, cpupool0->cpu_valid) )
 {
 /*
  * If we are not suspending, w

[Xen-devel] [PATCH v4 0/6] xen: simplify suspend/resume handling

[Juergen Gross]

Especially in the scheduler area (schedule.c, cpupool.c) there is a
rather complex handling involved when doing suspend and resume.

This can be simplified a lot by not performing a complete cpu down and
up cycle for the non-boot cpus, but keeping the pure software related
state and freeing it only in case a cpu didn't come up again during
resume.

In summary not only the complexity can be reduced, but the failure
tolerance will be even better with this series: With a dedicated hook
for failing cpus when resuming it is now possible to survive e.g. a
cpupool being left without any cpu after resume by moving its domains
to cpupool0.

Juergen Gross (6):
  xen/sched: call cpu_disable_scheduler() via cpu notifier
  xen: add helper for calling notifier_call_chain() to common/cpu.c
  xen: add new cpu notifier action CPU_RESUME_FAILED
  xen: don't free percpu areas during suspend
  xen/cpupool: simplify suspend/resume handling
  xen/sched: don't disable scheduler on cpus during suspend

 xen/arch/arm/smpboot.c |   2 -
 xen/arch/x86/percpu.c  |   3 +-
 xen/arch/x86/smpboot.c |   3 -
 xen/common/cpu.c   |  61 +++---
 xen/common/cpupool.c   | 131 --
 xen/common/schedule.c  | 197 +++--
 xen/include/xen/cpu.h  |  29 ---
 xen/include/xen/sched-if.h |   1 -
 8 files changed, 184 insertions(+), 243 deletions(-)

-- 
2.16.4


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

Re: [Xen-devel] [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Pu Wen]

On 2019/4/2 23:46, Jan Beulich wrote:

On 02.04.19 at 13:58,  wrote:

On 2019/4/2 18:20, Jan Beulich wrote:

On 02.04.19 at 08:46,  wrote:

On 2019/4/1 16:41, Jan Beulich wrote:

On 30.03.19 at 11:42,  wrote:

There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.


I think it would have been nice if you had mentioned the real
reason why you want to bypass the MSR accesses. This way it
sounds as if the change was only cosmetic, and hence could be
left out.


Okay, how about the new description:
There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
this MSR will stop the Xen initialization process


"... for some early Hygon steppings"(?). I'm unaware of AMD CPUs


Yes,for some early Hygon steppings.


having this issue - are you telling us otherwise?


I tested with an AMD CPU(Family 17h, Model 1, Stepping 1) today, and
it also stopped when reading the MSR_INTEL_PLATFORM_INFO instead of
producing #GP(0).


I've yet to try it out on my Rome system, but I have to admit I


We have Rome system too, I'll have a try on it as well.


find this hard to believe. Andrew - you've tried to boot Xen on a
Rome already. Iirc you said it crashed, but did it perhaps get to
(and past) this point?


--
Regards,
Pu Wen

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

[Xen-devel] [PATCH v4 6/6] xen/sched: don't disable scheduler on cpus during suspend

[Juergen Gross]

Today there is special handling in cpu_disable_scheduler() for suspend
by forcing all vcpus to the boot cpu. In fact there is no need for that
as during resume the vcpus are put on the correct cpus again.

So we can just omit the call of cpu_disable_scheduler() when offlining
a cpu due to suspend and on resuming we can omit taking the schedule
lock for selecting the new processor.

In restore_vcpu_affinity() we should be careful when applying affinity
as the cpu might not have come back to life. This in turn enables us
to even support affinity_broken across suspend/resume.

Avoid all other scheduler dealloc - alloc dance when doing suspend and
resume, too. It is enough to react on cpus failing to come up on resume
again.

Signed-off-by: Juergen Gross 
Reviewed-by: Dario Faggioli 
---
 xen/common/schedule.c | 161 --
 1 file changed, 52 insertions(+), 109 deletions(-)

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 86bd10945d..a418506c6b 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -560,33 +560,6 @@ static void vcpu_move_locked(struct vcpu *v, unsigned int 
new_cpu)
 v->processor = new_cpu;
 }
 
-/*
- * Move a vcpu from its current processor to a target new processor,
- * without asking the scheduler to do any placement. This is intended
- * for being called from special contexts, where things are quiet
- * enough that no contention is supposed to happen (i.e., during
- * shutdown or software suspend, like ACPI S3).
- */
-static void vcpu_move_nosched(struct vcpu *v, unsigned int new_cpu)
-{
-unsigned long flags;
-spinlock_t *lock, *new_lock;
-
-ASSERT(system_state == SYS_STATE_suspend);
-ASSERT(!vcpu_runnable(v) && (atomic_read(&v->pause_count) ||
- atomic_read(&v->domain->pause_count)));
-
-lock = per_cpu(schedule_data, v->processor).schedule_lock;
-new_lock = per_cpu(schedule_data, new_cpu).schedule_lock;
-
-sched_spin_lock_double(lock, new_lock, &flags);
-ASSERT(new_cpu != v->processor);
-vcpu_move_locked(v, new_cpu);
-sched_spin_unlock_double(lock, new_lock, flags);
-
-sched_move_irqs(v);
-}
-
 /*
  * Initiating migration
  *
@@ -735,31 +708,36 @@ void restore_vcpu_affinity(struct domain *d)
 
 ASSERT(!vcpu_runnable(v));
 
-lock = vcpu_schedule_lock_irq(v);
-
-if ( v->affinity_broken )
-{
-sched_set_affinity(v, v->cpu_hard_affinity_saved, NULL);
-v->affinity_broken = 0;
-
-}
-
 /*
- * During suspend (in cpu_disable_scheduler()), we moved every vCPU
- * to BSP (which, as of now, is pCPU 0), as a temporary measure to
- * allow the nonboot processors to have their data structure freed
- * and go to sleep. But nothing guardantees that the BSP is a valid
- * pCPU for a particular domain.
+ * Re-assign the initial processor as after resume we have no
+ * guarantee the old processor has come back to life again.
  *
  * Therefore, here, before actually unpausing the domains, we should
  * set v->processor of each of their vCPUs to something that will
  * make sense for the scheduler of the cpupool in which they are in.
  */
 cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
-cpupool_domain_cpumask(v->domain));
-v->processor = cpumask_any(cpumask_scratch_cpu(cpu));
+cpupool_domain_cpumask(d));
+if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
+{
+if ( v->affinity_broken )
+{
+sched_set_affinity(v, v->cpu_hard_affinity_saved, NULL);
+v->affinity_broken = 0;
+cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
+cpupool_domain_cpumask(d));
+}
 
-spin_unlock_irq(lock);
+if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
+{
+printk(XENLOG_DEBUG "Breaking affinity for %pv\n", v);
+sched_set_affinity(v, &cpumask_all, NULL);
+cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
+cpupool_domain_cpumask(d));
+}
+}
+
+v->processor = cpumask_any(cpumask_scratch_cpu(cpu));
 
 lock = vcpu_schedule_lock_irq(v);
 v->processor = SCHED_OP(vcpu_scheduler(v), pick_cpu, v);
@@ -783,7 +761,6 @@ int cpu_disable_scheduler(unsigned int cpu)
 struct vcpu *v;
 struct cpupool *c;
 cpumask_t online_affinity;
-unsigned int new_cpu;
 int ret = 0;
 
 c = per_cpu(cpupool, cpu);
@@ -809,14 +786,7 @@ int cpu_disable_scheduler(unsigned int cpu)
 break;
 }
 
-if (system_state == SYS_STATE_suspend)
-{
-cpumask_copy(v->cpu_hard_affinity_saved,
-   

[Xen-devel] [PATCH v4 3/6] xen: add new cpu notifier action CPU_RESUME_FAILED

[Juergen Gross]

Add a new cpu notifier action CPU_RESUME_FAILED which is called for all
cpus which failed to come up at resume. The calls will be done after
all other cpus are already up in order to know which resources are
available then.

Signed-off-by: Juergen Gross 
Reviewed-by: Dario Faggioli 
Reviewed-by: George Dunlap 
---
V2:
- added comment in xen/include/xen/cpu.h (Dario Faggioli)
---
 xen/common/cpu.c  |  5 +
 xen/include/xen/cpu.h | 29 ++---
 2 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 8bf69600a6..a6efc5e604 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -218,7 +218,12 @@ void enable_nonboot_cpus(void)
 printk("Error bringing CPU%d up: %d\n", cpu, error);
 BUG_ON(error == -EBUSY);
 }
+else
+__cpumask_clear_cpu(cpu, &frozen_cpus);
 }
 
+for_each_cpu ( cpu, &frozen_cpus )
+cpu_notifier_call_chain(cpu, CPU_RESUME_FAILED, NULL, true);
+
 cpumask_clear(&frozen_cpus);
 }
diff --git a/xen/include/xen/cpu.h b/xen/include/xen/cpu.h
index 2fe3ec05d8..4638c509e2 100644
--- a/xen/include/xen/cpu.h
+++ b/xen/include/xen/cpu.h
@@ -22,33 +22,40 @@ void register_cpu_notifier(struct notifier_block *nb);
  *  CPU_UP_PREPARE -> CPU_STARTING -> CPU_ONLINE -- successful CPU up
  *  CPU_DOWN_PREPARE -> CPU_DOWN_FAILED  -- failed CPU down
  *  CPU_DOWN_PREPARE -> CPU_DYING -> CPU_DEAD-- successful CPU down
- * 
+ * in the resume case we have additionally:
+ *  CPU_UP_PREPARE -> CPU_UP_CANCELLED -> CPU_RESUME_FAILED -- CPU not resumed
+ *  with the CPU_RESUME_FAILED handler called only after all CPUs have been
+ *  tried to put online again in order to know which CPUs did restart
+ *  successfully.
+ *
  * Hence note that only CPU_*_PREPARE handlers are allowed to fail. Also note
  * that once CPU_DYING is delivered, an offline action can no longer fail.
- * 
+ *
  * Notifiers are called highest-priority-first when:
  *  (a) A CPU is coming up; or (b) CPU_DOWN_FAILED
  * Notifiers are called lowest-priority-first when:
  *  (a) A CPU is going down; or (b) CPU_UP_CANCELED
  */
 /* CPU_UP_PREPARE: Preparing to bring CPU online. */
-#define CPU_UP_PREPARE   (0x0001 | NOTIFY_FORWARD)
+#define CPU_UP_PREPARE(0x0001 | NOTIFY_FORWARD)
 /* CPU_UP_CANCELED: CPU is no longer being brought online. */
-#define CPU_UP_CANCELED  (0x0002 | NOTIFY_REVERSE)
+#define CPU_UP_CANCELED   (0x0002 | NOTIFY_REVERSE)
 /* CPU_STARTING: CPU nearly online. Runs on new CPU, irqs still disabled. */
-#define CPU_STARTING (0x0003 | NOTIFY_FORWARD)
+#define CPU_STARTING  (0x0003 | NOTIFY_FORWARD)
 /* CPU_ONLINE: CPU is up. */
-#define CPU_ONLINE   (0x0004 | NOTIFY_FORWARD)
+#define CPU_ONLINE(0x0004 | NOTIFY_FORWARD)
 /* CPU_DOWN_PREPARE: CPU is going down. */
-#define CPU_DOWN_PREPARE (0x0005 | NOTIFY_REVERSE)
+#define CPU_DOWN_PREPARE  (0x0005 | NOTIFY_REVERSE)
 /* CPU_DOWN_FAILED: CPU is no longer going down. */
-#define CPU_DOWN_FAILED  (0x0006 | NOTIFY_FORWARD)
+#define CPU_DOWN_FAILED   (0x0006 | NOTIFY_FORWARD)
 /* CPU_DYING: CPU is nearly dead (in stop_machine context). */
-#define CPU_DYING(0x0007 | NOTIFY_REVERSE)
+#define CPU_DYING (0x0007 | NOTIFY_REVERSE)
 /* CPU_DEAD: CPU is dead. */
-#define CPU_DEAD (0x0008 | NOTIFY_REVERSE)
+#define CPU_DEAD  (0x0008 | NOTIFY_REVERSE)
 /* CPU_REMOVE: CPU was removed. */
-#define CPU_REMOVE   (0x0009 | NOTIFY_REVERSE)
+#define CPU_REMOVE(0x0009 | NOTIFY_REVERSE)
+/* CPU_RESUME_FAILED: CPU failed to come up in resume, all other CPUs up. */
+#define CPU_RESUME_FAILED (0x000a | NOTIFY_REVERSE)
 
 /* Perform CPU hotplug. May return -EAGAIN. */
 int cpu_down(unsigned int cpu);
-- 
2.16.4


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

[Xen-devel] [PATCH v4 2/6] xen: add helper for calling notifier_call_chain() to common/cpu.c

[Juergen Gross]

Add a helper cpu_notifier_call_chain() to call notifier_call_chain()
for a cpu with a specified action, returning an errno value.

This avoids coding the same pattern multiple times.

While at it avoid side effects from using BUG_ON() by not using
cpu_online(cpu) as a parameter.

Signed-off-by: Juergen Gross 
Reviewed-by: Dario Faggioli 
Acked-by: Jan Beulich 
---
V2:
- add nofail parameter to cpu_notifier_call_chain()
- avoid side effects from using BUG_ON() macro (Andrew Cooper)
---
 xen/common/cpu.c | 56 ++--
 1 file changed, 26 insertions(+), 30 deletions(-)

diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 836c62f97f..8bf69600a6 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -71,11 +71,21 @@ void __init register_cpu_notifier(struct notifier_block *nb)
 spin_unlock(&cpu_add_remove_lock);
 }
 
+static int cpu_notifier_call_chain(unsigned int cpu, unsigned long action,
+   struct notifier_block **nb, bool nofail)
+{
+void *hcpu = (void *)(long)cpu;
+int notifier_rc = notifier_call_chain(&cpu_chain, action, hcpu, nb);
+int ret = (notifier_rc == NOTIFY_DONE) ? 0 : 
notifier_to_errno(notifier_rc);
+
+BUG_ON(ret && nofail);
+
+return ret;
+}
+
 static void _take_cpu_down(void *unused)
 {
-void *hcpu = (void *)(long)smp_processor_id();
-int notifier_rc = notifier_call_chain(&cpu_chain, CPU_DYING, hcpu, NULL);
-BUG_ON(notifier_rc != NOTIFY_DONE);
+cpu_notifier_call_chain(smp_processor_id(), CPU_DYING, NULL, true);
 __cpu_disable();
 }
 
@@ -87,8 +97,7 @@ static int take_cpu_down(void *arg)
 
 int cpu_down(unsigned int cpu)
 {
-int err, notifier_rc;
-void *hcpu = (void *)(long)cpu;
+int err;
 struct notifier_block *nb = NULL;
 
 if ( !cpu_hotplug_begin() )
@@ -100,12 +109,9 @@ int cpu_down(unsigned int cpu)
 return -EINVAL;
 }
 
-notifier_rc = notifier_call_chain(&cpu_chain, CPU_DOWN_PREPARE, hcpu, &nb);
-if ( notifier_rc != NOTIFY_DONE )
-{
-err = notifier_to_errno(notifier_rc);
+err = cpu_notifier_call_chain(cpu, CPU_DOWN_PREPARE, &nb, false);
+if ( err )
 goto fail;
-}
 
 if ( unlikely(system_state < SYS_STATE_active) )
 on_selected_cpus(cpumask_of(cpu), _take_cpu_down, NULL, true);
@@ -113,26 +119,24 @@ int cpu_down(unsigned int cpu)
 goto fail;
 
 __cpu_die(cpu);
-BUG_ON(cpu_online(cpu));
+err = cpu_online(cpu);
+BUG_ON(err);
 
-notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
-BUG_ON(notifier_rc != NOTIFY_DONE);
+cpu_notifier_call_chain(cpu, CPU_DEAD, NULL, true);
 
 send_global_virq(VIRQ_PCPU_STATE);
 cpu_hotplug_done();
 return 0;
 
  fail:
-notifier_rc = notifier_call_chain(&cpu_chain, CPU_DOWN_FAILED, hcpu, &nb);
-BUG_ON(notifier_rc != NOTIFY_DONE);
+cpu_notifier_call_chain(cpu, CPU_DOWN_FAILED, &nb, true);
 cpu_hotplug_done();
 return err;
 }
 
 int cpu_up(unsigned int cpu)
 {
-int notifier_rc, err = 0;
-void *hcpu = (void *)(long)cpu;
+int err;
 struct notifier_block *nb = NULL;
 
 if ( !cpu_hotplug_begin() )
@@ -144,19 +148,15 @@ int cpu_up(unsigned int cpu)
 return -EINVAL;
 }
 
-notifier_rc = notifier_call_chain(&cpu_chain, CPU_UP_PREPARE, hcpu, &nb);
-if ( notifier_rc != NOTIFY_DONE )
-{
-err = notifier_to_errno(notifier_rc);
+err = cpu_notifier_call_chain(cpu, CPU_UP_PREPARE, &nb, false);
+if ( err )
 goto fail;
-}
 
 err = __cpu_up(cpu);
 if ( err < 0 )
 goto fail;
 
-notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
-BUG_ON(notifier_rc != NOTIFY_DONE);
+cpu_notifier_call_chain(cpu, CPU_ONLINE, NULL, true);
 
 send_global_virq(VIRQ_PCPU_STATE);
 
@@ -164,18 +164,14 @@ int cpu_up(unsigned int cpu)
 return 0;
 
  fail:
-notifier_rc = notifier_call_chain(&cpu_chain, CPU_UP_CANCELED, hcpu, &nb);
-BUG_ON(notifier_rc != NOTIFY_DONE);
+cpu_notifier_call_chain(cpu, CPU_UP_CANCELED, &nb, true);
 cpu_hotplug_done();
 return err;
 }
 
 void notify_cpu_starting(unsigned int cpu)
 {
-void *hcpu = (void *)(long)cpu;
-int notifier_rc = notifier_call_chain(
-&cpu_chain, CPU_STARTING, hcpu, NULL);
-BUG_ON(notifier_rc != NOTIFY_DONE);
+cpu_notifier_call_chain(cpu, CPU_STARTING, NULL, true);
 }
 
 static cpumask_t frozen_cpus;
-- 
2.16.4


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

Re: [Xen-devel] [PATCH v4 04/15] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Pu Wen]

On 2019/4/2 23:50, Jan Beulich wrote:
 On 02.04.19 at 14:11,  wrote:
>> By the way, how about the patch 01/15 of this series?
>> If it's fine, could you please offer Acked-by tag for it?
> 
> I've yet to look at v4 of it.

Andrew said the change of patch 01/15 should rebase over
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e72309ffbe7c4e507649c74749f130cda691131c
.

So I think I'll rework the patch first.

Thx.

-- 
Regards,
Pu Wen

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

[Xen-devel] [PATCH 1/4] xen/console: Properly buffer domU output when using CONSOLEIO_write

[Julien Grall]

The output will be buffered if the buffer provided by the DomU does not
contain a newline. This can also happen if buffer provided by DomU is
split in multiple part (Xen can only process 127 characters at the time).

As Xen will remove any non-printable characters, the output buffer may
be smaller than the buffer provided. However, Xen will buffer using the
original length. This means that the NUL character and garbagge will be
copied in the internal buffer.

Once the newline is found or the internal buffer is full, only part of
the internal buffer will end up to be printed.

An easy way to reproduce it is:

HYPERVISOR_consoleio(CONSOLEIO_write, "\33", 1);
HYPERVISOR_consoleio(CONSOLEIO_write, "d", 1);
HYPERVISOR_consoleio(CONSOLEIO_write, "\n", 1);

In the current code, the character 'd' will not be printed.

This problem can be solved by computing the size of the output buffer
(i.e the buffer without the non-printable characters).

Signed-off-by: Julien Grall 

---

I is possible to compute (kout - kbuf) only once. I didn't do it because
I wasn't able to find a good name.
---
 xen/drivers/char/console.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 5f0f54201b..9bbcb0f57a 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -592,11 +592,11 @@ static long 
guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, int count)
 guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
 cd->pbuf_idx = 0;
 }
-else if ( cd->pbuf_idx + kcount < (DOMAIN_PBUF_SIZE - 1) )
+else if ( cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1) )
 {
 /* buffer the output until a newline */
-memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kcount);
-cd->pbuf_idx += kcount;
+memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
+cd->pbuf_idx += (kout - kbuf);
 }
 else
 {
-- 
2.11.0


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

[Xen-devel] [PATCH 4/4] xen/console: Simplify domU console handling in guest_console_write

[Julien Grall]

2 paths in the domU console handling are now the same. So they can be
merged to make the code simpler.

Signed-off-by: Julien Grall 
---
 xen/drivers/char/console.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index b119bf980b..5483d66512 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -584,13 +584,8 @@ static long 
guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, int count)
 *kout = '\0';
 spin_lock(&cd->pbuf_lock);
 kcount = kin - kbuf;
-if ( c == '\n' )
-{
-cd->pbuf[cd->pbuf_idx] = '\0';
-guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
-cd->pbuf_idx = 0;
-}
-else if ( cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1) )
+if ( c != '\n' &&
+(cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
 {
 /* buffer the output until a newline */
 memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
-- 
2.11.0


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

[Xen-devel] [PATCH 0/4] xen/console: Bug fixes and doc improvement

[Julien Grall]

Hi all,

This series contains a bunch of bug fixes for the hypercall CONSOLEIO_write
and some documentation.

Note the patch #2 was originally sent in standalone, I have included here
with comments addressed to keep everything together.

Cheers,

Julien Grall (4):
  xen/console: Properly buffer domU output when using CONSOLEIO_write
  xen/console: Don't treat NUL character as the end of the buffer
  xen/public: Document HYPERCALL_console_io()
  xen/console: Simplify domU console handling in guest_console_write

 xen/arch/arm/early_printk.c   |  5 +--
 xen/common/gdbstub.c  |  6 ++--
 xen/drivers/char/console.c| 71 ++-
 xen/drivers/char/consoled.c   |  7 ++--
 xen/drivers/char/serial.c |  8 +++--
 xen/drivers/char/xen_pv_console.c | 10 +++---
 xen/drivers/video/lfb.c   | 14 
 xen/drivers/video/lfb.h   |  4 +--
 xen/drivers/video/vga.c   | 14 
 xen/include/public/xen.h  | 21 +++-
 xen/include/xen/console.h |  2 +-
 xen/include/xen/early_printk.h|  2 +-
 xen/include/xen/pv_console.h  |  4 +--
 xen/include/xen/serial.h  |  4 +--
 xen/include/xen/video.h   |  4 +--
 15 files changed, 97 insertions(+), 79 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH 2/4] xen/console: Don't treat NUL character as the end of the buffer

[Julien Grall]

After upgrading Debian to Buster, I have began to notice console
mangling when using zsh in Dom0. This is happenning because output sent by
zsh to the console may contain NULs in the middle of the buffer.

The actual implementation of CONSOLEIO_write considers that a buffer
always terminate with a NUL and therefore will ignore anything after it.

In general, NULs are perfectly legitimate in terminal streams. For
instance, this could be used for padding slow terminals. See terminfo(5)
section `Delays and Padding`, or search for the pcre '\bpad'.

Other use cases includes using the console for dumping non-human
readable information (e.g debugger, file if no network...). With the
current behavior, the resulting stream will end up to be corrupted.

The documentation for CONSOLEIO_write is pretty limited (to not say
inexistent). From the declaration, the hypercall takes a buffer and size.
So this could lead to think the NUL character is allowed in the middle of
the buffer.

This patch updates the console API to pass the size along the buffer
down so we can remove the reliance on buffer terminating by a NUL
character.

Signed-off-by: Julien Grall 

---

This patch was originally sent standalone [1]. But the series grows to
include another bug found in the console code and documentation.

Change since the standalone version:
- Fix early printk on Arm
- Fix gdbstub
- Remove unecessary leading NUL character added by Xen
- Handle DomU console
- Rework the commit message

Below a small C program to repro the bug on Xen:

int main(void)
{
write(1,
  
"\r\33[0m\0\0\0\0\0\0\0\0\33[27m\33[24m\33[j\33[32mjulien\33[31m@\33[00m\33[36mjuno2-julieng:~\33[37m>",
  75);
write(1,
  "\33[K\33[32C\33[01;33m--juno2-julieng-13:44--\33[00m\33[37m\33[55D",
  54);
write(1, "\33[?2004h", 8);

return 0;
}

Without this patch, the only --juno2-julieng-13:44-- will be printed in
yellow.

This patch was tested on Arm using serial console. I am not entirely
sure whether the video and PV console is correct. I would appreciate help
for testing here.

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-02/msg01932.html
---
 xen/arch/arm/early_printk.c   |  5 ++--
 xen/common/gdbstub.c  |  6 ++--
 xen/drivers/char/console.c| 58 +++
 xen/drivers/char/consoled.c   |  7 ++---
 xen/drivers/char/serial.c |  8 --
 xen/drivers/char/xen_pv_console.c | 10 +++
 xen/drivers/video/lfb.c   | 14 ++
 xen/drivers/video/lfb.h   |  4 +--
 xen/drivers/video/vga.c   | 14 ++
 xen/include/xen/console.h |  2 +-
 xen/include/xen/early_printk.h|  2 +-
 xen/include/xen/pv_console.h  |  4 +--
 xen/include/xen/serial.h  |  4 +--
 xen/include/xen/video.h   |  4 +--
 14 files changed, 73 insertions(+), 69 deletions(-)

diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
index 97466a12b1..35a47c7229 100644
--- a/xen/arch/arm/early_printk.c
+++ b/xen/arch/arm/early_printk.c
@@ -17,9 +17,10 @@
 void early_putch(char c);
 void early_flush(void);
 
-void early_puts(const char *s)
+void early_puts(const char *s, unsigned int nr)
 {
-while (*s != '\0') {
+while ( nr-- > 0 )
+{
 if (*s == '\n')
 early_putch('\r');
 early_putch(*s);
diff --git a/xen/common/gdbstub.c b/xen/common/gdbstub.c
index 07095e1ec7..08a4dda9f3 100644
--- a/xen/common/gdbstub.c
+++ b/xen/common/gdbstub.c
@@ -68,7 +68,7 @@ static void gdb_smp_resume(void);
 static char __initdata opt_gdb[30];
 string_param("gdb", opt_gdb);
 
-static void gdbstub_console_puts(const char *str);
+static void gdbstub_console_puts(const char *str, unsigned int nr);
 
 /* value <-> char (de)serialzers */
 static char
@@ -546,14 +546,14 @@ __gdb_ctx = {
 static struct gdb_context *gdb_ctx = &__gdb_ctx;
 
 static void
-gdbstub_console_puts(const char *str)
+gdbstub_console_puts(const char *str, unsigned int nr)
 {
 const char *p;
 
 gdb_start_packet(gdb_ctx);
 gdb_write_to_packet_char('O', gdb_ctx);
 
-for ( p = str; *p != '\0'; p++ )
+for ( p = str; nr > 0; p++, nr-- )
 {
 gdb_write_to_packet_char(hex2char((*p>>4) & 0x0f), gdb_ctx );
 gdb_write_to_packet_char(hex2char((*p) & 0x0f), gdb_ctx );
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9bbcb0f57a..b119bf980b 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -325,9 +325,9 @@ long read_console_ring(struct xen_sysctl_readconsole *op)
 static char serial_rx_ring[SERIAL_RX_SIZE];
 static unsigned int serial_rx_cons, serial_rx_prod;
 
-static void (*serial_steal_fn)(const char *) = early_puts;
+static void (*serial_steal_fn)(const char *, unsigned int nr) = early_puts;
 
-int console_steal(int handle, void (*fn)(const char *))
+int console_steal(int handle, void (*fn)(const char *, unsigned int nr))
 {
 if ( 

[Xen-devel] [PATCH 3/4] xen/public: Document HYPERCALL_console_io()

[Julien Grall]

Currently, OS developpers will have to look at Xen code in order to know
the parameters of an hypercall and how it is meant to work.

This is not a trivial task as you may need to have a deep understanding
of Xen internal.

This patch attempts to document the behavior of HYPERCALL_console_io() to
help OS developer.

Signed-off-by: Julien Grall 

---

This is a first attempt to address the lack on documentation for
hypercalls. We may want to decide a format to use in every hypercall so
it can be readable for the OS developer and easily consummed by
documentation tools.
---
 xen/include/public/xen.h | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index ccdffc0ad1..7c119c6782 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -97,6 +97,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #define __HYPERVISOR_set_timer_op 15
 #define __HYPERVISOR_event_channel_op_compat 16 /* compat since 0x00030202 */
 #define __HYPERVISOR_xen_version  17
+/* HYPERVISOR_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer); */
 #define __HYPERVISOR_console_io   18
 #define __HYPERVISOR_physdev_op_compat19 /* compat since 0x00030202 */
 #define __HYPERVISOR_grant_table_op   20
@@ -486,7 +487,25 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
 /* ` } */
 
 /*
- * Commands to HYPERVISOR_console_io().
+ * Commands to HYPERVISOR_console_io()
+ *
+ * @cmd: Command (see below)
+ * @count: Size of the buffer to read/write
+ * @buffer: Pointer in the guest memory
+ *
+ * List of commands:
+ *
+ *  * CONSOLEIO_write: Write the buffer on Xen console.
+ *  For the hardware domain, all the characters in the buffer will
+ *  be written. Characters will be printed to directly to the
+ *  console.
+ *  For all the other domains, only the printable characters will be
+ *  written. Characters may be buffered until a newline (i.e '\n') is
+ *  found.
+ *  Return 0 on success, otherwise return an error code.
+ *  * CONSOLE_read: Attempts to read up @count characters from Xen console.
+ *  Return the number of character read on success, otherwise return
+ *  an error code.
  */
 #define CONSOLEIO_write 0
 #define CONSOLEIO_read  1
-- 
2.11.0


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

[Xen-devel] [PATCH v2] public/io/blkif.h: try to fix the semantics of sector based quantities

[Paul Durrant]

This is actually v2 of the patch posted in [1]. Please see the thread
starting there for more context...

The semantics of sector based quanties, such as first_sect and last_sect in
blkif_request_segment, and the value of "sectors" in the backend info
in xenstore have become confused. Some comments in the header suggest they
should be supplied/interpreted strictly in terms of 512-byte units, others
suggest they should be scaled by the value of "sector-size" i.e. the
logical block size of the underlying backend storage.
This confusion has caused mixed semantics to become ingrained in frontend
implementations. For instance Linux xen-blkfront.c contains code such as:

fsect = offset >> 9;
lsect = fsect + (len >> 9) - 1;

whereas the Windows XENVBD frontend contains the following equivalent code:

Segment->FirstSector = (UCHAR)((Offset + SectorSize - 1) / SectorSize);
*SectorsNow = __min(SectorsLeft, SectorsPerPage - Segment->FirstSector);
Segment->LastSector = (UCHAR)(Segment->FirstSector + *SectorsNow - 1);

(where SectorSize is the "sector-size" value advertized in xenstore).

Thus it has become unsafe for a backend to set "sector-size" to anything
other than 512 as it does not know which way the frontend is coded.

This patch is intended to clarify the situation and also introduce a
mechanism to allow logical block sizes of more than 512 to be supported...

A new frontend feature node is specified: 'feature-large-sector-size'.
If this node is present and set to "1" then it means that frontend is
coded to supply and interpret all sector based quantities in terms of the
the advertized "sector-size" value rather than a hardcoded size of 512.

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg01600.html

Signed-off-by: Paul Durrant 
---
Cc: Konrad Rzeszutek Wilk 
Cc: Roger Pau Monné 
Cc: Athony PERARD 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v2:
 - Drop Konrad's original ack since the patch has substantially changed
 - Cc several different OS blkfront maintainers and 'the rest' maintainers
   for more opinion
---
 xen/include/public/io/blkif.h | 40 ++-
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
index 15a71e3fea..d4a34de94c 100644
--- a/xen/include/public/io/blkif.h
+++ b/xen/include/public/io/blkif.h
@@ -254,18 +254,26 @@
  * sector-size
  *  Values: 
  *
- *  The logical sector size, in bytes, of the backend device.
+ *  The logical block size, in bytes, of the underlying storage. This
+ *  must be a power of two with a minimum value of 512.
+ *
+ *  NOTE: Because of implementation bugs in some frontends this must be
+ *set to 512, unless the frontend advertizes a non-zero value
+ *in its "feature-large-sector-size" xenbus node. (See below).
  *
  * physical-sector-size
  *  Values: 
+ *  Default Value:  <"sector-size">
  *
- *  The physical sector size, in bytes, of the backend device.
+ *  The physical block size, in bytes, of the backend storage. This
+ *  must be an integer multiple of "sector-size".
  *
  * sectors
  *  Values: 
  *
- *  The size of the backend device, expressed in units of its logical
- *  sector size ("sector-size").
+ *  The size of the backend device, expressed in units of "sector-size".
+ *  The product of "sector-size" and "sectors" must also be an integer
+ *  multiple of "physical-sector-size", if that node is present.
  *
  *
  *Frontend XenBus Nodes
@@ -321,6 +329,8 @@
  *  The size of the frontend allocated request ring buffer in units of
  *  machine pages.  The value must be a power of 2.
  *
+ *- Features -
+ *
  * feature-persistent
  *  Values: 0/1 (boolean)
  *  Default Value:  0
@@ -342,6 +352,17 @@
  *  decides to limit the maximum number of persistently mapped grants
  *  to a value less than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST.
  *
+ * feature-large-sector-size
+ *  Values: 0/1 (boolean)
+ *  Default Value:  0
+ *
+ *  A value of "1" indicates that the frontend will correctly supply and
+ *  interpret all sector-based quantities in terms of the "sector-size"
+ *  value supplied in the backend info, whatever that may be set to.
+ *  If this node is not present or its value is "0" then it is assumed
+ *  that the frontend requires that the logical block size is 512 as it
+ *  is hardcoded (which is the case in some frontend implementations).
+ *
  *- Virtual Device Properties -
  *
  * device-type
@@ -607,12 +628,11 

Re: [Xen-devel] [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Andrew Cooper]

On 02/04/2019 17:14, Pu Wen wrote:
> On 2019/4/2 23:46, Jan Beulich wrote:
>> On 02.04.19 at 13:58,  wrote:
>>> On 2019/4/2 18:20, Jan Beulich wrote:
 On 02.04.19 at 08:46,  wrote:
> On 2019/4/1 16:41, Jan Beulich wrote:
>> On 30.03.19 at 11:42,  wrote:
>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families.
>>> So directly
>>> return false in the function probe_cpuid_faulting() if
>>> !cpu_has_hypervisor.
>>
>> I think it would have been nice if you had mentioned the real
>> reason why you want to bypass the MSR accesses. This way it
>> sounds as if the change was only cosmetic, and hence could be
>> left out.
>
> Okay, how about the new description:
> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
> this MSR will stop the Xen initialization process

 "... for some early Hygon steppings"(?). I'm unaware of AMD CPUs
>>>
>>> Yes,for some early Hygon steppings.
>>>
 having this issue - are you telling us otherwise?
>>>
>>> I tested with an AMD CPU(Family 17h, Model 1, Stepping 1) today, and
>>> it also stopped when reading the MSR_INTEL_PLATFORM_INFO instead of
>>> producing #GP(0).
>>
>> I've yet to try it out on my Rome system, but I have to admit I
>
> We have Rome system too, I'll have a try on it as well.

I've just spoken to a contact at AMD, and they've never encountered an
issue like this.

If it behaviour does manifest, then it is very concerning.

~Andrew

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

Re: [Xen-devel] [PATCH 2/4] xen/console: Don't treat NUL character as the end of the buffer

[Andrew Cooper]

On 02/04/2019 17:42, Julien Grall wrote:
> diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
> index 97466a12b1..35a47c7229 100644
> --- a/xen/arch/arm/early_printk.c
> +++ b/xen/arch/arm/early_printk.c
> @@ -17,9 +17,10 @@
>  void early_putch(char c);
>  void early_flush(void);
>  
> -void early_puts(const char *s)
> +void early_puts(const char *s, unsigned int nr)

size_t here and elsewhere please, because...

> @@ -666,16 +664,16 @@ static bool_t console_locks_busted;
>  
>  static void __putstr(const char *str)
>  {
> +size_t len = strlen(str);
> +
>  ASSERT(spin_is_locked(&console_lock));
>  
> -sercon_puts(str);
> -video_puts(str);
> +sercon_puts(str, len);
> +video_puts(str, len);

... this introduces a truncation bug for 64bit builds.

I don't expect a 4G buffer to be passed, but it is not worth introducing
the possibility for such a subtle bug in the first place.

~Andrew

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

[Xen-devel] [xen-unstable-smoke test] 134287: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  a57a1b26ec0ae31f924cf2bbcf479637d007be44
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   11 days
Failing since134068  2019-03-25 12:00:51 Z8 days   34 attempts
Testing same since   134287  2019-04-02 09:00:34 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  Jan Beulich 
  Juergen Gross 
  M A Young 
  Wei Liu 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit a57a1b26ec0ae31f924cf2bbcf479637d007be44
Author: Wei Liu 
Date:   Mon Apr 1 11:32:38 2019 +0100

tools/ocaml: make python scripts 2 and 3 compatible

1. Explicitly import reduce because that's required in 3.
2. Change print to function.
3. Eliminate invocations of has_key.

Signed-off-by: M A Young 
Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 
Acked-by: Christian Lindig 

commit ff915c8cacc264ae1380d51fea07267b8308d7ba
Author: Wei Liu 
Date:   Mon Apr 1 11:32:37 2019 +0100

pygrub: encode / decode string in Python 3

String is unicode in 3 but bytes in 2. We need to call encode / decode
function when using Python 3.

Reported-by: M A Young 
Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 767ba397d34848c7e0c4e9cdfc5efa4e0cb61442
Author: Wei Liu 
Date:   Mon Apr 1 11:32:36 2019 +0100

pygrub/grub: always use integer for default entry

The original code set the default to either a string or an integer
(0) and relies on a Python 2 specific behaviour to work (integer is
allowed to be compared to string in Python 2 but not 3).

Always use integer. The caller (pygrub) already has code to handle
that.

Reported-by: M A Young 
Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 485079e816788d70169f45579e1f5a8f909dc1b3
Author: Wei Liu 
Date:   Mon Apr 1 11:32:35 2019 +0100

pygrub: fix message in grub parser

The code suggests 0 is allowed. Zero is not a positive number.

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 905d7340f6d0abfbf986cede6e535c51ab1de3c3
Author: Andrew Cooper 
Date:   Mon Apr 1 10:08:43 2019 +

xen/sched: Remove d->is_pinned

The is_pinned field is rather odd.  It can only be activated with the
"dom0_vcpus_pin" command line option, and causes dom0 (or the late hwdom) to
have its vcpus identity pinned to pcpus.

Having dom0_vcpus_pin active disallows the use of vcpu_set_hard_affinity().
However, when a pcpu is offlined, or moved between cpupools, the affinity is
broken and reverts to cpumask_all.  This results in vcpus which are no 
longer
pinned, and cannot be adjusted.

A related bit of functionality is the is_pinned_vcpu() predicate.  This is
only used by x86 code, and permits the use of VCPUOP_

[Xen-devel] [linux-4.19 test] 134224: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64   4 host-install(4)broken REGR. vs. 129313
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 129313
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 129313
 test-armhf-armhf-xl-credit1  broken  in 134165
 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 134165 REGR. vs. 
129313

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit1  4 host-install(4) broken in 134165 pass in 134139
 test-armhf-armhf-xl-vhd   6 xen-install  fail in 134139 pass in 134165
 test-amd64-amd64-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail pass in 
134165

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1 13 migrate-support-check fail in 134139 never pass
 test-armhf-armhf-xl-credit1 14 saverestore-support-check fail in 134139 never 
pass
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 134165 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 134165 never 
pass
 test-armhf-armhf-xl 13 migrate-support-check fail in 134165 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 134165 never pass
 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 134165 never pass
 test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 134165 never 
pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 134165 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 134165 
never pass
 test-armhf-armhf-libvirt13 migrate-support-check fail in 134165 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 134165 never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 134165 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 134165 
never pass
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 134165 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 134165 never pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 134165 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 134165 never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fa

[Xen-devel] [PATCH 1/3] xen/cpu: Distinguish "cpu already in that state" in cpu_{up, down}()

[Andrew Cooper]

All methods of querying the online state of a CPU are racy without the hotplug
lock held, which can lead to a TOCTOU race trying to online or offline CPUs.

Distinguish this case with -EEXIST rather than -EINVAL, so the caller can take
other actions if necessary.

While adjusting this, rework the code slightly to fold the exit paths, which
results in a minor reduction in compiled code size.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
---
 xen/common/cpu.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 836c62f..1829318 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -94,11 +94,13 @@ int cpu_down(unsigned int cpu)
 if ( !cpu_hotplug_begin() )
 return -EBUSY;
 
-if ( (cpu >= nr_cpu_ids) || (cpu == 0) || !cpu_online(cpu) )
-{
-cpu_hotplug_done();
-return -EINVAL;
-}
+err = -EINVAL;
+if ( (cpu >= nr_cpu_ids) || (cpu == 0) )
+goto out;
+
+err = -EEXIST;
+if ( !cpu_online(cpu) )
+goto out;
 
 notifier_rc = notifier_call_chain(&cpu_chain, CPU_DOWN_PREPARE, hcpu, &nb);
 if ( notifier_rc != NOTIFY_DONE )
@@ -125,6 +127,7 @@ int cpu_down(unsigned int cpu)
  fail:
 notifier_rc = notifier_call_chain(&cpu_chain, CPU_DOWN_FAILED, hcpu, &nb);
 BUG_ON(notifier_rc != NOTIFY_DONE);
+ out:
 cpu_hotplug_done();
 return err;
 }
@@ -138,11 +141,13 @@ int cpu_up(unsigned int cpu)
 if ( !cpu_hotplug_begin() )
 return -EBUSY;
 
-if ( (cpu >= nr_cpu_ids) || cpu_online(cpu) || !cpu_present(cpu) )
-{
-cpu_hotplug_done();
-return -EINVAL;
-}
+err = -EINVAL;
+if ( (cpu >= nr_cpu_ids) || !cpu_present(cpu) )
+goto out;
+
+err = -EEXIST;
+if ( cpu_online(cpu) )
+goto out;
 
 notifier_rc = notifier_call_chain(&cpu_chain, CPU_UP_PREPARE, hcpu, &nb);
 if ( notifier_rc != NOTIFY_DONE )
@@ -166,6 +171,7 @@ int cpu_up(unsigned int cpu)
  fail:
 notifier_rc = notifier_call_chain(&cpu_chain, CPU_UP_CANCELED, hcpu, &nb);
 BUG_ON(notifier_rc != NOTIFY_DONE);
+ out:
 cpu_hotplug_done();
 return err;
 }
-- 
2.1.4


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

[Xen-devel] [PATCH 3/3] x86/smt: Support for enabling/disabling SMT at runtime

[Andrew Cooper]

Currently, a user can in combine the output of `xl info -n`, the APCI tables,
and some manual CPUID data to figure out which CPU numbers to feed into
`xen-hptool cpu-offline` to effectively disable SMT at runtime.

A more convenient option is to teach Xen how to perform this action.

First of all, extend XEN_SYSCTL_cpu_hotplug with two new operations.
Introduce new smt_{up,down}_helper() functions which wrap the
cpu_{up,down}_helper() helpers with logic which understands siblings based on
their APIC_ID.

Add libxc stubs, and extend xen-hptool with smt-{enable,disable} options.
These are intended to be shorthands for a loop over cpu-{online,offline}.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 

Slightly RFC.  I'm not very happy with the contination situation, but -EBUSY
is the preexisting style and it seems like it is the only option from tasklet
context.

Is it intentional that we can actually online and offline processors beyond
maxcpu?  This is a consequence of the cpu parking logic.
---
 tools/libxc/include/xenctrl.h   |  2 +
 tools/libxc/xc_cpu_hotplug.c| 26 +++
 tools/misc/xen-hptool.c | 56 
 xen/arch/x86/setup.c|  2 +-
 xen/arch/x86/sysctl.c   | 96 +
 xen/include/asm-x86/processor.h |  1 +
 xen/include/public/sysctl.h |  9 
 7 files changed, 191 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index a3628e5..49a6b2a 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1854,6 +1854,8 @@ int xc_pm_reset_cxstat(xc_interface *xch, int cpuid);
 
 int xc_cpu_online(xc_interface *xch, int cpu);
 int xc_cpu_offline(xc_interface *xch, int cpu);
+int xc_smt_enable(xc_interface *xch);
+int xc_smt_disable(xc_interface *xch);
 
 /* 
  * cpufreq para name of this structure named 
diff --git a/tools/libxc/xc_cpu_hotplug.c b/tools/libxc/xc_cpu_hotplug.c
index 58c2a0f..2ea9825 100644
--- a/tools/libxc/xc_cpu_hotplug.c
+++ b/tools/libxc/xc_cpu_hotplug.c
@@ -46,3 +46,29 @@ int xc_cpu_offline(xc_interface *xch, int cpu)
 return ret;
 }
 
+int xc_smt_enable(xc_interface *xch)
+{
+DECLARE_SYSCTL;
+int ret;
+
+sysctl.cmd = XEN_SYSCTL_cpu_hotplug;
+sysctl.u.cpu_hotplug.cpu = 0;
+sysctl.u.cpu_hotplug.op = XEN_SYSCTL_CPU_HOTPLUG_SMT_ENABLE;
+ret = xc_sysctl(xch, &sysctl);
+
+return ret;
+}
+
+int xc_smt_disable(xc_interface *xch)
+{
+DECLARE_SYSCTL;
+int ret;
+
+sysctl.cmd = XEN_SYSCTL_cpu_hotplug;
+sysctl.u.cpu_hotplug.cpu = 0;
+sysctl.u.cpu_hotplug.op = XEN_SYSCTL_CPU_HOTPLUG_SMT_DISABLE;
+ret = xc_sysctl(xch, &sysctl);
+
+return ret;
+}
+
diff --git a/tools/misc/xen-hptool.c b/tools/misc/xen-hptool.c
index 40cd966..6e27d9c 100644
--- a/tools/misc/xen-hptool.c
+++ b/tools/misc/xen-hptool.c
@@ -19,6 +19,8 @@ void show_help(void)
 "  mem-online  online MEMORY \n"
 "  mem-offline offline MEMORY \n"
 "  mem-status  query Memory status\n"
+"  smt-enable   onlines all SMT threads\n"
+"  smt-disable  offlines all SMT threads\n"
);
 }
 
@@ -304,6 +306,58 @@ static int hp_cpu_offline_func(int argc, char *argv[])
 return ret;
 }
 
+static int main_smt_enable(int argc, char *argv[])
+{
+int ret;
+
+if ( argc )
+{
+show_help();
+return -1;
+}
+
+for ( ;; )
+{
+ret = xc_smt_enable(xch);
+if ( (ret >= 0) || (errno != EBUSY) )
+break;
+}
+
+if ( ret < 0 )
+fprintf(stderr, "Unable to enable SMT: errno %d, %s\n",
+errno, strerror(errno));
+else
+printf("Enabled SMT\n");
+
+return ret;
+}
+
+static int main_smt_disable(int argc, char *argv[])
+{
+int ret;
+
+if ( argc )
+{
+show_help();
+return -1;
+}
+
+for ( ;; )
+{
+ret = xc_smt_disable(xch);
+if ( (ret >= 0) || (errno != EBUSY) )
+break;
+}
+
+if ( ret < 0 )
+fprintf(stderr, "Unable to disable SMT: errno %d, %s\n",
+errno, strerror(errno));
+else
+printf("Disabled SMT\n");
+
+return ret;
+}
+
 struct {
 const char *name;
 int (*function)(int argc, char *argv[]);
@@ -314,6 +368,8 @@ struct {
 { "mem-status", hp_mem_query_func},
 { "mem-online", hp_mem_online_func},
 { "mem-offline", hp_mem_offline_func},
+{ "smt-enable", main_smt_enable },
+{ "smt-disable", main_smt_disable },
 };
 
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 3440794..af245eb 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -60,7 +60,7 @@ static bool __initdata opt_nosmp;
 boolean_param("nosmp", opt_nosmp);
 
 /* maxcpus: maximum number of CPUs to activate. */
-static unsigned int __initdata max_cpus;
+unsigned int 

[Xen-devel] [PATCH 2/3] x86/sysctl: Clean up XEN_SYSCTL_cpu_hotplug

[Andrew Cooper]

A future change is going to introduce two more cases.  Instead of opcoding the
XSM checks and contine_hypercall logic, collect the data into local variables.

Switch the default return value to -EOPNOTSUPP to distinguish a bad op from a
bad cpu index.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
---
 xen/arch/x86/sysctl.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 1916a3d..b3cc4b5 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -137,27 +137,35 @@ long arch_do_sysctl(
 case XEN_SYSCTL_cpu_hotplug:
 {
 unsigned int cpu = sysctl->u.cpu_hotplug.cpu;
+bool plug;
+long (*fn)(void *) = NULL;
+void *hcpu = NULL;
 
 switch ( sysctl->u.cpu_hotplug.op )
 {
 case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
-ret = xsm_resource_plug_core(XSM_HOOK);
-if ( ret )
-break;
-ret = continue_hypercall_on_cpu(
-0, cpu_up_helper, (void *)(unsigned long)cpu);
+plug = true;
+fn = cpu_up_helper;
+hcpu = (void *)(unsigned long)cpu;
 break;
+
 case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE:
-ret = xsm_resource_unplug_core(XSM_HOOK);
-if ( ret )
-break;
-ret = continue_hypercall_on_cpu(
-0, cpu_down_helper, (void *)(unsigned long)cpu);
+plug = false;
+fn = cpu_down_helper;
+hcpu = (void *)(unsigned long)cpu;
 break;
+
 default:
-ret = -EINVAL;
+ret = -EOPNOTSUPP;
 break;
 }
+
+if ( !ret )
+ret = plug ? xsm_resource_plug_core(XSM_HOOK)
+   : xsm_resource_unplug_core(XSM_HOOK);
+
+if ( !ret )
+ret = continue_hypercall_on_cpu(0, fn, hcpu);
 }
 break;
 
-- 
2.1.4


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

[Xen-devel] [PATCH 0/3] x86/smt: Runtime SMT controls

[Andrew Cooper]

This is some work which was discussed for L1TF and never got finished.
Testing for this work is what discovered the cpu online/offline memory leak.

Andrew Cooper (3):
  xen/cpu: Distinguish "cpu already in that state" in cpu_{up,down}()
  x86/sysctl: Clean up XEN_SYSCTL_cpu_hotplug
  x86: Support for enabling/disabling SMT at runtime

 tools/libxc/include/xenctrl.h   |   2 +
 tools/libxc/xc_cpu_hotplug.c|  26 +
 tools/misc/xen-hptool.c |  56 ++
 xen/arch/x86/setup.c|   2 +-
 xen/arch/x86/sysctl.c   | 126 
 xen/common/cpu.c|  26 +
 xen/include/asm-x86/processor.h |   1 +
 xen/include/public/sysctl.h |   9 +++
 8 files changed, 226 insertions(+), 22 deletions(-)

-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 1/3] xen/arm: Add Amlogic Meson SoCs earlyprintk support

[André Przywara]

On 21/03/2019 10:25, Amit Singh Tomar wrote:
> Signed-off-by: Amit Singh Tomar 

Apart from the missing commit message:

Reviewed-by: Andre Przywara 
Tested-by: Andre Przywara 

Cheers,
Andre.

> ---
> TODO:
> * Capture XEN boot info on WIKI.
> 
> Changes since v1:
> 
> * Fixed coding style issue.
> * Undone changes in early-printk.txt.
> 
> Changes since RFC:
> 
> * Replaced LDRH with LDR, with this there
>   is no scattered output on console now.
> * Used tbnz instead of tst and b.ne.
> * Used AML_ prefix against register names.
> ---
>  xen/arch/arm/arm64/debug-meson.inc | 51 
> ++
>  1 file changed, 51 insertions(+)
>  create mode 100644 xen/arch/arm/arm64/debug-meson.inc
> 
> diff --git a/xen/arch/arm/arm64/debug-meson.inc 
> b/xen/arch/arm/arm64/debug-meson.inc
> new file mode 100644
> index 000..01b70f0
> --- /dev/null
> +++ b/xen/arch/arm/arm64/debug-meson.inc
> @@ -0,0 +1,51 @@
> +/*
> + * xen/arch/arm/arm64/debug-meson.inc
> + *
> + * MESON specific debug code.
> + *
> + * Copyright (c) 2019, Amit Singh Tomar .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#define AML_UART_WFIFO_REG  0x00
> +#define AML_UART_STATUS_REG 0x0c
> +
> +#define AML_UART_TX_FIFO_FULL   21
> +
> +/*
> + * MESON UART wait UART to be ready to transmit
> + * xb: register which contains the UART base address
> + * c: scratch register
> + */
> +.macro early_uart_ready xb c
> +1:
> +ldr w\c, [\xb, #AML_UART_STATUS_REG]/* status register */
> +tbnzw\c, #AML_UART_TX_FIFO_FULL, 1b /* Check TXFIFO FULL 
> bit */
> +.endm
> +
> +/*
> + * MESON UART transmit character
> + * xb: register which contains the UART base address
> + * wt: register which contains the character to transmit
> + */
> +.macro early_uart_transmit xb wt
> +str\wt, [\xb, #AML_UART_WFIFO_REG]
> +.endm
> +
> +/*
> + * Local variables:
> + * mode: ASM
> + * indent-tabs-mode: nil
> + * End:
> + */
> 


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

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add MESON UART driver for Amlogic Meson SoCs

[André Przywara]

On 21/03/2019 10:25, Amit Singh Tomar wrote:
> This patch adds driver for UART controller present on Amlogic Meson
> SoCs and it has been tested on Nanopi K2 board based on S905 SoC.
> 
> Controller registers defination is taken from Linux 4.20.
> https://github.com/torvalds/linux/blob/v4.20-rc1/drivers/tty/serial/meson_uart.c
> 
> Signed-off-by: Amit Singh Tomar 

Thanks for the changes!

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
> Changes since v1:
> 
> * Removed clrsetbits macro.
> * Fixed coding style issue.
> * Updated MAINTAINERS file.
> 
> Changes since RFC:
> 
> * Removed S905 reference as other Amlogic SoCs
>   have this uart controller.
> * Replaced meson_s905_read/write helper
>   with clrsetbit and friends helper.
> * Followed proper UART reset sequence.
> * List all UART compatible strings same as Linux
>   driver.
> ---
>  xen/drivers/char/Kconfig  |   8 ++
>  xen/drivers/char/Makefile |   1 +
>  xen/drivers/char/meson-uart.c | 276 
> ++
>  3 files changed, 285 insertions(+)
>  create mode 100644 xen/drivers/char/meson-uart.c
> 
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index b1f07f8..b572305 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -20,6 +20,14 @@ config HAS_MVEBU
> This selects the Marvell MVEBU UART. If you have a ARMADA 3700
> based board, say Y.
>  
> +config HAS_MESON
> + bool "Amlogic MESON UART driver"
> + default y
> + depends on ARM_64
> + help
> +   This selects the Amlogic MESON UART. If you have a Amlogic based
> +   board, say Y.
> +
>  config HAS_PL011
>   bool "ARM PL011 UART driver"
>   default y
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index b68c330..7c646d7 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_HAS_NS16550) += ns16550.o
>  obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
>  obj-$(CONFIG_HAS_PL011) += pl011.o
>  obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
> +obj-$(CONFIG_HAS_MESON) += meson-uart.o
>  obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
>  obj-$(CONFIG_HAS_OMAP) += omap-uart.o
>  obj-$(CONFIG_HAS_SCIF) += scif-uart.o
> diff --git a/xen/drivers/char/meson-uart.c b/xen/drivers/char/meson-uart.c
> new file mode 100644
> index 000..c16c188
> --- /dev/null
> +++ b/xen/drivers/char/meson-uart.c
> @@ -0,0 +1,276 @@
> +/*
> + * xen/drivers/char/meson-uart.c
> + *
> + * Driver for Amlogic MESON UART
> + *
> + * Copyright (c) 2019, Amit Singh Tomar .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register offsets */
> +#define AML_UART_WFIFO_REG  0x00
> +#define AML_UART_RFIFO_REG  0x04
> +#define AML_UART_CONTROL_REG0x08
> +#define AML_UART_STATUS_REG 0x0c
> +#define AML_UART_MISC_REG   0x10
> +
> +/* UART_CONTROL bits */
> +#define AML_UART_TX_RST BIT(22)
> +#define AML_UART_RX_RST BIT(23)
> +#define AML_UART_CLEAR_ERR  BIT(24)
> +#define AML_UART_RX_INT_EN  BIT(27)
> +#define AML_UART_TX_INT_EN  BIT(28)
> +
> +/* UART_STATUS bits */
> +#define AML_UART_RX_FIFO_EMPTY  BIT(20)
> +#define AML_UART_TX_FIFO_FULL   BIT(21)
> +#define AML_UART_TX_FIFO_EMPTY  BIT(22)
> +#define AML_UART_TX_CNT_MASKGENMASK(14, 8)
> +
> +/* AML_UART_MISC bits */
> +#define AML_UART_XMIT_IRQ(c)(((c) & 0xff) << 8)
> +#define AML_UART_RECV_IRQ(c)((c) & 0xff)
> +
> +#define TX_FIFO_SIZE64
> +
> +#define setbits(addr, set)  writel((readl(addr) | (set)), (addr))
> +#define clrbits(addr, clear)writel((readl(addr) & ~(clear)), 
> (addr))
> +
> +static struct meson_uart {
> +unsigned int irq;
> +void __iomem *regs;
> +struct irqaction irqaction;
> +struct vuart_info vuart;
> +} meson_com;
> +
> +static void meson_uart_interrupt(int irq, void *data,
> + struct cpu_user_regs *regs)
> +{
> +struct serial_port *port = data;
> +struct meson_uart *uart = port->uart;
> +uint32_t st = readl(uart->regs + AML_UART_STATUS_REG);
> +
> +

Re: [Xen-devel] [PATCH v2 3/3] MAINTAINERS: add ARM meson serial driver

[André Przywara]

On 21/03/2019 10:25, Amit Singh Tomar wrote:
> The meson-uart.c is an ARM specific UART driver for the Amlogic MESON
> SoC family.
> 
> Signed-off-by: Amit Singh Tomar 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba7527c..aff7f81 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -182,6 +182,7 @@ F:xen/arch/arm/
>  F:   xen/drivers/char/arm-uart.c
>  F:   xen/drivers/char/cadence-uart.c
>  F:   xen/drivers/char/exynos4210-uart.c
> +F:   xen/drivers/char/meson-uart.c
>  F:   xen/drivers/char/mvebu-uart.c
>  F:   xen/drivers/char/omap-uart.c
>  F:   xen/drivers/char/pl011.c
> 


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

[Xen-devel] [xen-unstable-smoke test] 134307: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  82a9e0aa193cacd9ae9fe37deff5de9ccd4212ad
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   11 days
Failing since134068  2019-03-25 12:00:51 Z8 days   35 attempts
Testing same since   134307  2019-04-02 18:00:38 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  M A Young 
  Wei Liu 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit 82a9e0aa193cacd9ae9fe37deff5de9ccd4212ad
Author: Andrew Cooper 
Date:   Wed Mar 27 19:52:17 2019 +

x86/vvmx: Fix debug prints to not have 17 unnecessary spaces

This has been problematic since its introduction in Xen 4.3

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Acked-by: Kevin Tian 

commit a57a1b26ec0ae31f924cf2bbcf479637d007be44
Author: Wei Liu 
Date:   Mon Apr 1 11:32:38 2019 +0100

tools/ocaml: make python scripts 2 and 3 compatible

1. Explicitly import reduce because that's required in 3.
2. Change print to function.
3. Eliminate invocations of has_key.

Signed-off-by: M A Young 
Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 
Acked-by: Christian Lindig 

commit ff915c8cacc264ae1380d51fea07267b8308d7ba
Author: Wei Liu 
Date:   Mon Apr 1 11:32:37 2019 +0100

pygrub: encode / decode string in Python 3

String is unicode in 3 but bytes in 2. We need to call encode / decode
function when using Python 3.

Reported-by: M A Young 
Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 767ba397d34848c7e0c4e9cdfc5efa4e0cb61442
Author: Wei Liu 
Date:   Mon Apr 1 11:32:36 2019 +0100

pygrub/grub: always use integer for default entry

The original code set the default to either a string or an integer
(0) and relies on a Python 2 specific behaviour to work (integer is
allowed to be compared to string in Python 2 but not 3).

Always use integer. The caller (pygrub) already has code to handle
that.

Reported-by: M A Young 
Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 485079e816788d70169f45579e1f5a8f909dc1b3
Author: Wei Liu 
Date:   Mon Apr 1 11:32:35 2019 +0100

pygrub: fix message in grub parser

The code suggests 0 is allowed. Zero is not a positive number.

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 905d7340f6d0abfbf986cede6e535c51ab1de3c3
Author: Andrew Cooper 
Date:   Mon Apr 1 10:08:43 2019 +

xen/sched: Remove d->is_pinned

The is_pinned field is rather odd.  It can only be activated with the
"dom0_vcpus_pin" command line option, and causes dom0 (or the late hwdom) to
have its vcpus identity pinned to pcpus.

Having dom0_vcpus_pin active disallows the use of vcpu_set_har

[Xen-devel] [xen-unstable-smoke test] 134309: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  82a9e0aa193cacd9ae9fe37deff5de9ccd4212ad
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   11 days
Failing since134068  2019-03-25 12:00:51 Z8 days   36 attempts
Testing same since   134307  2019-04-02 18:00:38 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  M A Young 
  Wei Liu 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit 82a9e0aa193cacd9ae9fe37deff5de9ccd4212ad
Author: Andrew Cooper 
Date:   Wed Mar 27 19:52:17 2019 +

x86/vvmx: Fix debug prints to not have 17 unnecessary spaces

This has been problematic since its introduction in Xen 4.3

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Acked-by: Kevin Tian 

commit a57a1b26ec0ae31f924cf2bbcf479637d007be44
Author: Wei Liu 
Date:   Mon Apr 1 11:32:38 2019 +0100

tools/ocaml: make python scripts 2 and 3 compatible

1. Explicitly import reduce because that's required in 3.
2. Change print to function.
3. Eliminate invocations of has_key.

Signed-off-by: M A Young 
Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 
Acked-by: Christian Lindig 

commit ff915c8cacc264ae1380d51fea07267b8308d7ba
Author: Wei Liu 
Date:   Mon Apr 1 11:32:37 2019 +0100

pygrub: encode / decode string in Python 3

String is unicode in 3 but bytes in 2. We need to call encode / decode
function when using Python 3.

Reported-by: M A Young 
Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 767ba397d34848c7e0c4e9cdfc5efa4e0cb61442
Author: Wei Liu 
Date:   Mon Apr 1 11:32:36 2019 +0100

pygrub/grub: always use integer for default entry

The original code set the default to either a string or an integer
(0) and relies on a Python 2 specific behaviour to work (integer is
allowed to be compared to string in Python 2 but not 3).

Always use integer. The caller (pygrub) already has code to handle
that.

Reported-by: M A Young 
Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 485079e816788d70169f45579e1f5a8f909dc1b3
Author: Wei Liu 
Date:   Mon Apr 1 11:32:35 2019 +0100

pygrub: fix message in grub parser

The code suggests 0 is allowed. Zero is not a positive number.

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 905d7340f6d0abfbf986cede6e535c51ab1de3c3
Author: Andrew Cooper 
Date:   Mon Apr 1 10:08:43 2019 +

xen/sched: Remove d->is_pinned

The is_pinned field is rather odd.  It can only be activated with the
"dom0_vcpus_pin" command line option, and causes dom0 (or the late hwdom) to
have its vcpus identity pinned to pcpus.

Having dom0_vcpus_pin active disallows the use of vcpu_set_har

Re: [Xen-devel] [PATCH 6/7] x86/IOMMU: abstract Intel-specific iommu_{en, dis}able_x2apic_IR()

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, April 2, 2019 9:17 PM
> 
> >>> On 02.04.19 at 05:24,  wrote:
> >>  From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, March 29, 2019 5:13 PM
> >>
> >> >>> On 28.03.19 at 18:37,  wrote:
> >> > On 28/03/2019 14:53, Jan Beulich wrote:
> >> >> @@ -35,6 +35,8 @@ void print_vtd_entries(struct iommu *iom
> >> >>  keyhandler_fn_t vtd_dump_iommu_info;
> >> >>
> >> >>  bool intel_iommu_supports_eim(void);
> >> >> +int intel_iommu_enable_x2apic_IR(void);
> >> >> +void intel_iommu_disable_x2apic_IR(void);
> >> >
> >> > Is there any particular reason why these retain their _IR suffix?
> >>
> >> Well, I've too been thinking about the naming here. I decided to
> >> keep the _IR suffixes because that's what the functions really
> >> do: They enable/disable interrupt remapping for x2APIC mode.
> >> They don't enable x2APIC itself in any way, and iirc x2APIC
> >> mode could be used (without wider APIC IDs and in physical
> >> mode) even without any IR enabled.
> >>
> >> > I'd suggest going with intel_iommu_{en,dis}able_eim() to match the
> >> > supports name here, whereas...
> >> >
> >> >> --- a/xen/drivers/passthrough/vtd/iommu.c
> >> >> +++ b/xen/drivers/passthrough/vtd/iommu.c
> >> >> @@ -2720,6 +2720,8 @@ const struct iommu_ops __initconstrel in
> >> >>  .free_page_table = iommu_free_page_table,
> >> >>  .reassign_device = reassign_device_ownership,
> >> >>  .get_device_group_id = intel_iommu_group_id,
> >> >> +.enable_x2apic_IR = intel_iommu_enable_x2apic_IR,
> >> >> +.disable_x2apic_IR = intel_iommu_disable_x2apic_IR,
> >> >>  .update_ire_from_apic = io_apic_write_remap_rte,
> >> >>  .update_ire_from_msi = msi_msg_write_remap_rte,
> >> >>  .read_apic_from_ire = io_apic_read_remap_rte,
> >> >> @@ -2736,6 +2738,7 @@ const struct iommu_ops __initconstrel in
> >> >>  };
> >> >>
> >> >>  const struct iommu_init_ops __initconstrel intel_iommu_init_ops = {
> >> >> +.ops = &intel_iommu_ops,
> >> >>  .setup = vtd_setup,
> >> >>  .supports_x2apic = intel_iommu_supports_eim,
> >> >>  };
> >> >> --- a/xen/drivers/passthrough/x86/iommu.c
> >> >> +++ b/xen/drivers/passthrough/x86/iommu.c
> >> >> @@ -26,6 +26,24 @@
> >> >>  const struct iommu_init_ops *__initdata iommu_init_ops;
> >> >>  struct iommu_ops __read_mostly iommu_ops;
> >> >>
> >> >> +int iommu_enable_x2apic_IR(void)
> >> >
> >> > ... using iommu_{en,dis}able_x2apic() here to match the
> >> > supports_x2apic() init hook.
> >> >
> >> >
> >> > I don't think these shorter names are any more ambiguous, and loosing
> >> > the _IR suffix does make them more consistent with the rest of Xen's
> >> > function naming conventions.
> >>
> >> The above said, in the end I'm not overly fussed, but before deciding
> >> which route to go I'll wait to see whether in particular Kevin has an
> >> opinion either way.
> >>
> >
> > let's remove _IR. we have intel_iommu prefix which is sufficient
> > to indicate enable_x2apic in iommu context is about IR.
> >
> > since renaming is small thing, here is my:
> >
> > Reviewed-by: Kevin Tian 
> 
> Thanks, but well, I'll then follow Andrew's suggestion and also
> name the VT-d functions intel_iommu_{en,dis}able_eim(). I
> hope that's okay with you.
> 

OK to me.

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

Re: [Xen-devel] [PATCH] VT-d: return full destination ID for IO-APIC reads

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, April 2, 2019 8:57 PM
> 
> In x2APIC mode it is 32 bits wide. Not having returned the full value
> was mostly benign: We never modify the ID based on its original value;
> full new values get written at all times. It was "just" debug logging
> which ended up wrong this way (and which will need adjustment itself as
> well, to also consume the full value).
> 
> Signed-off-by: Jan Beulich 

Acked-by: Kevin Tian 

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

[Xen-devel] [xen-unstable-smoke test] 134315: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  82a9e0aa193cacd9ae9fe37deff5de9ccd4212ad
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   11 days
Failing since134068  2019-03-25 12:00:51 Z8 days   37 attempts
Testing same since   134307  2019-04-02 18:00:38 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  M A Young 
  Wei Liu 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit 82a9e0aa193cacd9ae9fe37deff5de9ccd4212ad
Author: Andrew Cooper 
Date:   Wed Mar 27 19:52:17 2019 +

x86/vvmx: Fix debug prints to not have 17 unnecessary spaces

This has been problematic since its introduction in Xen 4.3

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Acked-by: Kevin Tian 

commit a57a1b26ec0ae31f924cf2bbcf479637d007be44
Author: Wei Liu 
Date:   Mon Apr 1 11:32:38 2019 +0100

tools/ocaml: make python scripts 2 and 3 compatible

1. Explicitly import reduce because that's required in 3.
2. Change print to function.
3. Eliminate invocations of has_key.

Signed-off-by: M A Young 
Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 
Acked-by: Christian Lindig 

commit ff915c8cacc264ae1380d51fea07267b8308d7ba
Author: Wei Liu 
Date:   Mon Apr 1 11:32:37 2019 +0100

pygrub: encode / decode string in Python 3

String is unicode in 3 but bytes in 2. We need to call encode / decode
function when using Python 3.

Reported-by: M A Young 
Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 767ba397d34848c7e0c4e9cdfc5efa4e0cb61442
Author: Wei Liu 
Date:   Mon Apr 1 11:32:36 2019 +0100

pygrub/grub: always use integer for default entry

The original code set the default to either a string or an integer
(0) and relies on a Python 2 specific behaviour to work (integer is
allowed to be compared to string in Python 2 but not 3).

Always use integer. The caller (pygrub) already has code to handle
that.

Reported-by: M A Young 
Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 485079e816788d70169f45579e1f5a8f909dc1b3
Author: Wei Liu 
Date:   Mon Apr 1 11:32:35 2019 +0100

pygrub: fix message in grub parser

The code suggests 0 is allowed. Zero is not a positive number.

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 905d7340f6d0abfbf986cede6e535c51ab1de3c3
Author: Andrew Cooper 
Date:   Mon Apr 1 10:08:43 2019 +

xen/sched: Remove d->is_pinned

The is_pinned field is rather odd.  It can only be activated with the
"dom0_vcpus_pin" command line option, and causes dom0 (or the late hwdom) to
have its vcpus identity pinned to pcpus.

Having dom0_vcpus_pin active disallows the use of vcpu_set_har

[Xen-devel] [linux-next test] 134264: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 134237
 test-armhf-armhf-xl-arndale   7 xen-boot fail REGR. vs. 134237
 test-armhf-armhf-xl-vhd   6 xen-install  fail REGR. vs. 134237
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 134237

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 build-arm64   4 host-install(4) broken like 134237
 build-arm64-pvops 4 host-install(4) broken like 134237
 build-arm64-xsm   4 host-install(4) broken like 134237
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail like 134237
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 134237
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 134237
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 134237
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 134237
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 134237
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 134237
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 134237
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 134237
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 134237
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linuxe3ecb83ee707a3b2a4d12e19509ecbda7f793cc2
baseline version:
 linuxb5c8314f0ebadb6d8a9789cb2d646cbef8448073

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   134264  2019-04-01 12:52:48 Z1 days1 attempts

jobs:
 build-amd64-xsm

[Xen-devel] [PATCH] xen: use struct_size() helper in kzalloc()

[Andrea Righi]

struct privcmd_buf_vma_private has a zero-sized array at the end
(pages), use the new struct_size() helper to determine the proper
allocation size and avoid potential type mistakes.

Signed-off-by: Andrea Righi 
---
 drivers/xen/privcmd-buf.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd-buf.c b/drivers/xen/privcmd-buf.c
index de01a6d0059d..a1c61e351d3f 100644
--- a/drivers/xen/privcmd-buf.c
+++ b/drivers/xen/privcmd-buf.c
@@ -140,8 +140,7 @@ static int privcmd_buf_mmap(struct file *file, struct 
vm_area_struct *vma)
if (!(vma->vm_flags & VM_SHARED))
return -EINVAL;
 
-   vma_priv = kzalloc(sizeof(*vma_priv) + count * sizeof(void *),
-  GFP_KERNEL);
+   vma_priv = kzalloc(struct_size(vma_priv, pages, count), GFP_KERNEL);
if (!vma_priv)
return -ENOMEM;
 
-- 
2.19.1


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

Re: [Xen-devel] [PATCH] xen: use struct_size() helper in kzalloc()

[Juergen Gross]

On 03/04/2019 07:26, Andrea Righi wrote:
> struct privcmd_buf_vma_private has a zero-sized array at the end
> (pages), use the new struct_size() helper to determine the proper
> allocation size and avoid potential type mistakes.
> 
> Signed-off-by: Andrea Righi 

Reviewed-by: Juergen Gross 


Juergen

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

[Xen-devel] [xen-unstable-smoke test] 134320: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133991

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  82a9e0aa193cacd9ae9fe37deff5de9ccd4212ad
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   11 days
Failing since134068  2019-03-25 12:00:51 Z8 days   38 attempts
Testing same since   134307  2019-04-02 18:00:38 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  M A Young 
  Wei Liu 

jobs:
 build-arm64-xsm  broken  
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit 82a9e0aa193cacd9ae9fe37deff5de9ccd4212ad
Author: Andrew Cooper 
Date:   Wed Mar 27 19:52:17 2019 +

x86/vvmx: Fix debug prints to not have 17 unnecessary spaces

This has been problematic since its introduction in Xen 4.3

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Acked-by: Kevin Tian 

commit a57a1b26ec0ae31f924cf2bbcf479637d007be44
Author: Wei Liu 
Date:   Mon Apr 1 11:32:38 2019 +0100

tools/ocaml: make python scripts 2 and 3 compatible

1. Explicitly import reduce because that's required in 3.
2. Change print to function.
3. Eliminate invocations of has_key.

Signed-off-by: M A Young 
Signed-off-by: Wei Liu 
Reviewed-by: Andrew Cooper 
Acked-by: Christian Lindig 

commit ff915c8cacc264ae1380d51fea07267b8308d7ba
Author: Wei Liu 
Date:   Mon Apr 1 11:32:37 2019 +0100

pygrub: encode / decode string in Python 3

String is unicode in 3 but bytes in 2. We need to call encode / decode
function when using Python 3.

Reported-by: M A Young 
Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 767ba397d34848c7e0c4e9cdfc5efa4e0cb61442
Author: Wei Liu 
Date:   Mon Apr 1 11:32:36 2019 +0100

pygrub/grub: always use integer for default entry

The original code set the default to either a string or an integer
(0) and relies on a Python 2 specific behaviour to work (integer is
allowed to be compared to string in Python 2 but not 3).

Always use integer. The caller (pygrub) already has code to handle
that.

Reported-by: M A Young 
Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 485079e816788d70169f45579e1f5a8f909dc1b3
Author: Wei Liu 
Date:   Mon Apr 1 11:32:35 2019 +0100

pygrub: fix message in grub parser

The code suggests 0 is allowed. Zero is not a positive number.

Signed-off-by: Wei Liu 
Acked-by: Andrew Cooper 

commit 905d7340f6d0abfbf986cede6e535c51ab1de3c3
Author: Andrew Cooper 
Date:   Mon Apr 1 10:08:43 2019 +

xen/sched: Remove d->is_pinned

The is_pinned field is rather odd.  It can only be activated with the
"dom0_vcpus_pin" command line option, and causes dom0 (or the late hwdom) to
have its vcpus identity pinned to pcpus.

Having dom0_vcpus_pin active disallows the use of vcpu_set_har

[Xen-devel] [qemu-mainline test] 134240: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 133909
 build-arm64   4 host-install(4)broken REGR. vs. 133909
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 133909
 test-amd64-i386-freebsd10-amd64 14 guest-saverestore fail REGR. vs. 133909
 test-amd64-i386-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 
133909
 test-amd64-i386-freebsd10-i386 14 guest-saverestore  fail REGR. vs. 133909
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 
133909
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail 
REGR. vs. 133909
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. 
vs. 133909
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 133909
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 133909
 test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 133909
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail REGR. 
vs. 133909
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 13 guest-saverestore fail 
REGR. vs. 133909
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail 
REGR. vs. 133909
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 13 guest-saverestore fail 
REGR. vs. 133909
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 133909
 test-amd64-amd64-xl-qemuu-ws16-amd64 13 guest-saverestore fail REGR. vs. 133909
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail REGR. vs. 133909

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale  15 guest-stop fail pass in 134218

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133909
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 133909
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-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-libvirt-raw 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-

Re: [Xen-devel] Performance Monitor and Profiling tools for ARM64

[Diego Alejandro Parra Guzman]

Hello Julien Grall

thank you for your replied,  you have clarified many of my doubts.

I have been implementing some basic functionality for the PMU :

Here small description:

   - getpmuinfo_attr : /* @brief  get PMU info,
   including number of Counters, and control counters */
   - enable_all_pmu_counters:  /* @brief  Enable the cycle
   counter register PMCCNTR_EL0, and any implemented event counter
   PMEVCNTR_EL0 */
   - disable_all_pmu_counters  /* @brief  Disable the cycle
   counter register PMCCNTR_EL0, and any implemented event counter
   PMEVCNTR_EL0. */
   - reset_all_pmu_counters  /* @brief  Reset the cycle
   counter register PMCCNTR_EL0,  and any implemented event counter
   PMEVCNTR_EL0.*/
   - enable_user_pmu_access  /* @brief  Enable user-mode access
   to counters.*/

I think these can be used as primitives for XEN:

Now I have some additional questions about XEN:

   - how can I include that primitives as a driver for ARM64 in XEN?

I've noticed that in linux kernel 4.14 - 4.15  $SOURCE/drivers/perf :

   - there is and implementation for arm_pmu  which is far better than what
   I've implemented, is it hard to import that driver to XEN ?
   - again how can I include that primitives as a driver for ARM64 in XEN?
   - PMU is implemented for each CPU so how to deal with that?

if you answer these questions will be really useful for me.
thank you.
BR
Diego.







On Fri, 22 Mar 2019 at 15:17, Julien Grall  wrote:

>
>
> On 22/03/2019 07:25, Diego Alejandro Parra Guzman wrote:
> > HI Everyone
>
> Hi Diego,
>
> > My name is diego. I'm very interesting in extend the XenOprof to ARM64
> based
> > architectures, and also integrate some tools for hypervisor and
> application
> > profiling and performance evaluation.
> >
> > I read the documentation for Oprofile a perf which is in the wiki page
> and I
> > noticed that XEN doesn't support ARM64 architectures.  For this reason I
> have
> > two ideas.
>
> Thank you for your interest to add perf support in Xen on Arm.
>
> >
> > 1. Add support for ARM64 architectures to XenOprof  in its current
> implementation.
> >
> > 2. I found an interesting library called libpfm4 which also work with
> > perf_event, and support ARM64 and ARM32 architectures. Well I can tray
> to use
> > this library in order to profile DOM0 and DOMU-VP guest.
> >
> > Personally I prefer the option 2 since the  library currently works in
> normal
> > linux OS and I guest could be easy to replicate it on XEN.
> >
> > Approaches:
> >
> > (hypercalls) from DOM0-DOMU to xen
> >
> > (direct pass through from DOM0 to PMU counters), and VPMU in DOMU .
>
> I think there are two (more or less distinct) use cases to take into
> account:
>1) A guest profiling itself
>2) The hypervisor profiling the system (i.e guests and itself).
>
>  From my understanding, the latter is implemented using XenOprof. For the
> former, then giving direct access to the PMU counters is probably a better
> approach over a PV solution.
>
> >
> > Here my questions?
> >
> > I would like to know if currently DOM0 and DOMU have support to
> perf_event
> > i.e., they can read directly performance monitoring unit (PMU) counters,
> only
> > DOM0 or none of them?
>
> Currently, there are no PMU support for Dom0 and DomU.
>
> >
> > should I implement some traps in XEN hypervisor ?
>
> The registers are already trapped (see arch/arm64/vsysregs.c) and
> implemented as
> a NOP for now. Depending on your use case, then trapping the registers may
> not
> be necessary (see more below).
>
> >
> > someone  currently  is working on this?
>
> I am not aware of anyone working on it so far.
>
> >
> > Which is the most efficient way to implement it ?
>
> I haven't fully thought through. The two use cases I mentioned above are
> quite
> distinct in term of implementation. It would probably be easy to implement
> them
> separately, but would require more thoughts if you want to handle the both
> at
> the same time.
>
> In the case of guest profiling itself, then I think you could just disable
> the
> traps and context switch the registers. You will also need to forward the
> PMU
> interrupts (such as the overflow one) to the domains. For accuracy, you
> may also
> need to enable/disable PMU counters (see PMCR_EL0) on each traps so you
> don't
> count events in the hypervisor. Unless there are a way to ignore events
> when at
> running at EL2 (I haven't explored the spec yet).
>
> In the case of the hypervisor profiling system, you would need to
> implement a
> PMU drivers in Xen. I don't know much about xenoprofile to be able to give
> more
> details here.
>
> >
> > There is a guide line to do this easily?
> I am afraid there are no silver bullet. You would need to read the ARM ARM
> section about the PMU and look at the xenoprofile code. I would be happy
> to
> answer any specific question if you are not understand some part of the
> code.
>
> Ch