Re: [Xen-devel] [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Jan Beulich]

 Juergen Gross  03/01/18 8:29 AM >>>
>On 28/02/18 19:28, Maran Wilson wrote:
>> The start info structure that is defined as part of the x86/HVM direct boot
>> ABI and used for starting Xen PVH guests would be more versatile if it also
>> included a way to pass information about the memory map to the guest. This
>> would allow KVM guests to share the same entry point.
>> 
>> Signed-off-by: Maran Wilson 
>
>I'm fine with this, but we need this change being accepted by the Xen
>community first. So an Ack from Jan or Andrew is required as the same
>change should be done on Xen side.

And for an ack to be given I continue to demand that a patch be sent against
the Xen tree. That said, the change looks fine to me now (as indicated before).

Jan


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

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

[Jan Beulich]

>>> Chao Gao  03/01/18 7:34 AM >>>
>On Mon, Feb 26, 2018 at 09:10:33AM -0700, Jan Beulich wrote:
>>Again - here we're talking about implementation limits, not
>>bottlenecks. So in this context all I'm interested in is whether
>>(and if so which) implementation limit remains. If an (almost)
>>arbitrary number is fine, perhaps we'll want to have a Kconfig
>>option.
>
>Do you think that struct hvm_info_table would be a implementation
>limits? To contain this struct in a single page, the HVM_MAX_VCPUS
>should be smaller than a value, like (PAGE_SIZE * 8). Supposing
>it is the only implementation limit, I don't think it is reasonable
>to set HVM_MAX_VCPUS to that value, because we don't have hardwares to
>perform tests, even Xeon-phi isn't capable. This value can be bumped
>when some methods verify a guest can work with more vcpus. Now I
>prefer 288 over 512 and some values else.

Whether going beyond PAGE_SIZE with the structure size is a valid item
to think about, but I don't think there's any implied limit from that. But -
did you read my and George's subsequent reply at all? You continue to
mix up supported (because of being able to test) limits with implementation
ones. Even Jürgen's suggestion to take NR_CPUS as the limit is not very
reasonable - PV guests have an implementation limit of (iirc) 8192. Once
again - if there's no sensible upper limit imposed by the implementation,
consider introducing a Kconfig option to pick the limit.

Jan


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

Re: [Xen-devel] [RFC PATCH v4 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without the need to run firmware.
> 
> There already exists an ABI to allow this for Xen PVH guests and the ABI
> is supported by Linux and FreeBSD:
> 
>https://xenbits.xen.org/docs/unstable/misc/pvh.html
> 
> This patch enables Qemu to use that same entry point for booting KVM
> guests.
> 
> Signed-off-by: Maran Wilson 

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] [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> would allow KVM guests to share the same entry point.
> 
> Signed-off-by: Maran Wilson 

I'm fine with this, but we need this change being accepted by the Xen
community first. So an Ack from Jan or Andrew is required as the same
change should be done on Xen side.

Juergen

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

Re: [Xen-devel] [PATCH v2 7/7] x86/build: Use new .nop directive when available

[Jan Beulich]

>>> Andrew Cooper  02/28/18 7:20 PM >>>
>On 28/02/18 16:22, Jan Beulich wrote:
> On 26.02.18 at 12:35,  wrote:
>>> --- a/xen/include/asm-x86/alternative-asm.h
>>> +++ b/xen/include/asm-x86/alternative-asm.h
>>> @@ -1,6 +1,8 @@
>>>  #ifndef _ASM_X86_ALTERNATIVE_ASM_H_
>>>  #define _ASM_X86_ALTERNATIVE_ASM_H_
>>>  
>>> +#include 
>>> +
>>>  #ifdef __ASSEMBLY__
>>>  
>>>  /*
>>> @@ -18,6 +20,14 @@
>>>  .byte \pad_len
>>>  .endm
>>>  
>>> +.macro mknops nr_bytes
>>> +#ifdef HAVE_AS_NOP_DIRECTIVE
>>> +.nop \nr_bytes, ASM_NOP_MAX
>> And do you really need to specify ASM_NOP_MAX here? What's
>> wrong with letting the assembler pick what it wants as the longest
>> NOP?
>
>I don't want a toolchain change to cause us to go beyond 11 byte nops,
>because of the associated decode stall on almost all hardware.  Using
>ASM_NOP_MAX seemed like the easiest way to keep the end result
>consistent, irrespective of toolchain support.

I don't understand - an earlier patch takes care of runtime replacing them
anyway. What stalls can then result?

Jan



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

Re: [Xen-devel] [PATCH v2 5/7] x86/alt: Support for automatic padding calculations

[Jan Beulich]

>>> Andrew Cooper  02/28/18 7:02 PM >>>
>On 28/02/18 16:16, Jan Beulich wrote:
> On 26.02.18 at 12:35,  wrote:
>>>  .macro ALTERNATIVE oldinstr, newinstr, feature
>>>  .L\@_orig_s:
>>>  \oldinstr
>>>  .L\@_orig_e:
>>> +/*
>>> + * Calculate the difference in size between the replacement and 
>>> original
>>> + * instructions, to derive how much padding to introduce.
>>> + */
>>> +.L\@_diff = repl_len(1) - orig_len
>>> +
>>> +.skip as_true(.L\@_diff > 0) * .L\@_diff, 0x90
>> How certain are you that these forward references actually work on
>> at least all half way recent gas versions? IOW I wonder whether it
>> wouldn't be more safe to make these backward references (i.e.
>> emitting the replacement code first).
>
>This code is used unconditionally in Linux, so any binutils within their
>minimum set work.
>
>So overall, I'm going to err on the side of "yes" in answer to your
>question.

Okay.

>>> @@ -45,18 +70,31 @@
>>>  .L\@_orig_s:
>>>  \oldinstr
>>>  .L\@_orig_e:
>>> +/*
>>> + * Calculate the difference in size between the largest replacement and
>>> + * the original instructions, to derive how much padding to introduce.
>>> + */
>>> +.L\@_diff = as_max(repl_len(1), repl_len(2)) - orig_len
>>> +
>>> + .skip as_true(.L\@_diff > 0) * .L\@_diff, 0x90
>>> +.L\@_orig_p:
>>>  
>>>  .pushsection .altinstructions, "a", @progbits
>>>  
>>>  altinstruction_entry .L\@_orig_s, .L\@_repl_s1, \feature1, \
>>> -orig_len, repl_len(1)
>>> +orig_len, repl_len(1), pad_len
>>>  altinstruction_entry .L\@_orig_s, .L\@_repl_s2, \feature2, \
>>> -orig_len, repl_len(2)
>>> +orig_len, repl_len(2), pad_len
>>>  
>>>  .section .discard, "a", @progbits
>>> -/* Assembler-time check that \newinstr{1,2} aren't longer than 
>>> \oldinstr. */
>>> -.byte 0xff + repl_len(1) - orig_len
>>> -.byte 0xff + repl_len(2) - orig_len
>>> +/*
>>> + * Assembler-time checks:
>>> + *   - total_len <= 255
>>> + *   - \newinstr* <= total_len
>>> + */
>>> +.byte total_len
>>> +.byte 0xff + repl_len(1) - total_len
>>> +.byte 0xff + repl_len(2) - total_len
>> Use as_max() here and emit only a single byte? I don't think the
>> diagnostic will be any less helpful, as iirc it doesn't point out the
>> line inside the macro anyway, so the developer will be left guessing
>> anyway which of the two alternatives it was. Otoh with the
>> padding size now being calculated, I don't see much point in these
>> checks anymore anyway.
>
>The bytes are discarded, so the quantity doesn't matter.  I can use max,
>and you are correct that the line reference only ends up pointing to the
>.macro itself.
>
>However, I would prefer to keep these.  They've spotted two bugs in the
>binutils development effort of .nops, and I'd prefer to be safe than sorry.

Well, fine with me then, and in that case it'll perhaps be indeed better to
avoid the use of max() here.

Jan



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

Re: [Xen-devel] [RFC PATCH v4 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> The original design for PVH entry in Xen guests relies on being able to
> obtain the memory map from the hypervisor using a hypercall. When we
> extend the PVH entry ABI to support other hypervisors like Qemu/KVM,
> a new mechanism will be added that allows the guest to get the memory
> map without needing to use hypercalls.
> 
> For Xen guests, the hypercall approach will still be supported. In
> preparation for adding support for other hypervisors, we can move the
> code that uses hypercalls into the Xen specific file. This will allow us
> to compile kernels in the future without CONFIG_XEN that are still capable
> of being booted as a Qemu/KVM guest via the PVH entry point.
> 
> Signed-off-by: Maran Wilson 

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 0/5] x86: improve PDX <-> PFN and alike translations

[Jan Beulich]

>>> Andrew Cooper  02/28/18 6:26 PM >>>
>On 28/02/18 13:51, Jan Beulich wrote:
>> 1: remove page.h and processor.h inclusion from asm_defns.h
>> 2: use PDEP for PTE flags insertion when available
>> 3: use PDEP/PEXT for maddr/direct-map-offset conversion when available
>> 4: use PDEP/PEXT for PFN/PDX conversion when available
>> 5: use MOV for PFN/PDX conversion when possible
>>
>> Signed-off-by: Jan Beulich 
>
>Ah - so this was the series you were on about which would have an
>interesting time in combination with my nop autosizing.
>
>Do you have performance numbers for these changes?  I can certainly see
>the attraction of using BMI2 when available, but do the associated costs
>>on incompatible hardware worth it?  I'm thinking specifically of turning
>all this inline bit manipulation into function calls?  (I genuinely
>don't know the answer, and it might be entirely fine, but I'm concerned
>about whether it may not be).

To be honest, performance on older hardware is of secondary concern to
me here, BMI2 isn't all that new anymore. The primary concern is
performance on recent hardware (which certainly is being improved) and
the much improved readability of generated code (which is particularly
relevant when one needs to investigate issues in one of the bigger
functions involving such translations.

>What generation of binutils do you expect this all to work with?

The respective change (d02603dc20) was done in August 2015.

>As for the pte flags, there is a much more simple approach which I've
>considered investigating in the past, and I think warrants discussing here.
>
>By switching 'unsigned int flags' to 'unsigned long flags', we avoid any
>need for packing in the first place.  Being 64bit only these days, all
>other PTE calculations are already 64bit operations, and the masks are
>probably already available in GPRs at the use-sites.  I.e. I think the
>use of 64bit flags will make better code than even this proposal.

If that doesn't result in overly many extra REX prefixes and/or full 64-bit
constant loads, perhaps. But that would affect just one of the five patches
here anyway.

Jan


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

Re: [Xen-devel] [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Juergen Gross]

On 28/02/18 19:28, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> This patch moves the small block of code used for initializing Xen PVH
> virtual machines into the Xen specific file. This initialization is not
> going to be needed for Qemu/KVM guests. Moving it out of the common file
> is going to allow us to compile kernels in the future without CONFIG_XEN
> that are still capable of being booted as a Qemu/KVM guest via the PVH
> entry point.
> 
> Signed-off-by: Maran Wilson 

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] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Juergen Gross]

On 28/02/18 19:27, Maran Wilson wrote:
> In order to pave the way for hypervisors other then Xen to use the PVH
> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a new config option for PVH entry that can be enabled
> independently from CONFIG_XEN.
> 
> Signed-off-by: Maran Wilson 

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 v4 15/20] x86emul: correctly handle CMPXCHG* comparison failures

[Tim Deegan]

At 06:09 -0700 on 28 Feb (1519798185), Jan Beulich wrote:
> If the ->cmpxchg() hook finds a mismatch, we should deal with this the
> same way as when the "manual" comparison reports a mismatch.
> 
> This involves reverting bfce0e62c3 ("x86/emul: Drop
> X86EMUL_CMPXCHG_FAILED"), albeit with X86EMUL_CMPXCHG_FAILED now
> becoming a value distinct from X86EMUL_RETRY.
> 
> Signed-off-by: Jan Beulich 
> Acked-by: Andrew Cooper 

Shadow parts Acked-by: Tim Deegan 

And also for the other parts of the series (13/20, 19/20 and 20/20).

Tim.

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

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

[Juergen Gross]

On 01/03/18 06:21, Chao Gao wrote:
> On Mon, Feb 26, 2018 at 09:10:33AM -0700, Jan Beulich wrote:
> On 26.02.18 at 14:11,  wrote:
>>> On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote:
>>> On 23.02.18 at 19:11,  wrote:
> On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
>> Signed-off-by: Chao Gao 
>> ---
>>  xen/include/public/hvm/hvm_info_table.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/include/public/hvm/hvm_info_table.h 
> b/xen/include/public/hvm/hvm_info_table.h
>> index 08c252e..6833a4c 100644
>> --- a/xen/include/public/hvm/hvm_info_table.h
>> +++ b/xen/include/public/hvm/hvm_info_table.h
>> @@ -32,7 +32,7 @@
>>  #define HVM_INFO_PADDR   ((HVM_INFO_PFN << 12) + HVM_INFO_OFFSET)
>>  
>>  /* Maximum we can support with current vLAPIC ID mapping. */
>> -#define HVM_MAX_VCPUS128
>> +#define HVM_MAX_VCPUS512
>
> Wow, that looks like a pretty big jump. I certainly don't have access
> to any box with this number of vCPUs, so that's going to be quite hard
> to test. What the reasoning behind this bump? Is hardware with 512
> ways expected soon-ish?
>
> Also osstest is not even able to test the current limit, so I would
> maybe bump this to 256, but as I expressed in other occasions I don't
> feel comfortable with have a number of vCPUs that the current test
> system doesn't have hardware to test with.

 I think implementation limit and supported limit need to be clearly
 distinguished here. Therefore I'd put the question the other way
 around: What's causing the limit to be 512, rather than 1024,
 4096, or even 4G-1 (x2APIC IDs are 32 bits wide, after all)?
>>>
>>> TBH, I have no idea. When I choose a value, what comes up to my mind is
>>> that the value should be 288, because Intel has Xeon-phi platform which
>>> has 288 physical threads, and some customers wants to use this new platform
>>> for HPC cloud. Furthermore, they requests to support a big VM in which
>>> almost computing and device resources are assigned to the VM. They just
>>> use virtulization technology to manage the machines. In this situation,
>>> I choose 512 is because I feel much better if the limit is a power of 2.
>>>
>>> You are asking that as these patches remove limitations imposed by some
>>> components, which one is the next bottleneck and how many vcpus does it
>>> limit.  Maybe it would be the use-case. No one is requesting to support
>>> more than 288 at this moment. So what is the value you prefer? 288 or
>>> 512? or you think I should find the next bottleneck in Xen's
>>> implementation.
>>
>> Again - here we're talking about implementation limits, not
>> bottlenecks. So in this context all I'm interested in is whether
>> (and if so which) implementation limit remains. If an (almost)
>> arbitrary number is fine, perhaps we'll want to have a Kconfig
>> option.
> 
> Do you think that struct hvm_info_table would be a implementation
> limits? To contain this struct in a single page, the HVM_MAX_VCPUS
> should be smaller than a value, like (PAGE_SIZE * 8). Supposing
> it is the only implementation limit, I don't think it is reasonable
> to set HVM_MAX_VCPUS to that value, because we don't have hardwares to
> perform tests, even Xeon-phi isn't capable. This value can be bumped
> when some methods verify a guest can work with more vcpus. Now I
> prefer 288 over 512 and some values else.
> 
>>
>> I'm also curious - do Phis not come in multi-socket configs? It's
>> my understanding that 288 is the count for a single socket.
> 
> Currently we don't have. But it's hard to say for future products.

Is there any reason to set HVM_MAX_VCPUS to a lower limit than
CONFIG_NR_CPUS? This can be set to 4095, so why not use the same
limit for HVM_MAX_VCPUS?


Juergen

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

Re: [Xen-devel] [RFC Patch v4 8/8] x86/hvm: bump the maximum number of vcpus to 512

[Chao Gao]

On Mon, Feb 26, 2018 at 09:10:33AM -0700, Jan Beulich wrote:
 On 26.02.18 at 14:11,  wrote:
>> On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote:
>> On 23.02.18 at 19:11,  wrote:
 On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
> Signed-off-by: Chao Gao 
> ---
>  xen/include/public/hvm/hvm_info_table.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/public/hvm/hvm_info_table.h 
 b/xen/include/public/hvm/hvm_info_table.h
> index 08c252e..6833a4c 100644
> --- a/xen/include/public/hvm/hvm_info_table.h
> +++ b/xen/include/public/hvm/hvm_info_table.h
> @@ -32,7 +32,7 @@
>  #define HVM_INFO_PADDR   ((HVM_INFO_PFN << 12) + HVM_INFO_OFFSET)
>  
>  /* Maximum we can support with current vLAPIC ID mapping. */
> -#define HVM_MAX_VCPUS128
> +#define HVM_MAX_VCPUS512
 
 Wow, that looks like a pretty big jump. I certainly don't have access
 to any box with this number of vCPUs, so that's going to be quite hard
 to test. What the reasoning behind this bump? Is hardware with 512
 ways expected soon-ish?
 
 Also osstest is not even able to test the current limit, so I would
 maybe bump this to 256, but as I expressed in other occasions I don't
 feel comfortable with have a number of vCPUs that the current test
 system doesn't have hardware to test with.
>>>
>>>I think implementation limit and supported limit need to be clearly
>>>distinguished here. Therefore I'd put the question the other way
>>>around: What's causing the limit to be 512, rather than 1024,
>>>4096, or even 4G-1 (x2APIC IDs are 32 bits wide, after all)?
>> 
>> TBH, I have no idea. When I choose a value, what comes up to my mind is
>> that the value should be 288, because Intel has Xeon-phi platform which
>> has 288 physical threads, and some customers wants to use this new platform
>> for HPC cloud. Furthermore, they requests to support a big VM in which
>> almost computing and device resources are assigned to the VM. They just
>> use virtulization technology to manage the machines. In this situation,
>> I choose 512 is because I feel much better if the limit is a power of 2.
>> 
>> You are asking that as these patches remove limitations imposed by some
>> components, which one is the next bottleneck and how many vcpus does it
>> limit.  Maybe it would be the use-case. No one is requesting to support
>> more than 288 at this moment. So what is the value you prefer? 288 or
>> 512? or you think I should find the next bottleneck in Xen's
>> implementation.
>
>Again - here we're talking about implementation limits, not
>bottlenecks. So in this context all I'm interested in is whether
>(and if so which) implementation limit remains. If an (almost)
>arbitrary number is fine, perhaps we'll want to have a Kconfig
>option.

Do you think that struct hvm_info_table would be a implementation
limits? To contain this struct in a single page, the HVM_MAX_VCPUS
should be smaller than a value, like (PAGE_SIZE * 8). Supposing
it is the only implementation limit, I don't think it is reasonable
to set HVM_MAX_VCPUS to that value, because we don't have hardwares to
perform tests, even Xeon-phi isn't capable. This value can be bumped
when some methods verify a guest can work with more vcpus. Now I
prefer 288 over 512 and some values else.

>
>I'm also curious - do Phis not come in multi-socket configs? It's
>my understanding that 288 is the count for a single socket.

Currently we don't have. But it's hard to say for future products.

Thanks
Chao

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

Re: [Xen-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

[Oleksandr Andrushchenko]

Hello,
Konrad, Takashi, Takashi and Clemens!

Could you please take a look at this series if it meets
ALSA expectations on para-virtualized sound for Xen?

Thank you,
Oleksandr

On 02/05/2018 10:24 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Hi, all!

Foreword


This change is aimed to add support for explicit back and front
synchronization during playback and capture in response to comments
raised during upstream attempt of the para-virtualized sound frontend
driver for Xen [1], [2] and gather opinions from the relevant communities
(ALSA, Xen) on the change.

The relevant backend is implemented as a user-space application [3]
and uses accompanying helper library [4].

Both frontend driver and backend were tested on real HW running Xen hypervisor
(Renesas R-Car ARM based H3/M3 boards, x86) to make sure the proposed
solution does work.

Rationale
=

During the first attempt to upstream the Linux front driver [5] number
of comments and concerns were raised, one of the biggest flaws in the
design were questioned by both Clemens Ladisch [6] and
Takashi Sakamoto [7]: the absence of synchronization between frontend
and backend during capture/playback. Two options were discussed:

“In design of ALSA PCM core, drivers are expected to synchronize to
actual hardwares for semi-realtime data transmission. The
synchronization is done by two points:
1) Interrupts to respond events from actual hardwares.
2) Positions of actual data transmission in any serial sound interfaces
 of actual hardwares.
“

and finally a change to the existing protocol was suggested:

“In 'include/xen/interface/io/sndif.h', there's no functionalities I
described the above:
1. notifications from DomU to Dom0 about the size of period for
 interrupts from actual hardwares. Or no way from Dom0 to DomU about
 the configured size of the period.
2. notifications of the interrupts from actual hardwares to DomU.”

This is implemented as a change to the sndif protocol and allows removing
period emulation:
1. Introduced a new event channel from back to front
2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS,
to be used for sending snd_pcm_period_elapsed at frontend (in Linux
implementation). Sent in bytes, not frames to make the protocol
generic and consistent)
3. New request for playback/capture control (XENSND_OP_TRIGGER) with
start/pause/stop/resume sub-ops
4. Playback/capture buffer size is set on the backend side via
XENSND_FIELD_BUFFER_SIZE XenStore entry

Waiting for your valuable comments,

Thank you,
Oleksandr

[1] https://github.com/andr2000/linux/commits/snd_upstream_v1
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
[3] https://github.com/xen-troops/snd_be
[4] https://github.com/xen-troops/libxenbe
[5] https://lkml.org/lkml/2017/8/7/363
[6] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
[7] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html


Oleksandr Andrushchenko (2):
   sndif: introduce protocol version
   sndif: add explicit back and front synchronization

  xen/include/public/io/sndif.h | 173 +-
  1 file changed, 170 insertions(+), 3 deletions(-)




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

Re: [Xen-devel] [PATCH v2] pvcalls-front: 64-bit align flags

[Juergen Gross]

On 01/03/18 03:05, Stefano Stabellini wrote:
> We are using test_and_* operations on the status and flag fields of
> struct sock_mapping. However, these functions require the operand to be
> 64-bit aligned on arm64. Currently, only status is 64-bit aligned.
> 
> Make status and flags explicitly 64-bit aligned.
> 
> Signed-off-by: Stefano Stabellini 

Committed to xen/tip for-linus-4.16a


Juergen


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

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Juergen Gross]

On 28/02/18 22:35, Paolo Bonzini wrote:
> On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote:
>> +obj-$(CONFIG_XEN_PVH) += pvh.o
>> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
>> +
> 
> Probably a better place for these would be
> arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
> .c or .S files in arch/x86).

Right.

> Maybe Xen ought to be moved under
> arch/x86/platform too.

And hyperv and kvm, too?

No, I think arch/x86/xen/ is fine.


Juergen

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

Re: [Xen-devel] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Juergen Gross]

On 28/02/18 22:07, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 28, 2018 at 10:27:57AM -0800, Maran Wilson wrote:
>> In order to pave the way for hypervisors other then Xen to use the PVH
>> entry point for VMs, we need to factor the PVH entry code into Xen specific
>> and hypervisor agnostic components. The first step in doing that, is to
>> create a new config option for PVH entry that can be enabled
>> independently from CONFIG_XEN.
>>
>> Signed-off-by: Maran Wilson 
>> ---
>>  arch/x86/Kconfig  | 8 
>>  arch/x86/kernel/head_64.S | 4 ++--
>>  arch/x86/xen/Kconfig  | 3 ++-
>>  3 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index eb7f43f23521..fa7cd0305125 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -791,6 +791,14 @@ config KVM_GUEST
>>underlying device model, the host provides the guest with
>>timing infrastructure such as time of day, and system time
>>  
>> +config PVH
>> +bool "Support for running PVH guests"
>> +depends on KVM_GUEST || XEN
>> +def_bool n
>> +---help---
>> +  This option enables the PVH entry point for guest virtual machines
>> +  as specified in the x86/HVM direct boot ABI.
>> +
>>  config KVM_DEBUG_FS
>>  bool "Enable debug information for KVM Guests in debugfs"
>>  depends on KVM_GUEST && DEBUG_FS
>> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
>> index 0f545b3cf926..fc9f678c6413 100644
>> --- a/arch/x86/kernel/head_64.S
>> +++ b/arch/x86/kernel/head_64.S
>> @@ -41,7 +41,7 @@
>>  
>>  #define pud_index(x)(((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
>>  
>> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
>> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>>  PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
>>  PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
>>  #endif
>> @@ -387,7 +387,7 @@ NEXT_PAGE(early_dynamic_pgts)
>>  
>>  .data
>>  
>> -#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
>> +#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
>>  NEXT_PGD_PAGE(init_top_pgt)
>>  .quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
>>  .orginit_top_pgt + PGD_PAGE_OFFSET*8, 0
>> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
>> index f605825a04ab..021c8591c3c0 100644
>> --- a/arch/x86/xen/Kconfig
>> +++ b/arch/x86/xen/Kconfig
>> @@ -77,8 +77,9 @@ config XEN_DEBUG_FS
>>Enabling this option may incur a significant performance overhead.
>>  
>>  config XEN_PVH
>> -bool "Support for running as a PVH guest"
>> +bool "Support for running as a Xen PVH guest"
>>  depends on XEN && XEN_PVHVM && ACPI
>>  # Pre-built page tables are not ready to handle 5-level paging.
>>  depends on !X86_5LEVEL
> 
> Not specific to this patch, but why is this there? PVH is not using PV so
> there should be no problems with 5 level paging.
> 
> Juergen, thoughts?

This dependency will be removed with Kyrill's series enabling to boot
the same kernel with either 5- or 4-level paging.

Adding 5-level paging support to the PVH boot path could be done later.
OTOH the same could be achieved by using grub2 to boot in PVH mode (with
my grub2 PVH series) as this variant is using the common Linux boot
entry, not the PVH specific one.


Juergen

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

[Xen-devel] [xen-4.8-testing test] 120067: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119771
 test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119771
 test-amd64-amd64-xl-multivcpu 15 guest-saverestore   fail REGR. vs. 119771
 test-amd64-amd64-xl-xsm  15 guest-saverestorefail REGR. vs. 119771
 test-amd64-i386-libvirt  15 guest-saverestorefail REGR. vs. 119771
 test-amd64-amd64-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 119771
 test-amd64-amd64-libvirt-xsm 15 guest-saverestorefail REGR. vs. 119771
 test-amd64-i386-xl-xsm   15 guest-saverestorefail REGR. vs. 119771
 test-amd64-amd64-xl-credit2  15 guest-saverestorefail REGR. vs. 119771
 test-amd64-i386-pair  22 guest-migrate/src_host/dst_host fail REGR. vs. 119771
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. 
vs. 119771
 test-amd64-amd64-xl  15 guest-saverestorefail REGR. vs. 119771
 test-amd64-i386-libvirt-xsm  15 guest-saverestorefail REGR. vs. 119771
 test-amd64-i386-xl   15 guest-saverestorefail REGR. vs. 119771
 test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 119771
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 
119771
 test-amd64-amd64-xl-qcow214 guest-saverestorefail REGR. vs. 119771
 test-amd64-amd64-pygrub  14 guest-saverestorefail REGR. vs. 119771
 test-amd64-amd64-amd64-pvgrub 14 guest-saverestore   fail REGR. vs. 119771
 test-amd64-amd64-i386-pvgrub 14 guest-saverestorefail REGR. vs. 119771
 test-amd64-amd64-libvirt-vhd 14 guest-saverestorefail REGR. vs. 119771
 test-amd64-i386-xl-raw   14 guest-saverestorefail REGR. vs. 119771

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-saverestorefail REGR. vs. 119771

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119771
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119771
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119771
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119771
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 119771
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 119771
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 119771
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 119771
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  85688075ccc22c12bd0fca2a2c269199938e104c
baseline version:
 xen  cb671efbf1fae302c0ee5ebd6e23564e319babc8

Last test of basis   120098  2018-02-28 16:01:46 Z0 days
Testing same since   120102  2018-02-28 19:01:39 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Kevin Tian 
  Razvan Cojocaru 
  Tamas K Lengyel 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   cb671efbf1..85688075cc  85688075ccc22c12bd0fca2a2c269199938e104c -> smoke

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

[Xen-devel] [ovmf test] 120070: all pass - PUSHED

[osstest service owner]

flight 120070 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120070/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f0c69b614cf56df1e7908574111d92864ca3ee9c
baseline version:
 ovmf f068aa038d09053c5dddea93c5f9576c51993546

Last test of basis   120040  2018-02-26 16:05:21 Z2 days
Testing same since   120070  2018-02-27 16:23:11 Z1 days1 attempts


People who touched revisions under test:
  Liming Gao 
  Ruiyu Ni 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   f068aa038d..f0c69b614c  f0c69b614cf56df1e7908574111d92864ca3ee9c -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH v2] pvcalls-front: 64-bit align flags

[Boris Ostrovsky]

On 02/28/2018 09:05 PM, Stefano Stabellini wrote:

We are using test_and_* operations on the status and flag fields of
struct sock_mapping. However, these functions require the operand to be
64-bit aligned on arm64. Currently, only status is 64-bit aligned.

Make status and flags explicitly 64-bit aligned.

Signed-off-by: Stefano Stabellini 



Reviewed-by: Boris Ostrovsky 


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

[Xen-devel] [PATCH v2] pvcalls-front: 64-bit align flags

[Stefano Stabellini]

We are using test_and_* operations on the status and flag fields of
struct sock_mapping. However, these functions require the operand to be
64-bit aligned on arm64. Currently, only status is 64-bit aligned.

Make status and flags explicitly 64-bit aligned.

Signed-off-by: Stefano Stabellini 

---
Changes in v2:
- use __attribute__((aligned(8)))
- add comments

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index ca5b773..582929e 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -73,20 +73,25 @@ struct sock_mapping {
wait_queue_head_t inflight_conn_req;
} active;
struct {
-   /* Socket status */
+   /*
+* Socket status, needs to be 64-bit aligned due to the
+* test_and_* functions which have this requirement on arm64.
+*/
 #define PVCALLS_STATUS_UNINITALIZED  0
 #define PVCALLS_STATUS_BIND  1
 #define PVCALLS_STATUS_LISTEN2
-   uint8_t status;
+   uint8_t status __attribute__((aligned(8)));
/*
 * Internal state-machine flags.
 * Only one accept operation can be inflight for a socket.
 * Only one poll operation can be inflight for a given socket.
+* flags needs to be 64-bit aligned due to the test_and_*
+* functions which have this requirement on arm64.
 */
 #define PVCALLS_FLAG_ACCEPT_INFLIGHT 0
 #define PVCALLS_FLAG_POLL_INFLIGHT   1
 #define PVCALLS_FLAG_POLL_RET2
-   uint8_t flags;
+   uint8_t flags __attribute__((aligned(8)));
uint32_t inflight_req_id;
struct sock_mapping *accept_map;
wait_queue_head_t inflight_accept_req;

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

Re: [Xen-devel] [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

[Stefano Stabellini]

On Wed, 28 Feb 2018, Julien Grall wrote:
> (+ Stefano and Wei)
> 
> Hi,
> 
> On 02/27/2018 12:40 PM, Oleksandr Andrushchenko wrote:
> > Please find some more clarifications on VirtIO use with Xen
> > (I would like to thank Xen community for helping with this)
> > 
> > 1. Possible security issues - VirtIO devices are PCI bus masters, thus
> > allowing real device (running, for example, in untrusted driver domain)
> > to get control over guest's memory by writing to its memory
> > 
> > 2. VirtIO currently uses GFNs written into the shared ring, without Xen
> > grants support. This will require generic grant-mapping/sharing layer
> > to be added to VirtIO.

This is important. VirtIO doesn't allow for driver domains (running the
backend inside a virtual machine). 


> > 3. VirtIO requires QEMU PCI emulation for setting up a device. Xen PV (and
> > PVH)
> > domains don't use QEMU for platform emulation in order to reduce attack
> > surface.
> > (PVH is in the process of gaining PCI config space emulation though, but it
> > is
> > optional, not a requirement)
> I don't think the support of PCI configuration space emulation for PVH would
> help there. The plan is to emulate in Xen, QEMU is still out of the equation
> there.

Right: there is no infrastructure to run IO emulation in userspace for
PV, PVH and ARM guests. We do have a QEMU instance running for PV, PVH
and ARM guests but only to implement PV backends, such as the vdispl
backend for example, which are handling asynchronous requests from
frontends using the traditional grant table maps/unmaps.


> > 4. Most of the PV drivers a guest uses at the moment are Xen PV drivers,
> > e.g. net,
> > block, console, so only virtio-gpu will require QEMU to run.
> > Although this use case would work on x86 it will require additional changes
> > to get this running on ARM, which is my target platform.
> 
> All type of guests but x86 HVM are not using QEMU for device emulation.
> 
> I would even be stronger here. Using QEMU would require a significant amount
> of engineering to make it work and increase the cost of safety certification
> for automotive use cases. So IHMO, the Xen PV display solution is the best.
> 
> The protocol was accepted and merged in Xen 4.9. This the standard way to have
> para-virtualized display for guests on Xen. Having the driver merged in Linux
> would help user to get out-of-box display in guest.

That's right. I don't think it really makes sense to introduce virtio
support in Xen on ARM as it is today.

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

Re: [Xen-devel] [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

[Stefano Stabellini]

Hi all,

just as a clarification, this patch series implements the frontend
driver for the "vdispl" protocol, which was reviewed, approved and
committed in xen.git back in April:

https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/displif.h

As Xen maintainer, if a competing PV DRM protocol proposal will come up,
I'll try to steer it into evolving the existing vdispl protocol, as we
like to have only one protocol per device class.

I am really looking forward to having this driver upstream in Linux.

Thanks Oleksandr!

Cheers,

Stefano

On Wed, 21 Feb 2018, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Hello!
> 
> This patch series adds support for Xen [1] para-virtualized
> frontend display driver. It implements the protocol from
> include/xen/interface/io/displif.h [2].
> Accompanying backend [3] is implemented as a user-space application
> and its helper library [4], capable of running as a Weston client
> or DRM master.
> Configuration of both backend and frontend is done via 
> Xen guest domain configuration options [5].
> 
> ***
> * Driver limitations
> ***
>  1. Configuration options 1.1 (contiguous display buffers) and 2 (backend
> allocated buffers) below are not supported at the same time.
> 
>  2. Only primary plane without additional properties is supported.
> 
>  3. Only one video mode supported which resolution is configured via XenStore.
> 
>  4. All CRTCs operate at fixed frequency of 60Hz.
> 
> ***
> * Driver modes of operation in terms of display buffers used
> ***
>  Depending on the requirements for the para-virtualized environment, namely
>  requirements dictated by the accompanying DRM/(v)GPU drivers running in both
>  host and guest environments, number of operating modes of para-virtualized
>  display driver are supported:
>   - display buffers can be allocated by either frontend driver or backend
>   - display buffers can be allocated to be contiguous in memory or not
> 
>  Note! Frontend driver itself has no dependency on contiguous memory for
>its operation.
> 
> ***
> * 1. Buffers allocated by the frontend driver.
> ***
> 
>  The below modes of operation are configured at compile-time via
>  frontend driver's kernel configuration.
> 
>  1.1. Front driver configured to use GEM CMA helpers
>   This use-case is useful when used with accompanying DRM/vGPU driver in
>   guest domain which was designed to only work with contiguous buffers,
>   e.g. DRM driver based on GEM CMA helpers: such drivers can only import
>   contiguous PRIME buffers, thus requiring frontend driver to provide
>   such. In order to implement this mode of operation para-virtualized
>   frontend driver can be configured to use GEM CMA helpers.
> 
>  1.2. Front driver doesn't use GEM CMA
>   If accompanying drivers can cope with non-contiguous memory then, to
>   lower pressure on CMA subsystem of the kernel, driver can allocate
>   buffers from system memory.
> 
>  Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
>may require IOMMU support on the platform, so accompanying DRM/vGPU
>hardware can still reach display buffer memory while importing PRIME
>buffers from the frontend driver.
> 
> ***
> * 2. Buffers allocated by the backend
> ***
> 
>  This mode of operation is run-time configured via guest domain configuration
>  through XenStore entries.
> 
>  For systems which do not provide IOMMU support, but having specific
>  requirements for display buffers it is possible to allocate such buffers
>  at backend side and share those with the frontend.
>  For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
>  physically contiguous memory, this allows implementing zero-copying
>  use-cases.
> 
> 
> I would like to thank at least, but not at last the following
> people/communities who helped this driver to happen ;)
> 
> 1. My team at EPAM for continuous support
> 2. Xen community for answering tons of questions on different
> modes of operation of the driver with respect to virtualized
> environment.
> 3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6]
> 4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7]
> 5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8]
> 
> Thank you,
> 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken
 build-armhf   5 host-build-prep  fail REGR. vs. 120098

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

version targeted for testing:
 xen  85688075ccc22c12bd0fca2a2c269199938e104c
baseline version:
 xen  cb671efbf1fae302c0ee5ebd6e23564e319babc8

Last test of basis   120098  2018-02-28 16:01:46 Z0 days
Testing same since   120102  2018-02-28 19:01:39 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Kevin Tian 
  Razvan Cojocaru 
  Tamas K Lengyel 

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



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

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

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

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

broken-job build-armhf broken

Not pushing.


commit 85688075ccc22c12bd0fca2a2c269199938e104c
Author: Andrew Cooper 
Date:   Wed Feb 21 18:10:00 2018 +

x86/hvm: Constify the read side of vlapic handling

This is in preparation to make hvm_x2apic_msr_read() take a const vcpu
pointer.  One modification is to alter vlapic_get_tmcct() to not use 
current.

This in turn needs an alteration to hvm_get_guest_time_fixed(), which is 
safe
because the only mutable action it makes is to take the domain plt lock.

Signed-off-by: Andrew Cooper 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 

commit 62e80dff59c779cb56755b419120529e3d7eb17d
Author: Andrew Cooper 
Date:   Mon Feb 26 14:23:03 2018 +

x86/vmx: Simplfy the default cases in vmx_msr_{read,write}_intercept()

The default case of vmx_msr_write_intercept() in particular is very tangled.

First of all, fold long_mode_do_msr_{read,write}() into their callers.  
These
functions were split out in the past because of the 32bit build of Xen, but 
it
is unclear why the cases weren't simply #ifdef'd in place.

Next, invert the vmx_write_guest_msr()/is_last_branch_msr() logic to break 
if
the condition is satisfied, rather than nesting if it wasn't.  This allows 
the
wrmsr_hypervisor_regs() call to be un-nested with respect to the other 
default
logic.

No practical difference from a guests point of view.

Signed-off-by: Andrew Cooper 
Acked-by: Kevin Tian 
Reviewed-by: Roger Pau Monné 

commit b68c4f1ebe4f413076c4915733a61c818b7dc73a
Author: Razvan Cojocaru 
Date:   Wed Feb 28 12:38:15 2018 +0200

x86/hvm: fix domain crash when CR3 has the noflush bit set

In hardware, when PCID support is enabled and the NOFLUSH bit is set
when writing a CR3 value, the hardware will clear that that bit and
change the CR3 without flushing the TLB. hvm_set_cr3(), however, was
ignoring this bit; the result was that post-vm_event checks detected
an invalid CR3 value and crashed the domain.

Handle NOFLUSH in hvm_set_cr3() by:
1. Clearing the bit
2. Passing a "noflush" flag to lower-level cr3 setting 

Re: [Xen-devel] pvh+vcpus startup issue

[xen]

On 28/02/18 9:35 PM, Juergen Gross wrote:

On 28/02/18 09:27, Roger Pau Monné wrote:

On Wed, Feb 28, 2018 at 01:34:31PM +1300, x...@randomwebstuff.com wrote:

Regards, Peter
http://ri.mu Startups start here.  Hosting.  DNS.  Offsite backups.  
Monitoring.  Email.

On 27/02/18 12:42 AM, Juergen Gross wrote:

On 22/02/18 21:38, x...@randomwebstuff.com wrote:

On 22/02/18 6:35 PM, Juergen Gross wrote:

On 22/02/18 05:37, x...@randomwebstuff.com wrote:

Hi.  I have a domU.  Its params file has: vcpus = 8.  It will start with
pv, but not type="pvh".  It will not start (on pvh) with vcpus = 7 or 6
or 5.  It does start with vcpus = 4.

I diffed the xl -v create logs, no difference there on either startup.

I grabbed the domU console output for a vcpus = 5 start (attached).  It
dies right after:

Dies as in crashes? Or simply gets stuck and there's no further output?


domU console:

[0.001000] cpu 0 spinlock event irq 5
[0.001000] Performance Events: unsupported p6 CPU model 23 no PMU driver, 
software events only.
[0.001000] Hierarchical SRCU implementation.
[0.001249] smp: Bringing up secondary CPUs ...
[0.001582] installing Xen timer for CPU 1
[0.001642] x86: Booting SMP configuration:
[0.001653]  node  #0, CPUs:  #1
[0.003157] cpu 1 spinlock event irq 11
[0.003305] installing Xen timer for CPU 2
[0.003385]  #2
[0.005152] cpu 2 spinlock event irq 17
[0.005311] installing Xen timer for CPU 3
[0.005375]  #3
[0.007107] cpu 3 spinlock event irq 23
[0.007341] installing Xen timer for CPU 4

Which exact kernel version is this, and can you also send the .config
Linux kernel file?


Xen domU params file:

cat /home/users/ot.glenn/params
kernel = "/home/users/ot.glenn/linux"
memory = 2000
swap = 128

This is not a xl option.


name = "ot.glenn"
ipaddr = "72.x.x.x"

Same here.


disk = [ 'phy:/dev/users/ot.glenn+centos6-x86_64-4.ext3,xvda1,w', 
'phy:/dev/users/ot.glenn+swapfs.swp,xvda9,w' ]
root = "/dev/xvda1 ro"
restart = 'onreboot'
console = 50089

And here.


type = "pvh"
vcpus = 5
vif = [ 'mac=aa:00:0b:67:50:64,bridge=br0' ]

Please add:

on_crash="preserve"

to your domain config file and after the domain crashed call:

/usr/lib/xen/bin/xenctx -C -s  -a 


Juergen
I commented out the non-standard options from the params file. (That did 
not appear to change any behavior).


After the vm is started it just quits/exits.  When I look at the domU 
console the last thing I see is:

[    0.007151] cpu 3 spinlock event irq 23
[    0.007341] installing Xen timer for CPU 4

The domU stays in the xl list output after the on_crash preserve option 
is added and I see this:
[root@host713 ~]# /usr/lib/xen/bin/xenctx -C -s 
/opt/xen/kernels/4.14.22-rh30-20180225201441.xenU.x86_64  -a 8

vcpu0 offline

vcpu1 offline

vcpu2 offline

vcpu3 offline

vcpu4:
rip: 810013a8
flags: 0012 nz a
rsp: 82603e18
rax:     rcx:     rdx: 0040
rbx: 0040    rsi: 82603e24    rdi: 0002
rbp:      r8:      r9: 
r10: 88007a418248    r11: 001800ff    r12: 
r13:     r14: 82d03680    r15: c938fe78
 cs: 0010     ss:      ds:      es: 
 fs:  @ 
 gs:  @ 88007a40/ +0x7a40/

cr0: 80050033
cr2: 
cr3: 02624000
cr4: 000406a0

dr0: 
dr1: 
dr2: 
dr3: 
dr6: 0ff0
dr7: 0400
Code (instr addr 810013a8)
cc cc cc cc cc cc cc cc cc cc cc cc cc b8 1d 00 00 00 0f 01 c1  cc 
cc cc cc cc cc cc cc cc cc


Config to the domU kernel is attached.  Since this is pvh I am not able 
to try too many different kernels (e.g. an old 2.6 or 3.0 kernel or even 
a 4.4 kernel) since those are not supported by pvh.


#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.14.22 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  broken
 test-armhf-armhf-xl   4 host-install(4)broken REGR. vs. 120098

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

version targeted for testing:
 xen  85688075ccc22c12bd0fca2a2c269199938e104c
baseline version:
 xen  cb671efbf1fae302c0ee5ebd6e23564e319babc8

Last test of basis   120098  2018-02-28 16:01:46 Z0 days
Testing same since   120102  2018-02-28 19:01:39 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Kevin Tian 
  Razvan Cojocaru 
  Tamas K Lengyel 

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



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

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

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

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

broken-job test-armhf-armhf-xl broken
broken-step test-armhf-armhf-xl host-install(4)

Not pushing.


commit 85688075ccc22c12bd0fca2a2c269199938e104c
Author: Andrew Cooper 
Date:   Wed Feb 21 18:10:00 2018 +

x86/hvm: Constify the read side of vlapic handling

This is in preparation to make hvm_x2apic_msr_read() take a const vcpu
pointer.  One modification is to alter vlapic_get_tmcct() to not use 
current.

This in turn needs an alteration to hvm_get_guest_time_fixed(), which is 
safe
because the only mutable action it makes is to take the domain plt lock.

Signed-off-by: Andrew Cooper 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 

commit 62e80dff59c779cb56755b419120529e3d7eb17d
Author: Andrew Cooper 
Date:   Mon Feb 26 14:23:03 2018 +

x86/vmx: Simplfy the default cases in vmx_msr_{read,write}_intercept()

The default case of vmx_msr_write_intercept() in particular is very tangled.

First of all, fold long_mode_do_msr_{read,write}() into their callers.  
These
functions were split out in the past because of the 32bit build of Xen, but 
it
is unclear why the cases weren't simply #ifdef'd in place.

Next, invert the vmx_write_guest_msr()/is_last_branch_msr() logic to break 
if
the condition is satisfied, rather than nesting if it wasn't.  This allows 
the
wrmsr_hypervisor_regs() call to be un-nested with respect to the other 
default
logic.

No practical difference from a guests point of view.

Signed-off-by: Andrew Cooper 
Acked-by: Kevin Tian 
Reviewed-by: Roger Pau Monné 

commit b68c4f1ebe4f413076c4915733a61c818b7dc73a
Author: Razvan Cojocaru 
Date:   Wed Feb 28 12:38:15 2018 +0200

x86/hvm: fix domain crash when CR3 has the noflush bit set

In hardware, when PCID support is enabled and the NOFLUSH bit is set
when writing a CR3 value, the hardware will clear that that bit and
change the CR3 without flushing the TLB. hvm_set_cr3(), however, was
ignoring this bit; the result was that post-vm_event checks detected
an invalid CR3 value and crashed the domain.

Handle NOFLUSH in hvm_set_cr3() by:
1. Clearing the bit
2. Passing a "noflush" flag to lower-level cr3 setting 

Re: [Xen-devel] [RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Paolo Bonzini]

On 28/02/2018 19:27, Maran Wilson wrote:
> Sorry for the delay between this version and the last -- it was mostly
> due to holidays and everyone being focused on security bug mitigation
> issues. Here are the links to the previous email threads in case it is
> helpful:
> 
> V3: https://lkml.org/lkml/2017/12/12/1230
> V2: https://lkml.org/lkml/2017/12/7/1624
> V1: https://lkml.org/lkml/2017/11/28/1280
> 
> Changes from v3:
> 
>  * Implemented Juergen's suggestion for refactoring and moving the PVH
>code so that CONFIG_XEN is no longer required for booting KVM guests
>via the PVH entry point.
>Functionally, nothing has changed from V3 really, but the patches
>look completely different now because of all the code movement and
>refactoring. Some of these patches can be combined, but I've left
>them very small in some cases to make the refactoring and code
>movement easier to review.
>My approach for refactoring has been to create a PVH entry layer that
>still has understanding and knowledge about Xen vs non-Xen guest types
>so that it can make run time decisions to handle either case, as
>opposed to going all the way and re-writing it to be a completely
>hypervisor agnostic and architecturally pure layer that is separate
>from guest type details. The latter seemed a bit overkill in this
>situation. And I've handled the complexity of having to support
>Qemu/KVM boot of kernels compiled with or without CONFIG_XEN via a
>pair of xen specific __weak routines that can be overridden in kernels
>that support Xen guests. Importantly, the __weak routines are for
>xen specific code only (not generic "guest type" specific code) so
>there is no clashing between xen version of the strong routine and,
>say, a KVM version of the same routine. But I'm sure there are many
>ways to skin this cat, so I'm open to alternate suggestions if there
>is a compelling reason for not using __weak in this situation.

As you say there are many ways to achieve this and I think your choice
is fully reasonable (the other alternative that comes to mind is a "Xen
detect" function that returns a struct of function pointers).

Apart from the placement of the files, it looks great.  Thanks!

Paolo

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

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Paolo Bonzini]

On 28/02/2018 22:08, Konrad Rzeszutek Wilk wrote:
> +obj-$(CONFIG_XEN_PVH) += pvh.o
> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
> +

Probably a better place for these would be
arch/x86/platform/pvh/{enlighten.c,head.S}.  (Just because there are no
.c or .S files in arch/x86).  Maybe Xen ought to be moved under
arch/x86/platform too.

Paolo

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

Re: [Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:27:58AM -0800, Maran Wilson wrote:
> Once hypervisors other than Xen start using the PVH entry point for
> starting VMs, we would like the option of being able to compile PVH entry
> capable kernels without enabling CONFIG_XEN and all the code that comes
> along with that. To allow that, we are moving the PVH code out of Xen and
> into files sitting at a higher level in the tree.
> 
> This patch is not introducing any code or functional changes, just moving
> files from one location to another.
> 
> Signed-off-by: Maran Wilson 
Reviewed-by: Konrad Rzeszutek Wilk 

Thank you!
> ---
>  MAINTAINERS | 1 +
>  arch/x86/Kbuild | 3 +++
>  arch/x86/{xen/xen-pvh.S => pvh-head.S}  | 0
>  arch/x86/{xen/enlighten_pvh.c => pvh.c} | 0
>  arch/x86/xen/Makefile   | 2 --
>  5 files changed, 4 insertions(+), 2 deletions(-)
>  rename arch/x86/{xen/xen-pvh.S => pvh-head.S} (100%)
>  rename arch/x86/{xen/enlighten_pvh.c => pvh.c} (100%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 93a12af4f180..dc89f3a279bd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15210,6 +15210,7 @@ L:xen-devel@lists.xenproject.org (moderated for 
> non-subscribers)
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
>  S:   Supported
>  F:   arch/x86/xen/
> +F:   arch/x86/*pvh*
>  F:   drivers/*/xen-*front.c
>  F:   drivers/xen/
>  F:   arch/x86/include/asm/xen/
> diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
> index 0038a2d10a7a..a4e5e3d348dc 100644
> --- a/arch/x86/Kbuild
> +++ b/arch/x86/Kbuild
> @@ -7,6 +7,9 @@ obj-$(CONFIG_KVM) += kvm/
>  # Xen paravirtualization support
>  obj-$(CONFIG_XEN) += xen/
>  
> +obj-$(CONFIG_XEN_PVH) += pvh.o
> +obj-$(CONFIG_XEN_PVH) += pvh-head.o
> +
>  # Hyper-V paravirtualization support
>  obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
>  
> diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/pvh-head.S
> similarity index 100%
> rename from arch/x86/xen/xen-pvh.S
> rename to arch/x86/pvh-head.S
> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/pvh.c
> similarity index 100%
> rename from arch/x86/xen/enlighten_pvh.c
> rename to arch/x86/pvh.c
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index d83cb5478f54..7e8145b33997 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -21,7 +21,6 @@ obj-y   := enlighten.o multicalls.o mmu.o irq.o 
> \
>  obj-$(CONFIG_XEN_PVHVM)  += enlighten_hvm.o mmu_hvm.o 
> suspend_hvm.o
>  obj-$(CONFIG_XEN_PV) += setup.o apic.o pmu.o suspend_pv.o \
>   p2m.o enlighten_pv.o mmu_pv.o
> -obj-$(CONFIG_XEN_PVH)+= enlighten_pvh.o
>  
>  obj-$(CONFIG_EVENT_TRACING) += trace.o
>  
> @@ -33,4 +32,3 @@ obj-$(CONFIG_XEN_DEBUG_FS)  += debugfs.o
>  obj-$(CONFIG_XEN_DOM0)   += vga.o
>  obj-$(CONFIG_SWIOTLB_XEN)+= pci-swiotlb-xen.o
>  obj-$(CONFIG_XEN_EFI)+= efi.o
> -obj-$(CONFIG_XEN_PVH)+= xen-pvh.o
> -- 
> 2.16.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [RFC PATCH v4 3/7] xen/pvh: Create a new file for Xen specific PVH code

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:27:59AM -0800, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> The first step in that direction is to create a new file that will
> eventually hold the Xen specific routines.
> 
> Signed-off-by: Maran Wilson 
> ---
>  arch/x86/pvh.c   |  1 -
>  arch/x86/xen/Makefile|  1 +
>  arch/x86/xen/enlighten_pvh.c | 11 +++
>  3 files changed, 12 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/xen/enlighten_pvh.c
> 
> diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
> index 436c4f003e17..b56cb5e7d6ac 100644
> --- a/arch/x86/pvh.c
> +++ b/arch/x86/pvh.c
> @@ -19,7 +19,6 @@
>   * xen_pvh and pvh_bootparams need to live in data segment since they

Perhaps remove 'xen_pvh' from there..
>   * are used after startup_{32|64}, which clear .bss, are invoked.
>   */
> -bool xen_pvh __attribute__((section(".data"))) = 0;
>  struct boot_params pvh_bootparams __attribute__((section(".data")));
>  
>  struct hvm_start_info pvh_start_info;
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index 7e8145b33997..ef6481a83768 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -21,6 +21,7 @@ obj-y   := enlighten.o multicalls.o mmu.o irq.o 
> \
>  obj-$(CONFIG_XEN_PVHVM)  += enlighten_hvm.o mmu_hvm.o 
> suspend_hvm.o
>  obj-$(CONFIG_XEN_PV) += setup.o apic.o pmu.o suspend_pv.o \
>   p2m.o enlighten_pv.o mmu_pv.o
> +obj-$(CONFIG_XEN_PVH)+= enlighten_pvh.o
>  
>  obj-$(CONFIG_EVENT_TRACING) += trace.o
>  
> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
> new file mode 100644
> index ..4b4e9cc78b8a
> --- /dev/null
> +++ b/arch/x86/xen/enlighten_pvh.c
> @@ -0,0 +1,11 @@
> +#include 
> +
> +/*
> + * PVH variables.
> + *
> + * The variables xen_pvh and pvh_bootparams need to live in the data segment

And remove 'and pvh_bootparams' here as well?

> + * since they are used after startup_{32|64} is invoked, which will clear the
> + * .bss segment.
> + */
> +bool xen_pvh __attribute__((section(".data"))) = 0;
> +
> -- 
> 2.16.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Konrad Rzeszutek Wilk]

On Wed, Feb 28, 2018 at 10:28:00AM -0800, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
> 
> This patch moves the small block of code used for initializing Xen PVH
> virtual machines into the Xen specific file. This initialization is not
> going to be needed for Qemu/KVM guests. Moving it out of the common file
> is going to allow us to compile kernels in the future without CONFIG_XEN
> that are still capable of being booted as a Qemu/KVM guest via the PVH
> entry point.
> 
> Signed-off-by: Maran Wilson 
Reviewed-by: Konrad Rzeszutek Wilk 

Thank you!

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

[Xen-devel] [xen-4.9-testing test] 120063: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
12

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 119954
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 119954
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 12
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 12
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 12
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 12
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 12
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg 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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 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  395cb3f9b4e31040564a2ca801a292e2cfa76818
baseline version:
 xen  88fbabc49158b0b858248fa124ef590c5df7782f

Last test of basis   12  2018-02-24 21:12:43 Z3 days
Testing same since   120063  2018-02-27 13:55:23 Z1 days1 attempts

Re: [Xen-devel] [PATCH 8/9] drm/xen-front: Implement GEM operations

[Oleksandr Andrushchenko]

On 02/28/2018 09:46 PM, Boris Ostrovsky wrote:

On 02/27/2018 01:52 AM, Oleksandr Andrushchenko wrote:

On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:

On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:

On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+    ret = gem_alloc_pages_array(xen_obj, size);
+    if (ret < 0) {
+    gem_free_pages_array(xen_obj);
+    goto fail;
+    }
+
+    ret = alloc_xenballooned_pages(xen_obj->num_pages,
+    xen_obj->pages);

Why are you allocating balloon pages?

in this use-case we map pages provided by the backend
(yes, I know this can be a problem from both security
POV and that DomU can die holding pages of Dom0 forever:
but still it is a configuration option, so user decides
if her use-case needs this and takes responsibility for
such a decision).

Perhaps I am missing something here but when you say "I know this can be
a problem from both security POV ..." then there is something wrong with
your solution.

well, in this scenario there are actually 2 concerns:
1. If DomU dies the pages/grants from Dom0/DomD cannot be
reclaimed back
2. Misbehaving guest may send too many requests to the
backend exhausting grant references and memory of Dom0/DomD
(this is the only concern from security POV). Please see [1]

But, we are focusing on embedded use-cases,
so those systems we use are not that "dynamic" with respect to 2).
Namely: we have fixed number of domains and their functionality
is well known, so we can do rather precise assumption on resource
usage. This is why I try to warn on such a use-case and rely on
the end user who understands the caveats


How will dom0/backend know whether or not to trust the front end (and
thus whether or not to provide provide pages to it)? Will there be
something in xenstore, for example, to indicate such trusted frontends?
Exactly, there is a dedicated xl configuration option available [1] for 
vdispl:


"be-alloc=BOOLEAN
Indicates if backend can be a buffer provider/allocator for this domain. 
See display protocol for details."


Thus, one can configure this per domain for trusted ones in corresponding
xl configuration files

-boris



I'll probably add more precise description of this use-case
clarifying what is that security POV, so there is no confusion

Hope this explanation answers your questions

-boris


Please see description of the buffering modes in xen_drm_front.h
specifically for backend allocated buffers:
  
***


   * 2. Buffers allocated by the backend
  
***


   *
   * This mode of operation is run-time configured via guest domain
configuration
   * through XenStore entries.
   *
   * For systems which do not provide IOMMU support, but having specific
   * requirements for display buffers it is possible to allocate such
buffers
   * at backend side and share those with the frontend.
   * For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting
   * physically contiguous memory, this allows implementing zero-copying
   * use-cases.


-boris


+    if (ret < 0) {
+    DRM_ERROR("Cannot allocate %zu ballooned pages: %d\n",
+    xen_obj->num_pages, ret);
+    goto fail;
+    }
+
+    return xen_obj;
+    }
+    /*
+ * need to allocate backing pages now, so we can share those
+ * with the backend
+ */
+    xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
+    xen_obj->pages = drm_gem_get_pages(_obj->base);
+    if (IS_ERR_OR_NULL(xen_obj->pages)) {
+    ret = PTR_ERR(xen_obj->pages);
+    xen_obj->pages = NULL;
+    goto fail;
+    }
+
+    return xen_obj;
+
+fail:
+    DRM_ERROR("Failed to allocate buffer with size %zu\n", size);
+    return ERR_PTR(ret);
+}
+


Thank you,
Oleksandr

[1]
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03100.html


[1] https://xenbits.xen.org/docs/4.10-testing/man/xl.cfg.5.html

   Indicates if backend can be a buffer provider/allocator for this
   domain. See display protocol for details.


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

Re: [Xen-devel] [PATCH 8/9] drm/xen-front: Implement GEM operations

[Boris Ostrovsky]

On 02/27/2018 01:52 AM, Oleksandr Andrushchenko wrote:
> On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:
>> On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:
>>> On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:
 On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
>>
> +    ret = gem_alloc_pages_array(xen_obj, size);
> +    if (ret < 0) {
> +    gem_free_pages_array(xen_obj);
> +    goto fail;
> +    }
> +
> +    ret = alloc_xenballooned_pages(xen_obj->num_pages,
> +    xen_obj->pages);
 Why are you allocating balloon pages?
>>> in this use-case we map pages provided by the backend
>>> (yes, I know this can be a problem from both security
>>> POV and that DomU can die holding pages of Dom0 forever:
>>> but still it is a configuration option, so user decides
>>> if her use-case needs this and takes responsibility for
>>> such a decision).
>>
>> Perhaps I am missing something here but when you say "I know this can be
>> a problem from both security POV ..." then there is something wrong with
>> your solution.
> well, in this scenario there are actually 2 concerns:
> 1. If DomU dies the pages/grants from Dom0/DomD cannot be
> reclaimed back
> 2. Misbehaving guest may send too many requests to the
> backend exhausting grant references and memory of Dom0/DomD
> (this is the only concern from security POV). Please see [1]
>
> But, we are focusing on embedded use-cases,
> so those systems we use are not that "dynamic" with respect to 2).
> Namely: we have fixed number of domains and their functionality
> is well known, so we can do rather precise assumption on resource
> usage. This is why I try to warn on such a use-case and rely on
> the end user who understands the caveats


How will dom0/backend know whether or not to trust the front end (and
thus whether or not to provide provide pages to it)? Will there be
something in xenstore, for example, to indicate such trusted frontends?

-boris


>
> I'll probably add more precise description of this use-case
> clarifying what is that security POV, so there is no confusion
>
> Hope this explanation answers your questions
>> -boris
>>
>>> Please see description of the buffering modes in xen_drm_front.h
>>> specifically for backend allocated buffers:
>>>  
>>> ***
>>>
>>>   * 2. Buffers allocated by the backend
>>>  
>>> ***
>>>
>>>   *
>>>   * This mode of operation is run-time configured via guest domain
>>> configuration
>>>   * through XenStore entries.
>>>   *
>>>   * For systems which do not provide IOMMU support, but having specific
>>>   * requirements for display buffers it is possible to allocate such
>>> buffers
>>>   * at backend side and share those with the frontend.
>>>   * For example, if host domain is 1:1 mapped and has DRM/GPU hardware
>>> expecting
>>>   * physically contiguous memory, this allows implementing zero-copying
>>>   * use-cases.
>>>
 -boris

> +    if (ret < 0) {
> +    DRM_ERROR("Cannot allocate %zu ballooned pages: %d\n",
> +    xen_obj->num_pages, ret);
> +    goto fail;
> +    }
> +
> +    return xen_obj;
> +    }
> +    /*
> + * need to allocate backing pages now, so we can share those
> + * with the backend
> + */
> +    xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
> +    xen_obj->pages = drm_gem_get_pages(_obj->base);
> +    if (IS_ERR_OR_NULL(xen_obj->pages)) {
> +    ret = PTR_ERR(xen_obj->pages);
> +    xen_obj->pages = NULL;
> +    goto fail;
> +    }
> +
> +    return xen_obj;
> +
> +fail:
> +    DRM_ERROR("Failed to allocate buffer with size %zu\n", size);
> +    return ERR_PTR(ret);
> +}
> +
>
> Thank you,
> Oleksandr
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03100.html
>


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

Re: [Xen-devel] [PATCH] xen/pirq: fix error path cleanup when binding MSIs

[Juergen Gross]

On 28/02/18 10:19, Roger Pau Monne wrote:
> Current cleanup in the error path of xen_bind_pirq_msi_to_irq is
> wrong. First of all there's an off-by-one in the cleanup loop, which
> can lead to unbinding wrong IRQs.
> 
> Secondly IRQs not bound won't be freed, thus leaking IRQ numbers.
> 
> Note that there's no need to differentiate between bound and unbound
> IRQs when freeing them, __unbind_from_irq will deal with both of them
> correctly.
> 
> Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
> Reported-by: Hooman Mirhadi 
> Signed-off-by: Roger Pau Monné 

Committed to xen/tip for-linus-4.16a


Juergen

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

Re: [Xen-devel] [PATCH] xen-netfront: Fix hang on device removal

[Juergen Gross]

On 28/02/18 13:23, Jason Andryuk wrote:
> A toolstack may delete the vif frontend and backend xenstore entries
> while xen-netfront is in the removal code path.  In that case, the
> checks for xenbus_read_driver_state would return XenbusStateUnknown, and
> xennet_remove would hang indefinitely.  This hang prevents system
> shutdown.
> 
> xennet_remove must be able to handle XenbusStateUnknown, and
> netback_changed must also wake up the wake_queue for that state as well.
> 
> Fixes: 5b5971df3bc2 ("xen-netfront: remove warning when unloading module")
> 
> Signed-off-by: Jason Andryuk 
> Cc: Eduardo Otubo 

Committed to xen/tip for-linus-4.16a


Juergen

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

Re: [Xen-devel] [PATCH v2 1/2] README: require Python 2.4 or newer

[Doug Goldstein]

On 2/28/18 1:18 PM, Doug Goldstein wrote:

> change from v1:
> - changed from Python 2.6 to Python 2.4 based on

Not sure what happened to my mind here

based on feedback on the list of folks still having environments where
Python 2.4 is in use.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 2/2] xen/tools: support Python 2 and Python 3

[Doug Goldstein]

These changes should make it possible to support modern Pythons as well
as the oldest Python 2 still supported.

Signed-off-by: Doug Goldstein 
---
CC: Andrew Cooper 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
---
changes since v1:
- switched to print() in cases where it works from Andrew Cooper
- dropped long() magic from Andrew Cooper. This is unnecessary with
  Python 2.4 and newer.
---
 xen/tools/compat-build-header.py |  2 +-
 xen/tools/compat-build-source.py |  2 +-
 xen/tools/gen-cpuid.py   | 34 --
 xen/tools/get-fields.sh  |  2 +-
 4 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/xen/tools/compat-build-header.py b/xen/tools/compat-build-header.py
index 32421b645b..b85c43f13f 100755
--- a/xen/tools/compat-build-header.py
+++ b/xen/tools/compat-build-header.py
@@ -23,4 +23,4 @@ pats = [
 for line in sys.stdin.readlines():
 for pat in pats:
 line = re.subn(pat[0], pat[1], line)[0]
-print line.rstrip()
+print(line.rstrip())
diff --git a/xen/tools/compat-build-source.py b/xen/tools/compat-build-source.py
index 595bc3ff58..c664eb85e6 100755
--- a/xen/tools/compat-build-source.py
+++ b/xen/tools/compat-build-source.py
@@ -26,4 +26,4 @@ for pat in pats:
 for line in sys.stdin.readlines():
 for pat in pats:
 line = re.sub(pat[0], pat[1], line)
-print line.rstrip()
+print(line.rstrip())
diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
index 613b909c3d..6359afb704 100755
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -3,6 +3,10 @@
 
 import sys, os, re
 
+if (sys.version_info > (3, 0)):
+def xrange(x):
+return range(x)
+
 class Fail(Exception):
 pass
 
@@ -98,13 +102,13 @@ def parse_definitions(state):
 def featureset_to_uint32s(fs, nr):
 """ Represent a featureset as a list of C-compatible uint32_t's """
 
-bitmap = 0L
+bitmap = 0
 for f in fs:
-bitmap |= 1L << f
+bitmap |= 1 << f
 
 words = []
 while bitmap:
-words.append(bitmap & ((1L << 32) - 1))
+words.append(bitmap & ((1 << 32) - 1))
 bitmap >>= 32
 
 assert len(words) <= nr
@@ -276,8 +280,8 @@ def crunch_numbers(state):
 # To debug, uncomment the following lines:
 # def repl(l):
 # return "[" + ", ".join((state.names[x] for x in l)) + "]"
-# print >>sys.stderr, "Feature %s, seen %s, to_process %s " % \
-# (state.names[feat], repl(seen), repl(to_process))
+# sys.stderr.write("Feature %s, seen %s, to_process %s \n" % \
+# (state.names[feat], repl(seen), repl(to_process)))
 
 f = to_process.pop(0)
 
@@ -293,7 +297,12 @@ def crunch_numbers(state):
 state.deep_features = featureset_to_uint32s(deps.keys(), nr_entries)
 state.nr_deep_deps = len(state.deep_deps.keys())
 
-for k, v in state.deep_deps.iteritems():
+try:
+_tmp = state.deep_deps.iteritems()
+except AttributeError:
+_tmp = state.deep_deps.items()
+
+for k, v in _tmp:
 state.deep_deps[k] = featureset_to_uint32s(v, nr_entries)
 
 # Calculate the bitfield name declarations
@@ -410,7 +419,8 @@ def open_file_or_fd(val, mode, buffering):
 else:
 return open(val, mode, buffering)
 
-except StandardError, e:
+except StandardError:
+e = sys.exc_info()[1]
 if fd != -1:
 raise Fail("Unable to open fd %d: %s: %s" %
(fd, e.__class__.__name__, e))
@@ -453,10 +463,14 @@ def main():
 if __name__ == "__main__":
 try:
 sys.exit(main())
-except Fail, e:
-print >>sys.stderr, "%s:" % (sys.argv[0],), e
+except Fail:
+e = sys.exc_info()[1]
+sys.stderr.write("%s:" % (sys.argv[0],))
+sys.stderr.write(e)
+sys.stderr.write("\n")
 sys.exit(1)
-except SystemExit, e:
+except SystemExit:
+e = sys.exc_info()[1]
 sys.exit(e.code)
 except KeyboardInterrupt:
 sys.exit(2)
diff --git a/xen/tools/get-fields.sh b/xen/tools/get-fields.sh
index 887feec370..45a0e2ed50 100644
--- a/xen/tools/get-fields.sh
+++ b/xen/tools/get-fields.sh
@@ -139,7 +139,7 @@ handle_field ()
local tag=$(echo "$5" | ${PYTHON} -c '
 import re,sys
 for line in sys.stdin.readlines():
-print re.subn(r"\s*(struct|union)\s+(compat_)?(\w+)\s.*", r"\3", 
line)[0].rstrip()
+sys.stdout.write(re.subn(r"\s*(struct|union)\s+(compat_)?(\w+)\s.*", 
r"\3", line)[0].rstrip() + "\n")
 ')
echo " \\"
printf %s "${1}XLAT_$tag(&(_d_)->$3, &(_s_)->$3);"
-- 
2.16.1

[Xen-devel] [PATCH v2 1/2] README: require Python 2.4 or newer

[Doug Goldstein]

Increase the minimum required Python to 2.4 or newer.

Signed-off-by: Doug Goldstein 
---
CC: Andrew Cooper 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
---
change from v1:
- changed from Python 2.6 to Python 2.4 based on

While the tools are broke with Python 2.4 currently there are
some scripts that people have an interest in still being able
to run with Python 2.4 so changed the documented information there.
I'm working on some updates to the Travis CI test loop (actually
switching to GitLab CI) to give us more flexibility in what is
being tested.

See
https://lists.xenproject.org/archives/html/xen-devel/2017-09/msg02389.html
for context on the build failures in tools with Python 2.4
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index e96cdd2862..4ed03b7fe2 100644
--- a/README
+++ b/README
@@ -46,7 +46,7 @@ provided by your OS distributor:
 - GCC 4.8 or later
 - GNU Binutils 2.24 or later
 * Development install of zlib (e.g., zlib-dev)
-* Development install of Python v2.3 or later (e.g., python-dev)
+* Development install of Python v2.4 or later (e.g., python-dev)
 * Development install of curses (e.g., libncurses-dev)
 * Development install of openssl (e.g., openssl-dev)
 * Development install of x11 (e.g. xorg-x11-dev)
-- 
2.16.1


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

Re: [Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

[Andrew Cooper]

On 28/02/18 16:40, Jan Beulich wrote:
 On 26.02.18 at 18:35,  wrote:
>> --- a/xen/arch/x86/hvm/viridian.c
>> +++ b/xen/arch/x86/hvm/viridian.c
>> @@ -554,13 +554,11 @@ static void update_reference_tsc(struct domain *d, 
>> bool_t initialize)
>>  put_page_and_type(page);
>>  }
>>  
>> -int wrmsr_viridian_regs(uint32_t idx, uint64_t val)
>> +int guest_wrmsr_viridian(struct vcpu *v, uint32_t idx, uint64_t val)
> unsigned int would do instead of uint32_t (same on the read side).

MSRs are architecturally uint32_t, and your proposed coding style
suggestions would have uint32_t here.  At the moment, uint32_t is used
consistently throughout the new MSR infrastructure.

>
>> @@ -173,11 +175,26 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,  
>> uint64_t *val)
>> _MSR_MISC_FEATURES_CPUID_FAULTING;
>>  break;
>>  
>> +case 0x4000 ... 0x41ff:
> As was already suggested, these want to gain #define-s.
>
> Reviewed-by: Jan Beulich 
> with at least the latter taken care of.

Just like on the CPUID side, the range of valid MSRs depend on the
fallthrough pattern, and which hypervisor(s) we are emulating for.

This is clearer by the end of the subsequent patch, but the logic is far
easier to follow without these numbers being hidden.

~Andrew

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

Re: [Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

[Andrew Cooper]

On 27/02/18 14:38, Paul Durrant wrote:
>> @@ -698,13 +697,11 @@ void viridian_time_ref_count_thaw(struct domain
>> *d)
>>  trc->off = (int64_t)trc->val - raw_trc_val(d);
>>  }
>>
>> -int rdmsr_viridian_regs(uint32_t idx, uint64_t *val)
>> +int guest_rdmsr_viridian(const struct vcpu *v, uint32_t idx, uint64_t *val)
>>  {
>> -struct vcpu *v = current;
>>  struct domain *d = v->domain;
>> -
>> -if ( !is_viridian_domain(d) )
>> -return 0;
>> +
>> +ASSERT(is_viridian_domain(d));
>>
>>  switch ( idx )
>>  {
>> @@ -725,7 +722,7 @@ int rdmsr_viridian_regs(uint32_t idx, uint64_t *val)
>>
>>  case HV_X64_MSR_TSC_FREQUENCY:
>>  if ( viridian_feature_mask(d) & HVMPV_no_freq )
>> -return 0;
>> +goto gp_fault;
>>
>>  perfc_incr(mshv_rdmsr_tsc_frequency);
>>  *val = (uint64_t)d->arch.tsc_khz * 1000ull;
>> @@ -733,7 +730,7 @@ int rdmsr_viridian_regs(uint32_t idx, uint64_t *val)
>>
>>  case HV_X64_MSR_APIC_FREQUENCY:
>>  if ( viridian_feature_mask(d) & HVMPV_no_freq )
>> -return 0;
>> +goto gp_fault;
>>
>>  perfc_incr(mshv_rdmsr_apic_frequency);
>>  *val = 10ull / APIC_BUS_CYCLE_NS;
>> @@ -757,7 +754,7 @@ int rdmsr_viridian_regs(uint32_t idx, uint64_t *val)
>>
>>  case HV_X64_MSR_REFERENCE_TSC:
>>  if ( !(viridian_feature_mask(d) & HVMPV_reference_tsc) )
>> -return 0;
> I have a recollection that for at least one version of Windows, when debug 
> mode is enabled, it reads the reference TSC MSR regardless of whether the 
> feature is enabled or not so this change may well cause guest boot failures.
> In general I would be wary of #GP faulting where the current code does not. I 
> think the current code is almost certainly too liberal even in the face of 
> buggy versions of Windows but the new code might be too conservative. It will 
> need some testing.
>
> In principle though...
>
> Reviewed-by: Paul Durrant 

The current code is absolutely wrong, because it falls back into the
default path and continues looking for a result.  On the read side, that
ends up leaking in L$N-1 hypervisor leaves if they are present, while
the write side ends up discarding the result.

ISTR it was only one single pre-release build of windows which failed to
check for the TSC feature, so I'm not sure we need to worry.

If we do find that it is a problem in practice, then the correct course
of action is to explicitly fill with 0 and return X86EMUL_OKAY, which at
least means that we've dealt with the request.

I've booted Win7 and Win10 with the code in this state.  Are you happy
for us to go with this provisionally, and revert back to an explicit
discard if we encounter problems?

~Andrew

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

Re: [Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

[Andrew Cooper]

On 27/02/18 14:13, Roger Pau Monné wrote:
> On Mon, Feb 26, 2018 at 05:35:15PM +, Andrew Cooper wrote:
>> @@ -173,11 +175,26 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, 
>> uint64_t *val)
>> _MSR_MISC_FEATURES_CPUID_FAULTING;
>>  break;
>>  
>> +case 0x4000 ... 0x41ff:
> I think it would be clearer to use VIRIDIAN_MSR_MIN ...
> VIRIDIAN_MSR_MAX.
>
> Or else the defines should be removed because you are removing all of
> it's users.

Both of these would be wrong.  I'll remove them instead.

The problem here, and moreso with the following patch, is that the range
of acceptable MSRs depends on which hypervisor we are emulating.  Using
named labels here actually confuses rather than helps matters.

~Andrew

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

[Xen-devel] [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.

Signed-off-by: Maran Wilson 
---
 include/xen/interface/hvm/start_info.h | 50 +-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/include/xen/interface/hvm/start_info.h 
b/include/xen/interface/hvm/start_info.h
index 648415976ead..80cfbd35c1af 100644
--- a/include/xen/interface/hvm/start_info.h
+++ b/include/xen/interface/hvm/start_info.h
@@ -33,7 +33,7 @@
  *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
  *|| ("xEn3" with the 0x80 bit of the "E" set).
  *  4 ++
- *| version| Version of this structure. Current version is 0. New
+ *| version| Version of this structure. Current version is 1. New
  *|| versions are guaranteed to be backwards-compatible.
  *  8 ++
  *| flags  | SIF_xxx flags.
@@ -48,6 +48,15 @@
  * 32 ++
  *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
  * 40 ++
+ *| memmap_paddr   | Physical address of the (optional) memory map. Only
+ *|| present in version 1 and newer of the structure.
+ * 48 ++
+ *| memmap_entries | Number of entries in the memory map table. Only
+ *|| present in version 1 and newer of the structure.
+ *|| Zero if there is no memory map being provided.
+ * 52 ++
+ *| reserved   | Version 1 and newer only.
+ * 56 ++
  *
  * The layout of each entry in the module structure is the following:
  *
@@ -62,10 +71,34 @@
  *| reserved   |
  * 32 ++
  *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 ++
+ *| addr   | Base address
+ *  8 ++
+ *| size   | Size of mapping in bytes
+ * 16 ++
+ *| type   | Type of mapping as defined between the hypervisor
+ *|| and guest it's starting. E820_TYPE_xxx, for example.
+ * 20 +|
+ *| reserved   |
+ * 24 ++
+ *
  * The address and sizes are always a 64bit little endian unsigned integer.
  *
  * NB: Xen on x86 will always try to place all the data below the 4GiB
  * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:
+ *
+ * Version 1:  Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ * padding) to the end of the hvm_start_info struct. These new
+ * fields can be used to pass a memory map to the guest. The
+ * memory map is optional and so guests that understand version 1
+ * of the structure must check that memmap_entries is non-zero
+ * before trying to read the memory map.
  */
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
 
@@ -86,6 +119,14 @@ struct hvm_start_info {
 uint64_t cmdline_paddr; /* Physical address of the command line. */
 uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
 /* structure.*/
+uint64_t memmap_paddr; /* Physical address of an array of   */
+   /* hvm_memmap_table_entry. Only present in   */
+   /* version 1 and newer of the structure  */
+uint32_t memmap_entries;   /* Number of entries in the memmap table.*/
+   /* Only present in version 1 and newer of*/
+   /* the structure. Value will be zero if  */
+   /* there is no memory map being provided.*/
+uint32_t reserved;
 };
 
 struct hvm_modlist_entry {
@@ -95,4 +136,11 @@ struct hvm_modlist_entry {
 uint64_t reserved;
 };
 
+struct hvm_memmap_table_entry {
+uint64_t addr; /* Base address of the memory region */
+uint64_t size; /* Size of the memory region in bytes*/
+uint32_t type; /* Mapping type  */
+uint32_t reserved;
+};
+
 #endif /* __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__ */
-- 
2.16.1


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

Re: [Xen-devel] PVH backports to 4.9 and 4.8

[Hans-Joachim Kliemeck]

> George Dunlap:
>> /On 01/23/2018 04:06 AM, Simon Gaiser wrote:/
>> /> George Dunlap:/
>> />> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport/
>> />> the PVH mode from 4.10 to 4.9 and 4.8. This will first allow people/
>> />> able to run PVH kernels to switch their PV guests directly to PVH/
>> />> guests; and second, eventually enable the backport of patches which/
>> />> will enable transparent changing of PV guests into PVH guests./
>> />>/
>> />> All of the hypervisor support seems to have existed already in 4.8, so/
>> />> the only backports involve toolstack patches./
>> />>/
>> />> I've put up two trees for a first-cut backport of the PVH/
>> />> functionality, to 4.9 and 4.8 here:/
>> />>/
>> />> git://xenbits.xen.org/people/gdunlap/xen.git/
>> />>/
>> />> Branches out/pvh-backport/4.8/v1 and out/pvh-backport/4.9/v1/
>> />>/
>> />> Below are the patches backported from 4.10 to 4.9 (23 patches total):/
>> /> [...]/
>> />/
>> /> So future 4.8 releases will include the backports, right? Asking because/
>> /> the AFAICS the 4.8.3-pre-shim-comet branch include them but staging-4.8/
>> /> does not./
>> //
>> /Some of us have had informal conversations about backporting PVH and/
>> /Comet host/toolstack patches to 4.8, and a number of us think it's a/
>> /good idea, but we haven't had an official discussion with all the/
>> /stakeholders yet. We'll come back to it once more of the fires have/
>> /been put out./
>> //
>> /Feel free to remind us in a month or so if you still haven't seen any/
>> /patches in the stable-4.8 branch. :-)/
> Ok, thank you for the quick reply. In Qubes we are using PVH with 4.8
> using the old device_model_version=none config option. And changing this
> would be much easier before release (So the change should be in our rc
> now). Anyway if it's not decided yet, we will have to guess what ends up
> in future 4.8.z releases.
>
>

Hi,

is there an update for the backports for 4.8 and 4.9? Or is there some
documentation available to see which parts are missing on 4.9 vs 4.10
(or 4.8 vs 4.10) to get PVH running (device_model_version=none, ...)?

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

[Xen-devel] [RFC PATCH v4 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.

There already exists an ABI to allow this for Xen PVH guests and the ABI
is supported by Linux and FreeBSD:

   https://xenbits.xen.org/docs/unstable/misc/pvh.html

This patch enables Qemu to use that same entry point for booting KVM
guests.

Signed-off-by: Maran Wilson 
---
 arch/x86/Kbuild |  4 ++--
 arch/x86/pvh.c  | 43 ---
 2 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index a4e5e3d348dc..e9dc0f1c9d32 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,8 +7,8 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
-obj-$(CONFIG_XEN_PVH) += pvh.o
-obj-$(CONFIG_XEN_PVH) += pvh-head.o
+obj-$(CONFIG_PVH) += pvh.o
+obj-$(CONFIG_PVH) += pvh-head.o
 
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index 6e9f6a6e97b3..97042d11342f 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -7,6 +7,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include 
 #include 
 
@@ -34,11 +37,28 @@ void __init __weak mem_map_via_hcall(struct boot_params 
*ptr __maybe_unused)
BUG();
 }
 
-static void __init init_pvh_bootparams(void)
+static void __init init_pvh_bootparams(bool xen_guest)
 {
memset(_bootparams, 0, sizeof(pvh_bootparams));
 
-   mem_map_via_hcall(_bootparams);
+   if ((pvh_start_info.version > 0) && (pvh_start_info.memmap_entries)) {
+   struct hvm_memmap_table_entry *ep;
+   int i;
+
+   ep = __va(pvh_start_info.memmap_paddr);
+   pvh_bootparams.e820_entries = pvh_start_info.memmap_entries;
+
+   for (i = 0; i < pvh_bootparams.e820_entries ; i++, ep++) {
+   pvh_bootparams.e820_table[i].addr = ep->addr;
+   pvh_bootparams.e820_table[i].size = ep->size;
+   pvh_bootparams.e820_table[i].type = ep->type;
+   }
+   } else if (xen_guest) {
+   mem_map_via_hcall(_bootparams);
+   } else {
+   /* Non-xen guests are not supported by version 0 */
+   BUG();
+   }
 
if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
@@ -69,7 +89,7 @@ static void __init init_pvh_bootparams(void)
 * environment (i.e. hardware_subarch 0).
 */
pvh_bootparams.hdr.version = 0x212;
-   pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
+   pvh_bootparams.hdr.type_of_loader = ((xen_guest ? 0x9 : 0xb) << 4) | 0;
 }
 
 /*
@@ -82,13 +102,10 @@ void __init __weak xen_pvh_init(void)
BUG();
 }
 
-/*
- * When we add support for other hypervisors like Qemu/KVM, this routine can
- * selectively invoke the appropriate initialization based on guest type.
- */
-static void hypervisor_specific_init(void)
+static void hypervisor_specific_init(bool xen_guest)
 {
-   xen_pvh_init();
+   if (xen_guest)
+   xen_pvh_init();
 }
 
 /*
@@ -97,13 +114,17 @@ static void hypervisor_specific_init(void)
  */
 void __init xen_prepare_pvh(void)
 {
+
+   u32 msr = xen_cpuid_base();
+   bool xen_guest = !!msr;
+
if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
pvh_start_info.magic);
BUG();
}
 
-   hypervisor_specific_init();
+   hypervisor_specific_init(xen_guest);
 
-   init_pvh_bootparams();
+   init_pvh_bootparams(xen_guest);
 }
-- 
2.16.1


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

[Xen-devel] [RFC PATCH v4 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common code

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

This patch moves the small block of code used for initializing Xen PVH
virtual machines into the Xen specific file. This initialization is not
going to be needed for Qemu/KVM guests. Moving it out of the common file
is going to allow us to compile kernels in the future without CONFIG_XEN
that are still capable of being booted as a Qemu/KVM guest via the PVH
entry point.

Signed-off-by: Maran Wilson 
---
 arch/x86/pvh.c   | 28 
 arch/x86/xen/enlighten_pvh.c | 18 +-
 2 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index b56cb5e7d6ac..2d7a7f4958cb 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -72,26 +72,38 @@ static void __init init_pvh_bootparams(void)
pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
 }
 
+/*
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide the required override for this routine.
+ */
+void __init __weak xen_pvh_init(void)
+{
+   xen_raw_printk("Error: Missing xen PVH initialization\n");
+   BUG();
+}
+
+/*
+ * When we add support for other hypervisors like Qemu/KVM, this routine can
+ * selectively invoke the appropriate initialization based on guest type.
+ */
+static void hypervisor_specific_init(void)
+{
+   xen_pvh_init();
+}
+
 /*
  * This routine (and those that it might call) should not use
  * anything that lives in .bss since that segment will be cleared later.
  */
 void __init xen_prepare_pvh(void)
 {
-   u32 msr;
-   u64 pfn;
-
if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
pvh_start_info.magic);
BUG();
}
 
-   xen_pvh = 1;
-
-   msr = cpuid_ebx(xen_cpuid_base() + 2);
-   pfn = __pa(hypercall_page);
-   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+   hypervisor_specific_init();
 
init_pvh_bootparams();
 }
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 4b4e9cc78b8a..833c441a20df 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,4 +1,9 @@
-#include 
+#include 
+
+#include 
+
+#include 
+#include 
 
 /*
  * PVH variables.
@@ -9,3 +14,14 @@
  */
 bool xen_pvh __attribute__((section(".data"))) = 0;
 
+void __init xen_pvh_init(void)
+{
+   u32 msr;
+   u64 pfn;
+
+   xen_pvh = 1;
+
+   msr = cpuid_ebx(xen_cpuid_base() + 2);
+   pfn = __pa(hypercall_page);
+   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+}
-- 
2.16.1


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

[Xen-devel] [RFC PATCH v4 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

[Maran Wilson]

Once hypervisors other than Xen start using the PVH entry point for
starting VMs, we would like the option of being able to compile PVH entry
capable kernels without enabling CONFIG_XEN and all the code that comes
along with that. To allow that, we are moving the PVH code out of Xen and
into files sitting at a higher level in the tree.

This patch is not introducing any code or functional changes, just moving
files from one location to another.

Signed-off-by: Maran Wilson 
---
 MAINTAINERS | 1 +
 arch/x86/Kbuild | 3 +++
 arch/x86/{xen/xen-pvh.S => pvh-head.S}  | 0
 arch/x86/{xen/enlighten_pvh.c => pvh.c} | 0
 arch/x86/xen/Makefile   | 2 --
 5 files changed, 4 insertions(+), 2 deletions(-)
 rename arch/x86/{xen/xen-pvh.S => pvh-head.S} (100%)
 rename arch/x86/{xen/enlighten_pvh.c => pvh.c} (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..dc89f3a279bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15210,6 +15210,7 @@ L:  xen-devel@lists.xenproject.org (moderated for 
non-subscribers)
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
 S: Supported
 F: arch/x86/xen/
+F: arch/x86/*pvh*
 F: drivers/*/xen-*front.c
 F: drivers/xen/
 F: arch/x86/include/asm/xen/
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 0038a2d10a7a..a4e5e3d348dc 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -7,6 +7,9 @@ obj-$(CONFIG_KVM) += kvm/
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
 
+obj-$(CONFIG_XEN_PVH) += pvh.o
+obj-$(CONFIG_XEN_PVH) += pvh-head.o
+
 # Hyper-V paravirtualization support
 obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
 
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/pvh-head.S
similarity index 100%
rename from arch/x86/xen/xen-pvh.S
rename to arch/x86/pvh-head.S
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/pvh.c
similarity index 100%
rename from arch/x86/xen/enlighten_pvh.c
rename to arch/x86/pvh.c
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index d83cb5478f54..7e8145b33997 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -21,7 +21,6 @@ obj-y := enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
 obj-$(CONFIG_XEN_PV)   += setup.o apic.o pmu.o suspend_pv.o \
p2m.o enlighten_pv.o mmu_pv.o
-obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
@@ -33,4 +32,3 @@ obj-$(CONFIG_XEN_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_XEN_DOM0) += vga.o
 obj-$(CONFIG_SWIOTLB_XEN)  += pci-swiotlb-xen.o
 obj-$(CONFIG_XEN_EFI)  += efi.o
-obj-$(CONFIG_XEN_PVH)  += xen-pvh.o
-- 
2.16.1


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

[Xen-devel] [RFC PATCH v4 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The original design for PVH entry in Xen guests relies on being able to
obtain the memory map from the hypervisor using a hypercall. When we
extend the PVH entry ABI to support other hypervisors like Qemu/KVM,
a new mechanism will be added that allows the guest to get the memory
map without needing to use hypercalls.

For Xen guests, the hypercall approach will still be supported. In
preparation for adding support for other hypervisors, we can move the
code that uses hypercalls into the Xen specific file. This will allow us
to compile kernels in the future without CONFIG_XEN that are still capable
of being booted as a Qemu/KVM guest via the PVH entry point.

Signed-off-by: Maran Wilson 
---
 arch/x86/pvh.c   | 28 ++--
 arch/x86/xen/enlighten_pvh.c | 20 
 2 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index 2d7a7f4958cb..6e9f6a6e97b3 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -7,9 +7,6 @@
 #include 
 #include 
 
-#include 
-#include 
-
 #include 
 #include 
 
@@ -24,21 +21,24 @@ struct boot_params pvh_bootparams 
__attribute__((section(".data")));
 struct hvm_start_info pvh_start_info;
 unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
 
+/*
+ * Xen guests are able to obtain the memory map from the hypervisor via the
+ * HYPERVISOR_memory_op hypercall.
+ * If we are trying to boot a Xen PVH guest, it is expected that the kernel
+ * will have been configured to provide an override for this routine to do
+ * just that.
+ */
+void __init __weak mem_map_via_hcall(struct boot_params *ptr __maybe_unused)
+{
+   xen_raw_printk("Error: Could not find memory map\n");
+   BUG();
+}
+
 static void __init init_pvh_bootparams(void)
 {
-   struct xen_memory_map memmap;
-   int rc;
-
memset(_bootparams, 0, sizeof(pvh_bootparams));
 
-   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
-   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
-   rc = HYPERVISOR_memory_op(XENMEM_memory_map, );
-   if (rc) {
-   xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
-   BUG();
-   }
-   pvh_bootparams.e820_entries = memmap.nr_entries;
+   mem_map_via_hcall(_bootparams);
 
if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 833c441a20df..3a830caef8ee 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -1,10 +1,15 @@
 #include 
 
+#include 
+
 #include 
+#include 
 
 #include 
 #include 
 
+#include 
+
 /*
  * PVH variables.
  *
@@ -25,3 +30,18 @@ void __init xen_pvh_init(void)
pfn = __pa(hypercall_page);
wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
 }
+
+void __init mem_map_via_hcall(struct boot_params *boot_params_p)
+{
+   struct xen_memory_map memmap;
+   int rc;
+
+   memmap.nr_entries = ARRAY_SIZE(boot_params_p->e820_table);
+   set_xen_guest_handle(memmap.buffer, boot_params_p->e820_table);
+   rc = HYPERVISOR_memory_op(XENMEM_memory_map, );
+   if (rc) {
+   xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
+   BUG();
+   }
+   boot_params_p->e820_entries = memmap.nr_entries;
+}
-- 
2.16.1


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

[Xen-devel] [RFC PATCH v4 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Maran Wilson]

Sorry for the delay between this version and the last -- it was mostly
due to holidays and everyone being focused on security bug mitigation
issues. Here are the links to the previous email threads in case it is
helpful:

V3: https://lkml.org/lkml/2017/12/12/1230
V2: https://lkml.org/lkml/2017/12/7/1624
V1: https://lkml.org/lkml/2017/11/28/1280

Changes from v3:

 * Implemented Juergen's suggestion for refactoring and moving the PVH
   code so that CONFIG_XEN is no longer required for booting KVM guests
   via the PVH entry point.
   Functionally, nothing has changed from V3 really, but the patches
   look completely different now because of all the code movement and
   refactoring. Some of these patches can be combined, but I've left
   them very small in some cases to make the refactoring and code
   movement easier to review.
   My approach for refactoring has been to create a PVH entry layer that
   still has understanding and knowledge about Xen vs non-Xen guest types
   so that it can make run time decisions to handle either case, as
   opposed to going all the way and re-writing it to be a completely
   hypervisor agnostic and architecturally pure layer that is separate
   from guest type details. The latter seemed a bit overkill in this
   situation. And I've handled the complexity of having to support
   Qemu/KVM boot of kernels compiled with or without CONFIG_XEN via a
   pair of xen specific __weak routines that can be overridden in kernels
   that support Xen guests. Importantly, the __weak routines are for
   xen specific code only (not generic "guest type" specific code) so
   there is no clashing between xen version of the strong routine and,
   say, a KVM version of the same routine. But I'm sure there are many
   ways to skin this cat, so I'm open to alternate suggestions if there
   is a compelling reason for not using __weak in this situation.

Changes from v2:

 * All structures (including memory map table entries) are padded and
   aligned to an 8 byte boundary.

 * Removed the "packed" attributes and made changes to comments as
   suggested by Jan.

Changes from v1:

 * Adopted Paolo's suggestion for defining a v2 PVH ABI that includes the
   e820 map instead of using the second module entry to pass the table.

 * Cleaned things up a bit to reduce the number of xen vs non-xen special
   cases.

Maran Wilson (7):
  xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH
  xen/pvh: Move PVH entry code out of Xen specific tree
  xen/pvh: Create a new file for Xen specific PVH code
  xen/pvh: Move Xen specific PVH VM initialization out of common code
  xen/pvh: Move Xen code for getting mem map via hcall out of common file
  xen/pvh: Add memory map pointer to hvm_start_info struct
  KVM: x86: Allow Qemu/KVM to use PVH entry point

 MAINTAINERS|   1 +
 arch/x86/Kbuild|   3 +
 arch/x86/Kconfig   |   8 ++
 arch/x86/kernel/head_64.S  |   4 +-
 arch/x86/pvh-head.S| 161 +++
 arch/x86/pvh.c | 130 ++
 arch/x86/xen/Kconfig   |   3 +-
 arch/x86/xen/Makefile  |   1 -
 arch/x86/xen/enlighten_pvh.c   |  87 +++-
 arch/x86/xen/xen-pvh.S | 161 ---
 include/xen/interface/hvm/start_info.h |  50 ++-
 11 files changed, 374 insertions(+), 235 deletions(-)


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

[Xen-devel] [RFC PATCH v4 3/7] xen/pvh: Create a new file for Xen specific PVH code

[Maran Wilson]

We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.

The first step in that direction is to create a new file that will
eventually hold the Xen specific routines.

Signed-off-by: Maran Wilson 
---
 arch/x86/pvh.c   |  1 -
 arch/x86/xen/Makefile|  1 +
 arch/x86/xen/enlighten_pvh.c | 11 +++
 3 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/xen/enlighten_pvh.c

diff --git a/arch/x86/pvh.c b/arch/x86/pvh.c
index 436c4f003e17..b56cb5e7d6ac 100644
--- a/arch/x86/pvh.c
+++ b/arch/x86/pvh.c
@@ -19,7 +19,6 @@
  * xen_pvh and pvh_bootparams need to live in data segment since they
  * are used after startup_{32|64}, which clear .bss, are invoked.
  */
-bool xen_pvh __attribute__((section(".data"))) = 0;
 struct boot_params pvh_bootparams __attribute__((section(".data")));
 
 struct hvm_start_info pvh_start_info;
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 7e8145b33997..ef6481a83768 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -21,6 +21,7 @@ obj-y := enlighten.o multicalls.o mmu.o irq.o \
 obj-$(CONFIG_XEN_PVHVM)+= enlighten_hvm.o mmu_hvm.o 
suspend_hvm.o
 obj-$(CONFIG_XEN_PV)   += setup.o apic.o pmu.o suspend_pv.o \
p2m.o enlighten_pv.o mmu_pv.o
+obj-$(CONFIG_XEN_PVH)  += enlighten_pvh.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
new file mode 100644
index ..4b4e9cc78b8a
--- /dev/null
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -0,0 +1,11 @@
+#include 
+
+/*
+ * PVH variables.
+ *
+ * The variables xen_pvh and pvh_bootparams need to live in the data segment
+ * since they are used after startup_{32|64} is invoked, which will clear the
+ * .bss segment.
+ */
+bool xen_pvh __attribute__((section(".data"))) = 0;
+
-- 
2.16.1


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

[Xen-devel] [RFC PATCH v4 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

[Maran Wilson]

In order to pave the way for hypervisors other then Xen to use the PVH
entry point for VMs, we need to factor the PVH entry code into Xen specific
and hypervisor agnostic components. The first step in doing that, is to
create a new config option for PVH entry that can be enabled
independently from CONFIG_XEN.

Signed-off-by: Maran Wilson 
---
 arch/x86/Kconfig  | 8 
 arch/x86/kernel/head_64.S | 4 ++--
 arch/x86/xen/Kconfig  | 3 ++-
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eb7f43f23521..fa7cd0305125 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -791,6 +791,14 @@ config KVM_GUEST
  underlying device model, the host provides the guest with
  timing infrastructure such as time of day, and system time
 
+config PVH
+   bool "Support for running PVH guests"
+   depends on KVM_GUEST || XEN
+   def_bool n
+   ---help---
+ This option enables the PVH entry point for guest virtual machines
+ as specified in the x86/HVM direct boot ABI.
+
 config KVM_DEBUG_FS
bool "Enable debug information for KVM Guests in debugfs"
depends on KVM_GUEST && DEBUG_FS
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 0f545b3cf926..fc9f678c6413 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -41,7 +41,7 @@
 
 #define pud_index(x)   (((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
 PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
 #endif
@@ -387,7 +387,7 @@ NEXT_PAGE(early_dynamic_pgts)
 
.data
 
-#if defined(CONFIG_XEN_PV) || defined(CONFIG_XEN_PVH)
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_PVH)
 NEXT_PGD_PAGE(init_top_pgt)
.quad   level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
.orginit_top_pgt + PGD_PAGE_OFFSET*8, 0
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index f605825a04ab..021c8591c3c0 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -77,8 +77,9 @@ config XEN_DEBUG_FS
  Enabling this option may incur a significant performance overhead.
 
 config XEN_PVH
-   bool "Support for running as a PVH guest"
+   bool "Support for running as a Xen PVH guest"
depends on XEN && XEN_PVHVM && ACPI
# Pre-built page tables are not ready to handle 5-level paging.
depends on !X86_5LEVEL
+   select PVH
def_bool n
-- 
2.16.1


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

Re: [Xen-devel] [PATCH v2 7/7] x86/build: Use new .nop directive when available

[Andrew Cooper]

On 28/02/18 16:22, Jan Beulich wrote:
 On 26.02.18 at 12:35,  wrote:
>> Newer versions of binutils are capable of emitting an exact number bytes 
>> worth
>> of optimised nops.  Use this in preference to .skip when available.
>>
>> Signed-off-by: Andrew Cooper 
> In principle
> Reviewed-by: Jan Beulich 
> However, ...
>
>> RFC until support is actually committed to binutils mainline.
> ... upstream looks to have switched to .nops now, so the prereq
> to the R-b is that you consistently switch over.

Yes.  I need to pull, rebuild and retest.  Even if this patch gets
committed, it is still semi-RFC and up for changes until the next
binutils release.

That said, given the explicit probe, it is at least safe to have a stale
ABI in use, and we can change it later if needs be.

>
>> --- a/xen/arch/x86/Rules.mk
>> +++ b/xen/arch/x86/Rules.mk
>> @@ -28,6 +28,10 @@ $(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
>>  $(call as-option-add,CFLAGS,CC,\
>>  ".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIVE_TRUE)
>>  
>> +# Check to see whether the assmbler supports the .nop directive.
>> +$(call as-option-add,CFLAGS,CC,\
>> +".L1: .L2: .nop (.L2 - .L1)$$(comma)9",-DHAVE_AS_NOP_DIRECTIVE)
> Do you really need the (arbitrary) second argument here?

I want the check to match the form we actually use.

>
>> --- a/xen/include/asm-x86/alternative-asm.h
>> +++ b/xen/include/asm-x86/alternative-asm.h
>> @@ -1,6 +1,8 @@
>>  #ifndef _ASM_X86_ALTERNATIVE_ASM_H_
>>  #define _ASM_X86_ALTERNATIVE_ASM_H_
>>  
>> +#include 
>> +
>>  #ifdef __ASSEMBLY__
>>  
>>  /*
>> @@ -18,6 +20,14 @@
>>  .byte \pad_len
>>  .endm
>>  
>> +.macro mknops nr_bytes
>> +#ifdef HAVE_AS_NOP_DIRECTIVE
>> +.nop \nr_bytes, ASM_NOP_MAX
> And do you really need to specify ASM_NOP_MAX here? What's
> wrong with letting the assembler pick what it wants as the longest
> NOP?

I don't want a toolchain change to cause us to go beyond 11 byte nops,
because of the associated decode stall on almost all hardware.  Using
ASM_NOP_MAX seemed like the easiest way to keep the end result
consistent, irrespective of toolchain support.

~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  cb671efbf1fae302c0ee5ebd6e23564e319babc8
baseline version:
 xen  1c473c42199a8f4d70533c202e1c57ecd1dad35b

Last test of basis   120078  2018-02-27 21:15:58 Z0 days
Testing same since   120098  2018-02-28 16:01:46 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   1c473c4219..cb671efbf1  cb671efbf1fae302c0ee5ebd6e23564e319babc8 -> smoke

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

Re: [Xen-devel] [PATCH v2 5/7] x86/alt: Support for automatic padding calculations

[Andrew Cooper]

On 28/02/18 16:16, Jan Beulich wrote:
 On 26.02.18 at 12:35,  wrote:
>> --- a/xen/arch/x86/Rules.mk
>> +++ b/xen/arch/x86/Rules.mk
>> @@ -24,6 +24,10 @@ $(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
>>   -U__OBJECT_LABEL__ -DHAVE_GAS_QUOTED_SYM \
>>   '-D__OBJECT_LABEL__=$(subst 
>> $(BASEDIR)/,,$(CURDIR))/$$@')
>>  
>> +# GCC's idea of true is -1.  Clang's idea is 1
>> +$(call as-option-add,CFLAGS,CC,\
>> +".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIVE_TRUE)
> With GCC replaced by gas, as indicated already be Roger
> (also in alternative*.h then)
> Reviewed-by: Jan Beulich 
>
> However, I have a question to raise and a remark to make:
>
>>  .macro ALTERNATIVE oldinstr, newinstr, feature
>>  .L\@_orig_s:
>>  \oldinstr
>>  .L\@_orig_e:
>> +/*
>> + * Calculate the difference in size between the replacement and original
>> + * instructions, to derive how much padding to introduce.
>> + */
>> +.L\@_diff = repl_len(1) - orig_len
>> +
>> +.skip as_true(.L\@_diff > 0) * .L\@_diff, 0x90
> How certain are you that these forward references actually work on
> at least all half way recent gas versions? IOW I wonder whether it
> wouldn't be more safe to make these backward references (i.e.
> emitting the replacement code first).

This code is used unconditionally in Linux, so any binutils within their
minimum set work.

So overall, I'm going to err on the side of "yes" in answer to your
question.

>
>> @@ -45,18 +70,31 @@
>>  .L\@_orig_s:
>>  \oldinstr
>>  .L\@_orig_e:
>> +/*
>> + * Calculate the difference in size between the largest replacement and
>> + * the original instructions, to derive how much padding to introduce.
>> + */
>> +.L\@_diff = as_max(repl_len(1), repl_len(2)) - orig_len
>> +
>> + .skip as_true(.L\@_diff > 0) * .L\@_diff, 0x90
>> +.L\@_orig_p:
>>  
>>  .pushsection .altinstructions, "a", @progbits
>>  
>>  altinstruction_entry .L\@_orig_s, .L\@_repl_s1, \feature1, \
>> -orig_len, repl_len(1)
>> +orig_len, repl_len(1), pad_len
>>  altinstruction_entry .L\@_orig_s, .L\@_repl_s2, \feature2, \
>> -orig_len, repl_len(2)
>> +orig_len, repl_len(2), pad_len
>>  
>>  .section .discard, "a", @progbits
>> -/* Assembler-time check that \newinstr{1,2} aren't longer than 
>> \oldinstr. */
>> -.byte 0xff + repl_len(1) - orig_len
>> -.byte 0xff + repl_len(2) - orig_len
>> +/*
>> + * Assembler-time checks:
>> + *   - total_len <= 255
>> + *   - \newinstr* <= total_len
>> + */
>> +.byte total_len
>> +.byte 0xff + repl_len(1) - total_len
>> +.byte 0xff + repl_len(2) - total_len
> Use as_max() here and emit only a single byte? I don't think the
> diagnostic will be any less helpful, as iirc it doesn't point out the
> line inside the macro anyway, so the developer will be left guessing
> anyway which of the two alternatives it was. Otoh with the
> padding size now being calculated, I don't see much point in these
> checks anymore anyway.

The bytes are discarded, so the quantity doesn't matter.  I can use max,
and you are correct that the line reference only ends up pointing to the
.macro itself.

However, I would prefer to keep these.  They've spotted two bugs in the
binutils development effort of .nops, and I'd prefer to be safe than sorry.

~Andrew

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

Re: [Xen-devel] [ATTN SVM maintainers] Re: [PATCH V6] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Boris Ostrovsky]

On 02/28/2018 12:12 PM, George Dunlap wrote:
> On 02/28/2018 10:38 AM, Razvan Cojocaru wrote:
>> In hardware, when PCID support is enabled and the NOFLUSH bit is set
>> when writing a CR3 value, the hardware will clear that that bit and
>> change the CR3 without flushing the TLB. hvm_set_cr3(), however, was
>> ignoring this bit; the result was that post-vm_event checks detected
>> an invalid CR3 value and crashed the domain.
>>
>> Handle NOFLUSH in hvm_set_cr3() by:
>> 1. Clearing the bit
>> 2. Passing a "noflush" flag to lower-level cr3 setting functions to
>> indicate that a flush should not be performed.
>>
>> Also clear X86_CR3_NOFLUSH when reporting CR3 monitored CR3 writes.
>>
>> This allows introspection to be used on VMs whose operating system uses
>> the NOFLUSH bit.
>>
>> Signed-off-by: Razvan Cojocaru 
>> Reported-by: Bitweasil 
>> Suggested-by: Andrew Cooper 
>> Acked-by: Tamas K Lengyel 
>> Reviewed-by: Jan Beulich 
>> Reviewed-by: Kevin Tian 
>> Acked-by: George Dunlap 
> Boris / Suvaree, any opinions on the SVM changes?
>


Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH v2 4/5] tools: xenpm: continue to support {set, get}-vcpu-migration-delay

[Dario Faggioli]

Il 28 Feb 2018 17:03, "George Dunlap"  ha scritto:


> Again, I considered this, for that same reason. The reason why I
> decided for stdout is for maximizing the chances that anyone actually
> using this will see the warning (even if, e.g., they're redirecting
> stderr).

If they're redirecting stderr then they have explicitly decided to
ignore warnings and errors -- if they want to miss messages like this
they should be allowed to.  I would think it much more likely that
stdout would be redirected somewhere than stderr.


This last one is a good point. IAC, as I said, I had doubts myself already,
so I'm fine turning this into stderr.

Thanks and Regards,
Dario
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 0/2][XTF] FPU test improvements

[Andrew Cooper]

On 28/02/18 13:15, Jan Beulich wrote:
> 1: add FPU/SIMD register state test
> 2: extend FPU exception tests
>
> Signed-off-by: Jan Beulich 
> ---
> v4: Just re-basing, no other feedback was received.

In principle, this is all fine, but I cannot commit it until the test
revision logic is sorted.  Otherwise, it will will break OSSTests
bisection logic and either cause XTF updates to be rejected, or
staging-$X.$Y updates to be rejected.

~Andrew

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

Re: [Xen-devel] [PATCH 0/5] x86: improve PDX <-> PFN and alike translations

[Andrew Cooper]

On 28/02/18 13:51, Jan Beulich wrote:
> 1: remove page.h and processor.h inclusion from asm_defns.h
> 2: use PDEP for PTE flags insertion when available
> 3: use PDEP/PEXT for maddr/direct-map-offset conversion when available
> 4: use PDEP/PEXT for PFN/PDX conversion when available
> 5: use MOV for PFN/PDX conversion when possible
>
> Signed-off-by: Jan Beulich 
>

Ah - so this was the series you were on about which would have an
interesting time in combination with my nop autosizing.

Do you have performance numbers for these changes?  I can certainly see
the attraction of using BMI2 when available, but do the associated costs
on incompatible hardware worth it?  I'm thinking specifically of turning
all this inline bit manipulation into function calls?  (I genuinely
don't know the answer, and it might be entirely fine, but I'm concerned
about whether it may not be).

What generation of binutils do you expect this all to work with?

As for the pte flags, there is a much more simple approach which I've
considered investigating in the past, and I think warrants discussing here.

By switching 'unsigned int flags' to 'unsigned long flags', we avoid any
need for packing in the first place.  Being 64bit only these days, all
other PTE calculations are already 64bit operations, and the masks are
probably already available in GPRs at the use-sites.  I.e. I think the
use of 64bit flags will make better code than even this proposal.

~Andrew

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

[Xen-devel] [ATTN SVM maintainers] Re: [PATCH V6] x86/hvm: fix domain crash when CR3 has the noflush bit set

[George Dunlap]

On 02/28/2018 10:38 AM, Razvan Cojocaru wrote:
> In hardware, when PCID support is enabled and the NOFLUSH bit is set
> when writing a CR3 value, the hardware will clear that that bit and
> change the CR3 without flushing the TLB. hvm_set_cr3(), however, was
> ignoring this bit; the result was that post-vm_event checks detected
> an invalid CR3 value and crashed the domain.
> 
> Handle NOFLUSH in hvm_set_cr3() by:
> 1. Clearing the bit
> 2. Passing a "noflush" flag to lower-level cr3 setting functions to
> indicate that a flush should not be performed.
> 
> Also clear X86_CR3_NOFLUSH when reporting CR3 monitored CR3 writes.
> 
> This allows introspection to be used on VMs whose operating system uses
> the NOFLUSH bit.
> 
> Signed-off-by: Razvan Cojocaru 
> Reported-by: Bitweasil 
> Suggested-by: Andrew Cooper 
> Acked-by: Tamas K Lengyel 
> Reviewed-by: Jan Beulich 
> Reviewed-by: Kevin Tian 
> Acked-by: George Dunlap 

Boris / Suvaree, any opinions on the SVM changes?

 -George

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

Re: [Xen-devel] [PATCH 4/6] xen/sched: Remove {init, destroy}_domain() interfaces

[Andrew Cooper]

On 28/02/18 16:22, George Dunlap wrote:
> On 02/28/2018 02:14 PM, Andrew Cooper wrote:
>> These hooks have one single caller (sched_{init,destroy}_domain()
>> respectively) and are all identical (when implemented).
>>
>> Previous changes have ensured that only real domains reach these functions, 
>> so
>> ASSERT() that system domains are not seen. Call sched_{alloc,free}_domdata()
>> directly, and handle d->sched_priv directly.
>>
>> The net diffstat is:
>>   add/remove: 0/8 grow/shrink: 1/7 up/down: 7/-335 (-328)
>>   function old new   delta
>>   sched_destroy_domain 130 137  +7
>>   sched_init_domain138 137  -1
>>   rt_dom_destroy 6   -  -6
>>   null_dom_destroy   6   -  -6
>>   csched_dom_destroy 9   -  -9
>>   csched2_dom_destroy9   -  -9
>>   sched_rtds_def   264 248 -16
>>   sched_null_def   264 248 -16
>>   sched_credit_def 264 248 -16
>>   sched_credit2_def264 248 -16
>>   sched_arinc653_def   264 248 -16
>>   ops  264 248 -16
>>   rt_dom_init   52   - -52
>>   null_dom_init 52   - -52
>>   csched_dom_init   52   - -52
>>   csched2_dom_init  52   - -52
>>
>> Signed-off-by: Andrew Cooper 
> I kind of feel like there was a reason for the init / alloc difference;
> but as you say, at the moment all the schedulers are basically
> identical.  In the unlikely event that we need separate callbacks, we
> can introduce them at such time as we have a need for them.
>
> Reviewed-by: George Dunlap 

It looks like it was the cpupool work (c/s 78be3dbb, 2010) which split
alloc/free domdata() out of init/destroy domain() and made the latter
effectively redundant.

~Andrew

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

Re: [Xen-devel] [PATCH v2] fuzz/x86_emulate: fix bounds for input size

[Paul Semel]

Hey George,

On 02/27/2018 11:39 AM, George Dunlap wrote:

Thanks for the patch. Looking a bit more at the code over the weekend,
I figured out what that BUILD_BUG_ON() is for -- in afl_harness.c, we
statically allocate a buffer of size INPUT_SIZE to hold the fuzz data.
The BUILD_BUG_ON() is to make sure that this buffer is always big enough
to hold the minimum input size.  And increasing the size accepted by
LLVMFuzzerTestOneInput() won't have any effect for anybody using
afl-harness, as the size passed in will never be larger than INPUT_SIZE.



Thanks for replying me ! Actually, I understood what this BUILD_BUG_ON() was for 
and I totally agree with you 


Anyway, I am pretty sure that this check is not needed anymore for the new 
changes I made, as the condition is never reachable anymore.



Are you running afl-harness, or are you using fuzz-emul directly some
other way (e.g., through Google's fuzzing service)?



I am actually not using it, but I discovered this tool some time before, and I 
am now trying to port the idea on an other emulator project.. 
Anyway, I made much changes on my own version, and if it still does interest 
you, I can share those changes with you once I'm done with my thing !



 -George

--
Paul

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

[Xen-devel] Usage of DEBUG_DIR breaks OVMF build

[Olaf Hering]

The default DEBUG_DIR=/usr/lib/debug can not be used for rpm builds
because that directory is "owned" by rpm-packaging itself to store the
autogenerated ${pkg}-debuginfo.rpm data. Thats why I set it to /boot.
This worked fine until recently, only /boot/xen-syms was affected by
that change, and in fact only the "xen" build needed DEBUG_DIR as make
cmdline option.

Now tools/firmware/Makefile also uses DEBUG_DIR. To set DEBUG_DIR the
tools build must be done like "make DEBUG_DIR=/my/dir". But this breaks
build with --enable-ovmf because ovmf.git makes use of the very same
variable. For some reason it can not deal with a custom value, some
autogenerated file will not be found:

[  126s] make[8]: *** No rule to make target '/boot/AutoGen.h', needed by 
'/home/abuild/rpmbuild/BUILD/xen-4.11.20180228T150620.cb671efbf1/non-dbg/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin'.

I think the only option to support rpm packaging is to rename DEBUG_DIR to
XEN_DEBUG_DIR. Any objections to that?

Olaf


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

Re: [Xen-devel] [PATCH 5/6] x86/hvm: Handle x2apic MSRs the new guest_{rd, wr}msr() infrastructure

[Jan Beulich]

>>> On 26.02.18 at 18:35,  wrote:

"in" missing from subject?

> Dispatch from the guest_{rd,wr}msr() functions.  The read side should be safe
> outside of current context, but the write side is definitely not.  As the
> toolstack has plausible reason to access the APIC registers via this interface

... has no plausible reason ... ?

> @@ -983,49 +982,52 @@ int vlapic_apicv_write(struct vcpu *v, unsigned int 
> offset)
>  return X86EMUL_OKAY;
>  }
>  
> -int hvm_x2apic_msr_write(struct vcpu *v, unsigned int msr, uint64_t 
> msr_content)
> +int guest_wrmsr_x2apic(struct vcpu *v, uint32_t msr, uint64_t msr_content)
>  {
>  struct vlapic *vlapic = vcpu_vlapic(v);
>  uint32_t offset = (msr - MSR_IA32_APICBASE_MSR) << 4;
>  
> +/* The timer handling at least is unsafe outside of current context. */
> +ASSERT(v == current);
> +
>  if ( !vlapic_x2apic_mode(vlapic) )
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
>  
>  switch ( offset )
>  {
>  case APIC_TASKPRI:
>  if ( msr_content & ~APIC_TPRI_MASK )
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
>  break;
>  
>  case APIC_SPIV:
>  if ( msr_content & ~(APIC_VECTOR_MASK | APIC_SPIV_APIC_ENABLED |
>   (VLAPIC_VERSION & APIC_LVR_DIRECTED_EOI
>? APIC_SPIV_DIRECTED_EOI : 0)) )
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
>  break;
>  
>  case APIC_LVTT:
>  if ( msr_content & ~(LVT_MASK | APIC_TIMER_MODE_MASK) )
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
>  break;
>  
>  case APIC_LVTTHMR:
>  case APIC_LVTPC:
>  case APIC_CMCI:
>  if ( msr_content & ~(LVT_MASK | APIC_MODE_MASK) )
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
>  break;
>  
>  case APIC_LVT0:
>  case APIC_LVT1:
>  if ( msr_content & ~LINT_MASK )
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
>  break;
>  
>  case APIC_LVTERR:
>  if ( msr_content & ~LVT_MASK )
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
>  break;
>  
>  case APIC_TMICT:
> @@ -1033,20 +1035,20 @@ int hvm_x2apic_msr_write(struct vcpu *v, unsigned int 
> msr, uint64_t msr_content)
>  
>  case APIC_TDCR:
>  if ( msr_content & ~APIC_TDR_DIV_1 )
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
>  break;
>  
>  case APIC_ICR:
>  if ( (uint32_t)msr_content & ~(APIC_VECTOR_MASK | APIC_MODE_MASK |
> APIC_DEST_MASK | APIC_INT_ASSERT |
> APIC_INT_LEVELTRIG | APIC_SHORT_MASK) 
> )
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
>  vlapic_set_reg(vlapic, APIC_ICR2, msr_content >> 32);
>  break;
>  
>  case APIC_SELF_IPI:
>  if ( msr_content & ~APIC_VECTOR_MASK )
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
>  offset = APIC_ICR;
>  msr_content = APIC_DEST_SELF | (msr_content & APIC_VECTOR_MASK);
>  break;
> @@ -1054,13 +1056,18 @@ int hvm_x2apic_msr_write(struct vcpu *v, unsigned int 
> msr, uint64_t msr_content)
>  case APIC_EOI:
>  case APIC_ESR:
>  if ( msr_content )
> +{
>  default:
> -return X86EMUL_UNHANDLEABLE;
> +goto gp_fault;
> +}
>  }
>  
>  vlapic_reg_write(v, offset, msr_content);
>  
>  return X86EMUL_OKAY;
> +
> + gp_fault:
> +return X86EMUL_EXCEPTION;
>  }

There's really no good reason to use goto all over the place here
when all that's at the label is a single return statement. I was
actually hoping to do conversions the other way around in some
other code.

> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -139,6 +139,7 @@ int init_vcpu_msr_policy(struct vcpu *v)
>  
>  int guest_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
>  {
> +const struct vcpu *curr = current;
>  const struct domain *d = v->domain;
>  const struct cpuid_policy *cp = d->arch.cpuid;
>  const struct msr_domain_policy *dp = d->arch.msr;
> @@ -175,6 +176,13 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, 
> uint64_t *val)
> _MSR_MISC_FEATURES_CPUID_FAULTING;
>  break;
>  
> +case MSR_IA32_APICBASE_MSR ... MSR_IA32_APICBASE_MSR + 0x3ff:
> +if ( !is_hvm_domain(d) || v != curr )
> +goto gp_fault;

"v != curr" is quite certainly not a reason to raise #GP.

Jan

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

Re: [Xen-devel] [PATCH 4/6] x86/hvm: Constify the read side of vlapic handling

[Jan Beulich]

>>> On 26.02.18 at 18:35,  wrote:
> This is in preparation to make hvm_x2apic_msr_read() take a const vcpu
> pointer.  One modification is to alter vlapic_get_tmcct() to not use 
> current.
> 
> This in turn needs an alteration to hvm_get_guest_time_fixed(), which is safe
> because the only mutable action it makes is to take the domain plt lock.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 3/6] x86: Handle the Xen MSRs via the new guest_{rd, wr}msr() infrastructure

[Jan Beulich]

>>> On 26.02.18 at 18:35,  wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -183,6 +183,10 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, 
> uint64_t *val)
>  }
>  
>  /* Fallthrough. */
> +case 0x4200 ... 0x42ff:

These again want to have #define-s added.

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -776,29 +776,26 @@ static void do_trap(struct cpu_user_regs *regs)
>trapnr, trapstr(trapnr), regs->error_code);
>  }
>  
> -/* Returns 0 if not handled, and non-0 for success. */
> -int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val)
> +int guest_rdmsr_xen(const struct vcpu *v, uint32_t idx, uint64_t *val)
>  {
> -struct domain *d = current->domain;
> +const struct domain *d = v->domain;
>  /* Optionally shift out of the way of Viridian architectural MSRs. */
>  uint32_t base = is_viridian_domain(d) ? 0x4200 : 0x4000;
>  
>  switch ( idx - base )
>  {
>  case 0: /* Write hypercall page MSR.  Read as zero. */
> -{
>  *val = 0;
> -return 1;
> -}
> -}
> +return X86EMUL_OKAY;
>  
> -return 0;
> +default:
> +return X86EMUL_EXCEPTION;
> +}
>  }

Could I talk you into adjusting the code to have a "return" at the
end of the function, e.g. by dropping the default case? Also on
the write path then?

With at least the #define-s added,
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 2/6] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

[Jan Beulich]

>>> On 26.02.18 at 18:35,  wrote:
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -554,13 +554,11 @@ static void update_reference_tsc(struct domain *d, 
> bool_t initialize)
>  put_page_and_type(page);
>  }
>  
> -int wrmsr_viridian_regs(uint32_t idx, uint64_t val)
> +int guest_wrmsr_viridian(struct vcpu *v, uint32_t idx, uint64_t val)

unsigned int would do instead of uint32_t (same on the read side).

> @@ -173,11 +175,26 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,  
> uint64_t *val)
> _MSR_MISC_FEATURES_CPUID_FAULTING;
>  break;
>  
> +case 0x4000 ... 0x41ff:

As was already suggested, these want to gain #define-s.

Reviewed-by: Jan Beulich 
with at least the latter taken care of.

Jan


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

[Xen-devel] [xen-4.6-testing test] 120062: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt broken  in 120035
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
119227

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt 4 host-install(4) broken in 120035 pass in 120062
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 119983 pass 
in 120062
 test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail 
in 120035 pass in 120062
 test-xtf-amd64-amd64-3   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 119983
 test-xtf-amd64-amd64-1   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 120035
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-localmigrate 
fail pass in 120035
 test-armhf-armhf-xl-xsm  16 guest-start/debian.repeat  fail pass in 120035

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 119983 like 
119187
 test-armhf-armhf-xl-rtds 12 guest-start fail in 119983 like 119227
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 119187
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119227
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119227
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119227
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119227
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119227
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119227
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119227
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119227
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 119227
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   76 xtf/test-pv32pae-xsa-194 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-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 

Re: [Xen-devel] [PATCH 6/6] xen/domain: Use IS_ERR_OR_NULL() when checking the return value of domain_create()

[George Dunlap]

On Wed, Feb 28, 2018 at 2:14 PM, Andrew Cooper
 wrote:
> This means that hitting the fail path with with err set to 0 isn't considered
> as success by the callers.  All current codepaths look fine.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> ---
>  xen/arch/arm/mm.c | 6 +++---
>  xen/arch/arm/setup.c  | 2 +-
>  xen/arch/x86/mm.c | 6 +++---
>  xen/arch/x86/setup.c  | 2 +-
>  xen/common/domctl.c   | 2 +-
>  xen/common/schedule.c | 2 +-
>  6 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 3c328e2..16a08cf 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -521,7 +521,7 @@ void __init arch_init_memory(void)
>   * their domain field set to dom_xen.
>   */
>  dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0, NULL);
> -BUG_ON(IS_ERR(dom_xen));
> +BUG_ON(IS_ERR_OR_NULL(dom_xen));
>
>  /*
>   * Initialise our DOMID_IO domain.
> @@ -529,14 +529,14 @@ void __init arch_init_memory(void)
>   * array. Mappings occur at the priv of the caller.
>   */
>  dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0, NULL);
> -BUG_ON(IS_ERR(dom_io));
> +BUG_ON(IS_ERR_OR_NULL(dom_io));
>
>  /*
>   * Initialise our COW domain.
>   * This domain owns sharable pages.
>   */
>  dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0, NULL);
> -BUG_ON(IS_ERR(dom_cow));
> +BUG_ON(IS_ERR_OR_NULL(dom_cow));
>  }
>
>  static inline lpae_t pte_of_xenaddr(vaddr_t va)
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 032a6a8..6646074 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -857,7 +857,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>  config.nr_spis = gic_number_lines() - 32;
>
>  dom0 = domain_create(0, 0, 0, );
> -if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
> +if ( IS_ERR_OR_NULL(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
>  panic("Error creating domain 0");
>
>  dom0->is_privileged = 1;
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index e1f089b..c44b781 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -272,7 +272,7 @@ void __init arch_init_memory(void)
>   * (but be [partly] controlled by Dom0 nevertheless).
>   */
>  dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0, NULL);
> -BUG_ON(IS_ERR(dom_xen));
> +BUG_ON(IS_ERR_OR_NULL(dom_xen));
>  INIT_LIST_HEAD(_xen->arch.pdev_list);
>
>  /*
> @@ -281,14 +281,14 @@ void __init arch_init_memory(void)
>   * array. Mappings occur at the priv of the caller.
>   */
>  dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0, NULL);
> -BUG_ON(IS_ERR(dom_io));
> +BUG_ON(IS_ERR_OR_NULL(dom_io));
>
>  /*
>   * Initialise our COW domain.
>   * This domain owns sharable pages.
>   */
>  dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0, NULL);
> -BUG_ON(IS_ERR(dom_cow));
> +BUG_ON(IS_ERR_OR_NULL(dom_cow));
>
>  /*
>   * First 1MB of RAM is historically marked as I/O.  If we booted PVH,
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index ac530ec..92428da 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1640,7 +1640,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>
>  /* Create initial domain 0. */
>  dom0 = domain_create(get_initial_domain_id(), domcr_flags, 0, );
> -if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
> +if ( IS_ERR_OR_NULL(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
>  panic("Error creating domain 0");
>
>  if ( !pv_shim )
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 50f7422..18dcb2d 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -547,7 +547,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>
>  d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref,
>>u.createdomain.config);
> -if ( IS_ERR(d) )
> +if ( IS_ERR_OR_NULL(d) )
>  {
>  ret = PTR_ERR(d);
>  d = NULL;

This will fail to crash if domain_create() returns NULL, but it will
still return 0 from the hypercall (since AFAICT PTR_ERR(NULL) will be
just '0').  Is that what we want?

Given that anywhere else this returns NULL will cause a BUG() or a
panic, I almost feel like a BUG_ON(d == NULL) would be more
appropriate.

Everything else looks good to me.

 -George

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

Re: [Xen-devel] [PATCH 4/6] xen/sched: Remove {init, destroy}_domain() interfaces

[Meng Xu]

On Wed, Feb 28, 2018 at 9:14 AM, Andrew Cooper
 wrote:
> These hooks have one single caller (sched_{init,destroy}_domain()
> respectively) and are all identical (when implemented).
>
> Previous changes have ensured that only real domains reach these functions, so
> ASSERT() that system domains are not seen. Call sched_{alloc,free}_domdata()
> directly, and handle d->sched_priv directly.
>
> The net diffstat is:
>   add/remove: 0/8 grow/shrink: 1/7 up/down: 7/-335 (-328)
>   function old new   delta
>   sched_destroy_domain 130 137  +7
>   sched_init_domain138 137  -1
>   rt_dom_destroy 6   -  -6
>   null_dom_destroy   6   -  -6
>   csched_dom_destroy 9   -  -9
>   csched2_dom_destroy9   -  -9
>   sched_rtds_def   264 248 -16
>   sched_null_def   264 248 -16
>   sched_credit_def 264 248 -16
>   sched_credit2_def264 248 -16
>   sched_arinc653_def   264 248 -16
>   ops  264 248 -16
>   rt_dom_init   52   - -52
>   null_dom_init 52   - -52
>   csched_dom_init   52   - -52
>   csched2_dom_init  52   - -52
>
> Signed-off-by: Andrew Cooper 
> ---


Acked-by: Meng Xu 


Thanks,

Meng

---
Meng Xu
Ph.D. Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH 3/6] xen/sched: Improvements to the {alloc, free}_domdata() interfaces

[Meng Xu]

On Wed, Feb 28, 2018 at 9:14 AM, Andrew Cooper
 wrote:
>
> The main purpose of this change is for the subsequent cleanup it enables, but
> it stands on its own merits.
>
> In principle, these hooks are optional, but the SCHED_OP() default aliases a
> memory allocation failure, which causes arinc653 to play the dangerous game of
> passing its priv pointer back, and remembering not to actually free it.
>
> Redefine alloc_domdata to use ERR_PTR() for errors, NULL for nothing, and
> non-NULL for a real allocation, which allows the hook to become properly
> optional.  Redefine free_domdata to be idempotent.
>
> For arinc653, this means the dummy hooks can be dropped entirely.  For the
> other schedulers, this means returning ERR_PTR(-ENOMEM) instead of NULL for
> memory allocation failures, and modifying the free hooks to cope with a NULL
> pointer.  While making the alterations, drop some spurious casts to void *.
>
> Introduce and use proper wrappers for sched_{alloc,free}_domdata().  These are
> strictly better than SCHED_OP(), as the source code is visible to
> grep/cscope/tags, the generated code is better, and there can be proper
> per-hook defaults and checks.
>
> Callers of the alloc hooks are switched to using IS_ERR(), rather than
> checking for NULL.
>
> Signed-off-by: Andrew Cooper 
> ---


Acked-by: Meng Xu 


Thanks,


Meng

---
Meng Xu
Ph.D. Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v3] build: remove shim related targets

[Jan Beulich]

>>> On 28.02.18 at 16:47,  wrote:
> On Wed, Feb 28, 2018 at 08:30:12AM -0700, Jan Beulich wrote:
>> >>> On 28.02.18 at 16:02,  wrote:
>> > But that raises the question, if prefix=/usr/local this will become:
>> > 
>> > /usr/local/lib/usr/local/lib/xen/...
>> 
>> /usr/local/lib/debug/usr/local/lib/xen/...
>> 
>> > Should this instead be:
>> > 
>> > /usr/local/lib/usr/lib/xen/...
>> 
>> /usr/local/lib/debug/usr/lib/xen/...
> 
> Right.
> 
>> > I don't think so, but want to be sure.
>> 
>> Neither, I would say (without knowing whether there are any
>> conventions for ${prefix}/lib/debug) - what has the full path got to
>> do in the middle in there? The more when it's /home/... or
>> something even more obscure?
> 
> I would expect debuggers like gdb to search /usr/lib/debug and
> /usr/local/lib/debug in order to find the debug symbols of a binary,
> so that what's inside the debug/ directory needs to have the same path
> as where the binary resides, hence I think it should be:
> 
> /usr/local/lib/debug/usr/local/lib/xen/

Makes sense for stuff under /usr and /usr/local, but not really
for stuff under e.g. /home or some network mount.

Jan


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

Re: [Xen-devel] kexec and xen/arch/x86/boot/head.S trampoline

[Trammell Hudson]

On Wed, Feb 28, 2018 at 03:07:41PM +, Andrew Cooper wrote:
> On 28/02/18 14:08, Trammell Hudson wrote:
> > kexec allocates a 1 page segment at 0x0 and memsets most of it to zero,
> > wiping out coreboot's EBDA structure, which xen's head.S consulted to
> > allocate the trampoline.  Xen's code looks like this:
> 
> This sounds like a bug as and of itself.  I presume this is to do with
> IVT handling?

Maybe?  That's the right address and it only populates 0x78 bytes
(in qemu) with contents, which would be about right for the interrupt
table.  I haven't tracked down where that data comes from.

> [...]
> > Are there reasons to prefer EBDA over mbi->mem_lower?
> 
> I think the expectation was that the EBDA would be more reliable than
> mbi->mem_lower.  However, we recently hit a similar bug with PVH
> handling (c/s a232346b1fe), and these days, the EBDA is quite likely not
> to be present.
> 
> I think we probably can use mbi->mem_lower (if available and sane) by
> default.  If the bootloader has messed that up, all bets are off
> anyway.  Irrespective, we should fix the EBDA lower sanity check.

What do you think of something like this instead?

/*
 * If the multiboot structure memory limits are available,
 * use it for the trampoline.
 */
testb   $MBI_MEMLIMITS,(%ebx)
jz  1f  /* not available? BDA value will be fine */
mov MB_mem_lower(%ebx),%ecx
cmp $0x100,%ecx /* is the multiboot value too small? */
jae 2f

1:
/* MBI not available, set up trampoline segment 64k below EBDA */
movzwl  0x40e,%ecx  /* EBDA segment */
cmp $0xa000,%ecx/* sanity check (high) */
jae 0f
cmp $0x4000,%ecx/* sanity check (low) */
jae 2f
0:
movzwl  0x413,%ecx  /* use base memory size on failure */
cmp $0xa000,%ecx/* sanity check (high) */
jae bad_ebda
cmp $0x4000,%ecx/* sanity check (low) */
jb  bad_ebda

2:  /* Reserve 64kb for the trampoline */
shl $10-4,%ecx  /* convert to bytes */
sub $0x1000,%ecx

-- 
Trammell

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

Re: [Xen-devel] [PATCH RFC 3/3] xtf: add minimal HPET functionality test

[Jan Beulich]

>>> On 28.02.18 at 16:37,  wrote:
> On Fri, Feb 23, 2018 at 07:07:18PM +, Wei Liu wrote:
>> On Fri, Feb 23, 2018 at 01:27:43PM +, Roger Pau Monne wrote:
>> > --- a/arch/x86/include/arch/lib.h
>> > +++ b/arch/x86/include/arch/lib.h
>> > @@ -392,6 +392,20 @@ static inline void write_xcr0(uint64_t xcr0)
>> >  xsetbv(0, xcr0);
>> >  }
>> >  
>> > +static inline uint64_t rdtsc(void)
>> > +{
>> > +uint32_t low, high;
>> > +
>> > +asm volatile ("rdtsc" : "=a" (low), "=d" (high));
>> > +
>> 
>> You probably need to add lfence or mfence. See rdtsc_ordered in Xen.
> 
> Oh, OK that's news to me. I guess just using a lfence before it
> should be fine.

Except that on AMD, without LFENCE made dispatch serializing,
you'd need MFENCE.

Jan


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

Re: [Xen-devel] [PATCH 5/6] xen/domain: Call sched_destroy_domain() in the domain_create() error path

[George Dunlap]

On 02/28/2018 02:14 PM, Andrew Cooper wrote:
> If domain_create() fails, complete_domain_destroy() doesn't get called,
> meaning that sched_destroy_domain() is missed.  In practice, this can only
> fail because of exceptional late_hwdom_init() issues at the moment.
> 
> Make sched_destroy_domain() idempotent, and call it in the fail path.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH 4/6] xen/sched: Remove {init, destroy}_domain() interfaces

[George Dunlap]

On 02/28/2018 02:14 PM, Andrew Cooper wrote:
> These hooks have one single caller (sched_{init,destroy}_domain()
> respectively) and are all identical (when implemented).
> 
> Previous changes have ensured that only real domains reach these functions, so
> ASSERT() that system domains are not seen. Call sched_{alloc,free}_domdata()
> directly, and handle d->sched_priv directly.
> 
> The net diffstat is:
>   add/remove: 0/8 grow/shrink: 1/7 up/down: 7/-335 (-328)
>   function old new   delta
>   sched_destroy_domain 130 137  +7
>   sched_init_domain138 137  -1
>   rt_dom_destroy 6   -  -6
>   null_dom_destroy   6   -  -6
>   csched_dom_destroy 9   -  -9
>   csched2_dom_destroy9   -  -9
>   sched_rtds_def   264 248 -16
>   sched_null_def   264 248 -16
>   sched_credit_def 264 248 -16
>   sched_credit2_def264 248 -16
>   sched_arinc653_def   264 248 -16
>   ops  264 248 -16
>   rt_dom_init   52   - -52
>   null_dom_init 52   - -52
>   csched_dom_init   52   - -52
>   csched2_dom_init  52   - -52
> 
> Signed-off-by: Andrew Cooper 

I kind of feel like there was a reason for the init / alloc difference;
but as you say, at the moment all the schedulers are basically
identical.  In the unlikely event that we need separate callbacks, we
can introduce them at such time as we have a need for them.

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH v2 7/7] x86/build: Use new .nop directive when available

[Jan Beulich]

>>> On 26.02.18 at 12:35,  wrote:
> Newer versions of binutils are capable of emitting an exact number bytes worth
> of optimised nops.  Use this in preference to .skip when available.
> 
> Signed-off-by: Andrew Cooper 

In principle
Reviewed-by: Jan Beulich 
However, ...

> RFC until support is actually committed to binutils mainline.

... upstream looks to have switched to .nops now, so the prereq
to the R-b is that you consistently switch over.

> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -28,6 +28,10 @@ $(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
>  $(call as-option-add,CFLAGS,CC,\
>  ".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIVE_TRUE)
>  
> +# Check to see whether the assmbler supports the .nop directive.
> +$(call as-option-add,CFLAGS,CC,\
> +".L1: .L2: .nop (.L2 - .L1)$$(comma)9",-DHAVE_AS_NOP_DIRECTIVE)

Do you really need the (arbitrary) second argument here?

> --- a/xen/include/asm-x86/alternative-asm.h
> +++ b/xen/include/asm-x86/alternative-asm.h
> @@ -1,6 +1,8 @@
>  #ifndef _ASM_X86_ALTERNATIVE_ASM_H_
>  #define _ASM_X86_ALTERNATIVE_ASM_H_
>  
> +#include 
> +
>  #ifdef __ASSEMBLY__
>  
>  /*
> @@ -18,6 +20,14 @@
>  .byte \pad_len
>  .endm
>  
> +.macro mknops nr_bytes
> +#ifdef HAVE_AS_NOP_DIRECTIVE
> +.nop \nr_bytes, ASM_NOP_MAX

And do you really need to specify ASM_NOP_MAX here? What's
wrong with letting the assembler pick what it wants as the longest
NOP?

Jan


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

Re: [Xen-devel] [PATCH v2 5/7] x86/alt: Support for automatic padding calculations

[Jan Beulich]

>>> On 26.02.18 at 12:35,  wrote:
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -24,6 +24,10 @@ $(call as-option-add,CFLAGS,CC,".equ \"x\"$$(comma)1", \
>   -U__OBJECT_LABEL__ -DHAVE_GAS_QUOTED_SYM \
>   '-D__OBJECT_LABEL__=$(subst 
> $(BASEDIR)/,,$(CURDIR))/$$@')
>  
> +# GCC's idea of true is -1.  Clang's idea is 1
> +$(call as-option-add,CFLAGS,CC,\
> +".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIVE_TRUE)

With GCC replaced by gas, as indicated already be Roger
(also in alternative*.h then)
Reviewed-by: Jan Beulich 

However, I have a question to raise and a remark to make:

>  .macro ALTERNATIVE oldinstr, newinstr, feature
>  .L\@_orig_s:
>  \oldinstr
>  .L\@_orig_e:
> +/*
> + * Calculate the difference in size between the replacement and original
> + * instructions, to derive how much padding to introduce.
> + */
> +.L\@_diff = repl_len(1) - orig_len
> +
> +.skip as_true(.L\@_diff > 0) * .L\@_diff, 0x90

How certain are you that these forward references actually work on
at least all half way recent gas versions? IOW I wonder whether it
wouldn't be more safe to make these backward references (i.e.
emitting the replacement code first).

> @@ -45,18 +70,31 @@
>  .L\@_orig_s:
>  \oldinstr
>  .L\@_orig_e:
> +/*
> + * Calculate the difference in size between the largest replacement and
> + * the original instructions, to derive how much padding to introduce.
> + */
> +.L\@_diff = as_max(repl_len(1), repl_len(2)) - orig_len
> +
> + .skip as_true(.L\@_diff > 0) * .L\@_diff, 0x90
> +.L\@_orig_p:
>  
>  .pushsection .altinstructions, "a", @progbits
>  
>  altinstruction_entry .L\@_orig_s, .L\@_repl_s1, \feature1, \
> -orig_len, repl_len(1)
> +orig_len, repl_len(1), pad_len
>  altinstruction_entry .L\@_orig_s, .L\@_repl_s2, \feature2, \
> -orig_len, repl_len(2)
> +orig_len, repl_len(2), pad_len
>  
>  .section .discard, "a", @progbits
> -/* Assembler-time check that \newinstr{1,2} aren't longer than 
> \oldinstr. */
> -.byte 0xff + repl_len(1) - orig_len
> -.byte 0xff + repl_len(2) - orig_len
> +/*
> + * Assembler-time checks:
> + *   - total_len <= 255
> + *   - \newinstr* <= total_len
> + */
> +.byte total_len
> +.byte 0xff + repl_len(1) - total_len
> +.byte 0xff + repl_len(2) - total_len

Use as_max() here and emit only a single byte? I don't think the
diagnostic will be any less helpful, as iirc it doesn't point out the
line inside the macro anyway, so the developer will be left guessing
anyway which of the two alternatives it was. Otoh with the
padding size now being calculated, I don't see much point in these
checks anymore anyway.

Jan


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

Re: [Xen-devel] [PATCH v3] build: remove shim related targets

[Roger Pau Monné]

On Wed, Feb 28, 2018 at 08:30:12AM -0700, Jan Beulich wrote:
> >>> On 28.02.18 at 16:02,  wrote:
> > But that raises the question, if prefix=/usr/local this will become:
> > 
> > /usr/local/lib/usr/local/lib/xen/...
> 
> /usr/local/lib/debug/usr/local/lib/xen/...
> 
> > Should this instead be:
> > 
> > /usr/local/lib/usr/lib/xen/...
> 
> /usr/local/lib/debug/usr/lib/xen/...

Right.

> > I don't think so, but want to be sure.
> 
> Neither, I would say (without knowing whether there are any
> conventions for ${prefix}/lib/debug) - what has the full path got to
> do in the middle in there? The more when it's /home/... or
> something even more obscure?

I would expect debuggers like gdb to search /usr/lib/debug and
/usr/local/lib/debug in order to find the debug symbols of a binary,
so that what's inside the debug/ directory needs to have the same path
as where the binary resides, hence I think it should be:

/usr/local/lib/debug/usr/local/lib/xen/

Roger.

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

[Xen-devel] [PATCH v5 1/5] x86/msr: add VMX MSRs definitions and populate Raw domain policy

[Sergey Dyasli]

New definitions provide a convenient way of accessing contents of
VMX MSRs. They are separated into 5 logical blocks based on the
availability conditions of MSRs in the each block:

1. vmx: [VMX_BASIC, VMX_VMCS_ENUM]
2. VMX_PROCBASED_CTLS2
3. VMX_EPT_VPID_CAP
4. vmx_true_ctls: [VMX_TRUE_PINBASED_CTLS, VMX_TRUE_ENTRY_CTLS]
5. VMX_VMFUNC

Every bit value is accessible by its name and bit names match existing
Xen's definitions as close as possible. There is a "raw" 64-bit field
for each MSR as well as "raw" arrays for vmx and vmx_true_ctls blocks.

Add calculate_raw_vmx_policy() which fills Raw policy with H/W values
of VMX MSRs. Host policy will contain a copy of these values (for now).

Signed-off-by: Sergey Dyasli 
---
v4 --> v5:
- Clarified the reason for splitting MSRs into 5 blocks
- Added raw field into cr0/4_bits
- Moved cr0/4_bits definitions into asm-x86/x86-defns.h
- Added msr availability helpers
---
 xen/arch/x86/msr.c  | 118 ++
 xen/include/asm-x86/msr.h   | 330 
 xen/include/asm-x86/x86-defns.h |  54 +++
 3 files changed, 502 insertions(+)

diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 8ae3b4e616..43607b5107 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -34,10 +34,65 @@ struct msr_domain_policy __read_mostly 
raw_msr_domain_policy,
 struct msr_vcpu_policy __read_mostly hvm_max_msr_vcpu_policy,
__read_mostly  pv_max_msr_vcpu_policy;
 
+static bool vmx_procbased_ctls2_available(const struct msr_domain_policy *dp)
+{
+return dp->vmx.procbased_ctls.allowed_1.activate_secondary_controls;
+}
+
+static bool vmx_ept_vpid_cap_available(const struct msr_domain_policy *dp)
+{
+return dp->vmx_procbased_ctls2.allowed_1.enable_ept ||
+   dp->vmx_procbased_ctls2.allowed_1.enable_vpid;
+}
+
+static bool vmx_true_ctls_available(const struct msr_domain_policy *dp)
+{
+return dp->vmx.basic.default1_zero;
+}
+
+static bool vmx_vmfunc_available(const struct msr_domain_policy *dp)
+{
+return dp->vmx_procbased_ctls2.allowed_1.enable_vm_functions;
+}
+
+static void __init calculate_raw_vmx_policy(struct msr_domain_policy *dp)
+{
+unsigned int i, start_msr, end_msr;
+
+if ( !cpu_has_vmx )
+return;
+
+start_msr = MSR_IA32_VMX_BASIC;
+end_msr = MSR_IA32_VMX_VMCS_ENUM;
+for ( i = start_msr; i <= end_msr; i++ )
+rdmsrl(i, dp->vmx.raw[i - start_msr]);
+
+if ( vmx_procbased_ctls2_available(dp) )
+rdmsrl(MSR_IA32_VMX_PROCBASED_CTLS2, dp->vmx_procbased_ctls2.raw);
+
+if ( vmx_ept_vpid_cap_available(dp) )
+rdmsrl(MSR_IA32_VMX_EPT_VPID_CAP, dp->vmx_ept_vpid_cap.raw);
+
+if ( vmx_true_ctls_available(dp) )
+{
+start_msr = MSR_IA32_VMX_TRUE_PINBASED_CTLS;
+end_msr = MSR_IA32_VMX_TRUE_ENTRY_CTLS;
+for ( i = start_msr; i <= end_msr; i++ )
+rdmsrl(i, dp->vmx_true_ctls.raw[i - start_msr]);
+}
+
+if ( vmx_vmfunc_available(dp) )
+rdmsrl(MSR_IA32_VMX_VMFUNC, dp->vmx_vmfunc.raw);
+}
+
 static void __init calculate_raw_policy(void)
 {
+struct msr_domain_policy *dp = _msr_domain_policy;
+
 /* 0x00ce  MSR_INTEL_PLATFORM_INFO */
 /* Was already added by probe_cpuid_faulting() */
+
+calculate_raw_vmx_policy(dp);
 }
 
 static void __init calculate_host_policy(void)
@@ -260,6 +315,69 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 return X86EMUL_EXCEPTION;
 }
 
+static void __init __maybe_unused build_assertions(void)
+{
+struct msr_domain_policy dp;
+
+BUILD_BUG_ON(sizeof(dp.vmx.basic) !=
+ sizeof(dp.vmx.basic.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.pinbased_ctls) !=
+ sizeof(dp.vmx.pinbased_ctls.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.procbased_ctls) !=
+ sizeof(dp.vmx.procbased_ctls.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.exit_ctls) !=
+ sizeof(dp.vmx.exit_ctls.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.entry_ctls) !=
+ sizeof(dp.vmx.entry_ctls.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.misc) !=
+ sizeof(dp.vmx.misc.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.cr0_fixed0) !=
+ sizeof(dp.vmx.cr0_fixed0.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.cr0_fixed1) !=
+ sizeof(dp.vmx.cr0_fixed1.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.cr4_fixed0) !=
+ sizeof(dp.vmx.cr4_fixed0.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.cr4_fixed1) !=
+ sizeof(dp.vmx.cr4_fixed1.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.vmcs_enum) !=
+ sizeof(dp.vmx.vmcs_enum.raw));
+BUILD_BUG_ON(sizeof(dp.vmx.raw) !=
+ sizeof(dp.vmx.basic) +
+ sizeof(dp.vmx.pinbased_ctls) +
+ sizeof(dp.vmx.procbased_ctls) +
+ sizeof(dp.vmx.exit_ctls) +
+ sizeof(dp.vmx.entry_ctls) +
+   

[Xen-devel] [PATCH v5 5/5] x86/msr: handle VMX MSRs with guest_rd/wrmsr()

[Sergey Dyasli]

Now that each domain has a correct view of VMX MSRs in it's per-domain
MSR policy, it's possible to handle guest's RD/WRMSR with the new
handlers. Do it and remove the old nvmx_msr_read_intercept() and
associated bits.

There is no functional change to what a guest sees in its VMX MSRs.

Signed-off-by: Sergey Dyasli 
---
v4 --> v5:
- New msr availability helpers are used
---
 xen/arch/x86/hvm/vmx/vmx.c |   6 --
 xen/arch/x86/hvm/vmx/vvmx.c| 178 -
 xen/arch/x86/msr.c |  35 
 xen/include/asm-x86/hvm/vmx/vvmx.h |   2 -
 4 files changed, 35 insertions(+), 186 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 4856ad7c24..e850ef913f 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2934,10 +2934,6 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 if ( nestedhvm_enabled(curr->domain) )
 *msr_content |= IA32_FEATURE_CONTROL_ENABLE_VMXON_OUTSIDE_SMX;
 break;
-case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC:
-if ( !nvmx_msr_read_intercept(msr, msr_content) )
-goto gp_fault;
-break;
 case MSR_IA32_MISC_ENABLE:
 rdmsrl(MSR_IA32_MISC_ENABLE, *msr_content);
 /* Debug Trace Store is not supported. */
@@ -3160,8 +3156,6 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 break;
 }
 case MSR_IA32_FEATURE_CONTROL:
-case MSR_IA32_VMX_BASIC ... MSR_IA32_VMX_VMFUNC:
-/* None of these MSRs are writeable. */
 goto gp_fault;
 
 case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index c8c168b7d0..8f4a68cf9a 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1975,184 +1975,6 @@ int nvmx_handle_invvpid(struct cpu_user_regs *regs)
 return X86EMUL_OKAY;
 }
 
-#define __emul_value(enable1, default1) \
-((enable1 | default1) << 32 | (default1))
-
-#define gen_vmx_msr(enable1, default1, host_value) \
-(((__emul_value(enable1, default1) & host_value) & (~0ul << 32)) | \
-((uint32_t)(__emul_value(enable1, default1) | host_value)))
-
-/*
- * Capability reporting
- */
-int nvmx_msr_read_intercept(unsigned int msr, u64 *msr_content)
-{
-struct vcpu *v = current;
-struct domain *d = v->domain;
-u64 data = 0, host_data = 0;
-int r = 1;
-
-/* VMX capablity MSRs are available only when guest supports VMX. */
-if ( !nestedhvm_enabled(d) || !d->arch.cpuid->basic.vmx )
-return 0;
-
-/*
- * These MSRs are only available when flags in other MSRs are set.
- * These prerequisites are listed in the Intel 64 and IA-32
- * Architectures Software Developer’s Manual, Vol 3, Appendix A.
- */
-switch ( msr )
-{
-case MSR_IA32_VMX_PROCBASED_CTLS2:
-if ( !cpu_has_vmx_secondary_exec_control )
-return 0;
-break;
-
-case MSR_IA32_VMX_EPT_VPID_CAP:
-if ( !(cpu_has_vmx_ept || cpu_has_vmx_vpid) )
-return 0;
-break;
-
-case MSR_IA32_VMX_TRUE_PINBASED_CTLS:
-case MSR_IA32_VMX_TRUE_PROCBASED_CTLS:
-case MSR_IA32_VMX_TRUE_EXIT_CTLS:
-case MSR_IA32_VMX_TRUE_ENTRY_CTLS:
-if ( !(vmx_basic_msr & VMX_BASIC_DEFAULT1_ZERO) )
-return 0;
-break;
-
-case MSR_IA32_VMX_VMFUNC:
-if ( !cpu_has_vmx_vmfunc )
-return 0;
-break;
-}
-
-rdmsrl(msr, host_data);
-
-/*
- * Remove unsupport features from n1 guest capability MSR
- */
-switch (msr) {
-case MSR_IA32_VMX_BASIC:
-{
-const struct vmcs_struct *vmcs =
-map_domain_page(_mfn(PFN_DOWN(v->arch.hvm_vmx.vmcs_pa)));
-
-data = (host_data & (~0ul << 32)) |
-   (vmcs->vmcs_revision_id & 0x7fff);
-unmap_domain_page(vmcs);
-break;
-}
-case MSR_IA32_VMX_PINBASED_CTLS:
-case MSR_IA32_VMX_TRUE_PINBASED_CTLS:
-/* 1-settings */
-data = PIN_BASED_EXT_INTR_MASK |
-   PIN_BASED_NMI_EXITING |
-   PIN_BASED_PREEMPT_TIMER;
-data = gen_vmx_msr(data, VMX_PINBASED_CTLS_DEFAULT1, host_data);
-break;
-case MSR_IA32_VMX_PROCBASED_CTLS:
-case MSR_IA32_VMX_TRUE_PROCBASED_CTLS:
-{
-u32 default1_bits = VMX_PROCBASED_CTLS_DEFAULT1;
-/* 1-settings */
-data = CPU_BASED_HLT_EXITING |
-   CPU_BASED_VIRTUAL_INTR_PENDING |
-   CPU_BASED_CR8_LOAD_EXITING |
-   CPU_BASED_CR8_STORE_EXITING |
-   CPU_BASED_INVLPG_EXITING |
-   CPU_BASED_CR3_LOAD_EXITING |
-   CPU_BASED_CR3_STORE_EXITING |
-   CPU_BASED_MONITOR_EXITING |
-   CPU_BASED_MWAIT_EXITING |
-   CPU_BASED_MOV_DR_EXITING |
-   CPU_BASED_ACTIVATE_IO_BITMAP |
-   

[Xen-devel] [PATCH v5 3/5] x86/cpuid: update signature of hvm_cr4_guest_valid_bits()

[Sergey Dyasli]

With the new cpuid infrastructure there is a domain-wide struct cpuid
policy and there is no need to pass a separate struct vcpu * into
hvm_cr4_guest_valid_bits() anymore. Make the function accept struct
domain * instead and update callers.

Signed-off-by: Sergey Dyasli 
---
v4 --> v5: rebased to the latest staging
---
 xen/arch/x86/hvm/domain.c   | 3 ++-
 xen/arch/x86/hvm/hvm.c  | 7 +++
 xen/arch/x86/hvm/svm/svmdebug.c | 4 ++--
 xen/arch/x86/hvm/vmx/vmx.c  | 2 +-
 xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
 xen/include/asm-x86/hvm/hvm.h   | 2 +-
 6 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c
index 60474649de..ce15ce0470 100644
--- a/xen/arch/x86/hvm/domain.c
+++ b/xen/arch/x86/hvm/domain.c
@@ -111,6 +111,7 @@ static int check_segment(struct segment_register *reg, enum 
x86_segment seg)
 /* Called by VCPUOP_initialise for HVM guests. */
 int arch_set_info_hvm_guest(struct vcpu *v, const vcpu_hvm_context_t *ctx)
 {
+const struct domain *d = v->domain;
 struct cpu_user_regs *uregs = >arch.user_regs;
 struct segment_register cs, ds, ss, es, tr;
 const char *errstr;
@@ -272,7 +273,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const 
vcpu_hvm_context_t *ctx)
 if ( v->arch.hvm_vcpu.guest_efer & EFER_LME )
 v->arch.hvm_vcpu.guest_efer |= EFER_LMA;
 
-if ( v->arch.hvm_vcpu.guest_cr[4] & ~hvm_cr4_guest_valid_bits(v, 0) )
+if ( v->arch.hvm_vcpu.guest_cr[4] & ~hvm_cr4_guest_valid_bits(d, false) )
 {
 gprintk(XENLOG_ERR, "Bad CR4 value: %#016lx\n",
 v->arch.hvm_vcpu.guest_cr[4]);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0539551851..c96e166952 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -932,9 +932,8 @@ const char *hvm_efer_valid(const struct vcpu *v, uint64_t 
value,
 X86_CR0_CD | X86_CR0_PG)))
 
 /* These bits in CR4 can be set by the guest. */
-unsigned long hvm_cr4_guest_valid_bits(const struct vcpu *v, bool restore)
+unsigned long hvm_cr4_guest_valid_bits(const struct domain *d, bool restore)
 {
-const struct domain *d = v->domain;
 const struct cpuid_policy *p;
 bool mce, vmxe;
 
@@ -1001,7 +1000,7 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 }
 
-if ( ctxt.cr4 & ~hvm_cr4_guest_valid_bits(v, 1) )
+if ( ctxt.cr4 & ~hvm_cr4_guest_valid_bits(d, true) )
 {
 printk(XENLOG_G_ERR "HVM%d restore: bad CR4 %#" PRIx64 "\n",
d->domain_id, ctxt.cr4);
@@ -2344,7 +2343,7 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
 struct vcpu *v = current;
 unsigned long old_cr;
 
-if ( value & ~hvm_cr4_guest_valid_bits(v, 0) )
+if ( value & ~hvm_cr4_guest_valid_bits(v->domain, false) )
 {
 HVM_DBG_LOG(DBG_LEVEL_1,
 "Guest attempts to set reserved bit in CR4: %lx",
diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index 091c58fa1b..6c215d19fe 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -121,9 +121,9 @@ bool svm_vmcb_isvalid(const char *from, const struct 
vmcb_struct *vmcb,
(cr3 >> v->domain->arch.cpuid->extd.maxphysaddr))) )
 PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", cr3);
 
-if ( cr4 & ~hvm_cr4_guest_valid_bits(v, false) )
+if ( cr4 & ~hvm_cr4_guest_valid_bits(v->domain, false) )
 PRINTF("CR4: invalid bits are set (%#"PRIx64", valid: %#"PRIx64")\n",
-   cr4, hvm_cr4_guest_valid_bits(v, false));
+   cr4, hvm_cr4_guest_valid_bits(v->domain, false));
 
 if ( vmcb_get_dr6(vmcb) >> 32 )
 PRINTF("DR6: bits [63:32] are not zero (%#"PRIx64")\n",
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index aa0505036b..4856ad7c24 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1699,7 +1699,7 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr)
  * bits that are controlled by the hypervisor.
  */
 v->arch.hvm_vmx.cr4_host_mask = HVM_CR4_HOST_MASK | X86_CR4_PKE |
-~hvm_cr4_guest_valid_bits(v, 0);
+~hvm_cr4_guest_valid_bits(v->domain, 
0);
 v->arch.hvm_vmx.cr4_host_mask |= v->arch.hvm_vmx.vmx_realmode ?
  X86_CR4_VME : 0;
 v->arch.hvm_vmx.cr4_host_mask |= !hvm_paging_enabled(v) ?
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 8176736e8f..c8c168b7d0 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2135,7 +2135,7 @@ int nvmx_msr_read_intercept(unsigned int msr, u64 
*msr_content)
 data = X86_CR4_VMXE;
 break;
 case MSR_IA32_VMX_CR4_FIXED1:
-data = hvm_cr4_guest_valid_bits(v, 0);

[Xen-devel] [PATCH v5 4/5] x86/msr: update domain policy on CPUID policy changes

[Sergey Dyasli]

Availability of some MSRs depends on certain CPUID bits. Add function
recalculate_domain_msr_policy() which updates availability of per-domain
MSRs based on current domain's CPUID policy. This function is called
when CPUID policy is changed from a toolstack.

Add recalculate_domain_vmx_msr_policy() which changes availability of
VMX MSRs based on domain's nested virt settings. If it's enabled, then
the domain receives a copy of HVM_max vmx policy with allowed CR4 bits
adjusted by CPUID policy.

Signed-off-by: Sergey Dyasli 
---
v4 --> v5:
- Removed _domain from function names
- Added vmx_copy_policy() helper
- recalculate_vmx_msr_policy() was rewritten
---
 xen/arch/x86/domctl.c |  1 +
 xen/arch/x86/msr.c| 35 +++
 xen/include/asm-x86/msr.h |  3 +++
 3 files changed, 39 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 8fbbf3aeb3..5bde1a22b7 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -125,6 +125,7 @@ static int update_domain_cpuid_info(struct domain *d,
 }
 
 recalculate_cpuid_policy(d);
+recalculate_msr_policy(d);
 
 switch ( ctl->input[0] )
 {
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index f700e05570..9114b8f53b 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DEFINE_PER_CPU(uint32_t, tsc_aux);
 
@@ -282,6 +283,39 @@ void __init init_guest_msr_policy(void)
 calculate_pv_max_policy();
 }
 
+static void vmx_copy_policy(const struct msr_domain_policy *src,
+  struct msr_domain_policy *dst)
+{
+memcpy(dst->vmx.raw, src->vmx.raw, sizeof(dst->vmx.raw));
+dst->vmx_procbased_ctls2.raw = src->vmx_procbased_ctls2.raw;
+dst->vmx_ept_vpid_cap.raw = src->vmx_ept_vpid_cap.raw;
+memcpy(dst->vmx_true_ctls.raw, src->vmx_true_ctls.raw,
+   sizeof(dst->vmx_true_ctls.raw));
+dst->vmx_vmfunc.raw = src->vmx_vmfunc.raw;
+}
+
+static void recalculate_vmx_msr_policy(struct domain *d)
+{
+struct msr_domain_policy *dp = d->arch.msr;
+
+if ( !nestedhvm_enabled(d) || !d->arch.cpuid->basic.vmx )
+{
+vmx_clear_policy(dp);
+
+return;
+}
+
+vmx_copy_policy(_max_msr_domain_policy, dp);
+
+/* Get allowed CR4 bits from CPUID policy */
+dp->vmx.cr4_fixed1.allowed_1.raw = hvm_cr4_guest_valid_bits(d, false);
+}
+
+void recalculate_msr_policy(struct domain *d)
+{
+recalculate_vmx_msr_policy(d);
+}
+
 int init_domain_msr_policy(struct domain *d)
 {
 struct msr_domain_policy *dp;
@@ -302,6 +336,7 @@ int init_domain_msr_policy(struct domain *d)
 }
 
 d->arch.msr = dp;
+recalculate_msr_policy(d);
 
 return 0;
 }
diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
index 419ab6f8a7..4747572871 100644
--- a/xen/include/asm-x86/msr.h
+++ b/xen/include/asm-x86/msr.h
@@ -606,6 +606,9 @@ int init_vcpu_msr_policy(struct vcpu *v);
 int guest_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val);
 int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val);
 
+/* Update availability of per-domain MSRs based on CPUID policy */
+void recalculate_msr_policy(struct domain *d);
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_MSR_H */
-- 
2.14.1


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

[Xen-devel] [PATCH v5 2/5] x86/msr: add VMX MSRs into HVM_max domain policy

[Sergey Dyasli]

Currently, when nested virt is enabled, the set of L1 VMX features
is fixed and calculated by nvmx_msr_read_intercept() as an intersection
between the full set of Xen's supported L1 VMX features, the set of
actual H/W features and, for MSR_IA32_VMX_EPT_VPID_CAP, the set of
features that Xen uses.

Add calculate_hvm_max_vmx_policy() which will save the end result of
nvmx_msr_read_intercept() on current H/W into HVM_max domain policy.
There will be no functional change to what L1 sees in VMX MSRs. But the
actual use of HVM_max domain policy will happen later, when VMX MSRs
are handled by guest_rd/wrmsr().

Signed-off-by: Sergey Dyasli 
---
v4 --> v5:
- Macros are removed and now supported bitmask is used to derive policy
- Added vmx_clear_policy() helper
---
 xen/arch/x86/msr.c | 134 +
 1 file changed, 134 insertions(+)

diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 43607b5107..f700e05570 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -106,6 +106,138 @@ static void __init calculate_host_policy(void)
 dp->plaform_info.cpuid_faulting = cpu_has_cpuid_faulting;
 }
 
+static void vmx_clear_policy(struct msr_domain_policy *dp)
+{
+memset(dp->vmx.raw, 0, sizeof(dp->vmx.raw));
+dp->vmx_procbased_ctls2.raw = 0;
+dp->vmx_ept_vpid_cap.raw = 0;
+memset(dp->vmx_true_ctls.raw, 0, sizeof(dp->vmx_true_ctls.raw));
+dp->vmx_vmfunc.raw = 0;
+}
+
+static void __init calculate_hvm_max_vmx_policy(struct msr_domain_policy *dp)
+{
+const struct msr_domain_policy *hp = _msr_domain_policy;
+uint32_t supported;
+
+if ( !cpu_has_vmx )
+return;
+
+vmx_clear_policy(dp);
+
+dp->vmx.basic.raw = hp->vmx.basic.raw;
+
+dp->vmx.pinbased_ctls.allowed_0.raw = VMX_PINBASED_CTLS_DEFAULT1;
+dp->vmx.pinbased_ctls.allowed_1.raw = VMX_PINBASED_CTLS_DEFAULT1;
+supported = PIN_BASED_EXT_INTR_MASK |
+PIN_BASED_NMI_EXITING   |
+PIN_BASED_PREEMPT_TIMER;
+dp->vmx.pinbased_ctls.allowed_1.raw |= supported;
+dp->vmx.pinbased_ctls.allowed_1.raw &= hp->vmx.pinbased_ctls.allowed_1.raw;
+
+dp->vmx.procbased_ctls.allowed_0.raw = VMX_PROCBASED_CTLS_DEFAULT1;
+dp->vmx.procbased_ctls.allowed_1.raw = VMX_PROCBASED_CTLS_DEFAULT1;
+supported = CPU_BASED_HLT_EXITING  |
+CPU_BASED_VIRTUAL_INTR_PENDING |
+CPU_BASED_CR8_LOAD_EXITING |
+CPU_BASED_CR8_STORE_EXITING|
+CPU_BASED_INVLPG_EXITING   |
+CPU_BASED_MONITOR_EXITING  |
+CPU_BASED_MWAIT_EXITING|
+CPU_BASED_MOV_DR_EXITING   |
+CPU_BASED_ACTIVATE_IO_BITMAP   |
+CPU_BASED_USE_TSC_OFFSETING|
+CPU_BASED_UNCOND_IO_EXITING|
+CPU_BASED_RDTSC_EXITING|
+CPU_BASED_MONITOR_TRAP_FLAG|
+CPU_BASED_VIRTUAL_NMI_PENDING  |
+CPU_BASED_ACTIVATE_MSR_BITMAP  |
+CPU_BASED_PAUSE_EXITING|
+CPU_BASED_RDPMC_EXITING|
+CPU_BASED_TPR_SHADOW   |
+CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
+dp->vmx.procbased_ctls.allowed_1.raw |= supported;
+dp->vmx.procbased_ctls.allowed_1.raw &=
+hp->vmx.procbased_ctls.allowed_1.raw;
+
+dp->vmx.exit_ctls.allowed_0.raw = VMX_EXIT_CTLS_DEFAULT1;
+dp->vmx.exit_ctls.allowed_1.raw = VMX_EXIT_CTLS_DEFAULT1;
+supported = VM_EXIT_ACK_INTR_ON_EXIT   |
+VM_EXIT_IA32E_MODE |
+VM_EXIT_SAVE_PREEMPT_TIMER |
+VM_EXIT_SAVE_GUEST_PAT |
+VM_EXIT_LOAD_HOST_PAT  |
+VM_EXIT_SAVE_GUEST_EFER|
+VM_EXIT_LOAD_HOST_EFER |
+VM_EXIT_LOAD_PERF_GLOBAL_CTRL;
+dp->vmx.exit_ctls.allowed_1.raw |= supported;
+dp->vmx.exit_ctls.allowed_1.raw &= hp->vmx.exit_ctls.allowed_1.raw;
+
+dp->vmx.entry_ctls.allowed_0.raw = VMX_ENTRY_CTLS_DEFAULT1;
+dp->vmx.entry_ctls.allowed_1.raw = VMX_ENTRY_CTLS_DEFAULT1;
+supported = VM_ENTRY_LOAD_GUEST_PAT|
+VM_ENTRY_LOAD_GUEST_EFER   |
+VM_ENTRY_LOAD_PERF_GLOBAL_CTRL |
+VM_ENTRY_IA32E_MODE;
+dp->vmx.entry_ctls.allowed_1.raw |= supported;
+dp->vmx.entry_ctls.allowed_1.raw &= hp->vmx.entry_ctls.allowed_1.raw;
+
+dp->vmx.misc.raw = hp->vmx.misc.raw;
+/* Do not support CR3-target feature now */
+dp->vmx.misc.cr3_target = false;
+
+/* PG, PE bits must be 1 in VMX operation */
+dp->vmx.cr0_fixed0.allowed_0.pe = true;
+dp->vmx.cr0_fixed0.allowed_0.pg = true;
+
+/* allow 0-settings for all bits */
+dp->vmx.cr0_fixed1.allowed_1.raw = 0x;
+
+/* VMXE bit must be 1 in VMX operation */
+dp->vmx.cr4_fixed0.allowed_0.vmxe = true;
+
+/*
+ * Allowed CR4 bits will be 

[Xen-devel] [PATCH v5 0/5] VMX MSRs policy for Nested Virt: part 1

[Sergey Dyasli]

The end goal of having VMX MSRs policy is to be able to manage
L1 VMX features. This patch series is the first part of this work.
There is no functional change to what L1 sees in VMX MSRs at this
point. But each domain will have a policy object which allows to
sensibly query what VMX features the domain has. This will unblock
some other nested virtualization work items.

Currently, when nested virt is enabled, the set of L1 VMX features
is fixed and calculated by nvmx_msr_read_intercept() as an intersection
between the full set of Xen's supported L1 VMX features, the set of
actual H/W features and, for MSR_IA32_VMX_EPT_VPID_CAP, the set of
features that Xen uses.

The above makes L1 VMX feature set inconsistent between different H/W
and there is no ability to control what features are available to L1.
The overall set of issues has much in common with CPUID policy.

Part 1 adds VMX MSRs into struct msr_domain_policy and initializes them
during domain creation based on CPUID policy. In the future it should be
possible to independently configure values of VMX MSRs for each domain.

v4 --> v5:
- First patch "x86/msr: add Raw and Host domain policies" was upstreamed
  separately
- Combined the next 2 patches into 1

Sergey Dyasli (5):
  x86/msr: add VMX MSRs definitions and populate Raw domain policy
  x86/msr: add VMX MSRs into HVM_max domain policy
  x86/cpuid: update signature of hvm_cr4_guest_valid_bits()
  x86/msr: update domain policy on CPUID policy changes
  x86/msr: handle VMX MSRs with guest_rd/wrmsr()

 xen/arch/x86/domctl.c  |   1 +
 xen/arch/x86/hvm/domain.c  |   3 +-
 xen/arch/x86/hvm/hvm.c |   7 +-
 xen/arch/x86/hvm/svm/svmdebug.c|   4 +-
 xen/arch/x86/hvm/vmx/vmx.c |   8 +-
 xen/arch/x86/hvm/vmx/vvmx.c| 178 
 xen/arch/x86/msr.c | 322 +++
 xen/include/asm-x86/hvm/hvm.h  |   2 +-
 xen/include/asm-x86/hvm/vmx/vvmx.h |   2 -
 xen/include/asm-x86/msr.h  | 333 +
 xen/include/asm-x86/x86-defns.h|  54 ++
 11 files changed, 719 insertions(+), 195 deletions(-)

-- 
2.14.1


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

Re: [Xen-devel] [PATCH RFC 3/3] xtf: add minimal HPET functionality test

[Roger Pau Monné]

On Fri, Feb 23, 2018 at 07:07:18PM +, Wei Liu wrote:
> On Fri, Feb 23, 2018 at 01:27:43PM +, Roger Pau Monne wrote:
> > Add a basic HPET functionality test, note that this test requires the
> > HPET to support level triggered interrupts.
> > 
> > Further improvements should add support for interrupt delivery, and
> > testing all the available timers.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Andrew Cooper 
> > ---
> >  arch/x86/include/arch/lib.h |  14 
> >  docs/all-tests.dox  |   2 +
> >  tests/hpet/Makefile |   9 +++
> >  tests/hpet/main.c   | 187 
> > 
> >  4 files changed, 212 insertions(+)
> >  create mode 100644 tests/hpet/Makefile
> >  create mode 100644 tests/hpet/main.c
> > 
> > diff --git a/arch/x86/include/arch/lib.h b/arch/x86/include/arch/lib.h
> > index 6714bdc..3400890 100644
> > --- a/arch/x86/include/arch/lib.h
> > +++ b/arch/x86/include/arch/lib.h
> > @@ -392,6 +392,20 @@ static inline void write_xcr0(uint64_t xcr0)
> >  xsetbv(0, xcr0);
> >  }
> >  
> > +static inline uint64_t rdtsc(void)
> > +{
> > +uint32_t low, high;
> > +
> > +asm volatile ("rdtsc" : "=a" (low), "=d" (high));
> > +
> 
> You probably need to add lfence or mfence. See rdtsc_ordered in Xen.

Oh, OK that's news to me. I guess just using a lfence before it
should be fine.

> > +return ((uint64_t)high << 32) | low;
> > +}
> > +
> [...]
> > +static void set_freq(void)
> > +{
> > +uint32_t eax, ebx, ecx, edx, base;
> > +bool found = false;
> > +
> > +/* Get tsc frequency from cpuid. */
> > +for ( base = XEN_CPUID_FIRST_LEAF;
> > +  base < XEN_CPUID_FIRST_LEAF + 0x1; base += 0x100 )
> > +{
> > +cpuid(base, , , , );
> > +
> > +if ( (ebx == XEN_CPUID_SIGNATURE_EBX) &&
> > + (ecx == XEN_CPUID_SIGNATURE_ECX) &&
> > + (edx == XEN_CPUID_SIGNATURE_EDX) &&
> > + ((eax - base) >= 2) )
> > +{
> > +found = true;
> > +break;
> > +}
> > +}
> > +
> > +if ( !found )
> > +panic("Unable to locate Xen CPUID leaves\n");
> > +
> 
> Finding Xen leaves should live in its own function and move to common
> code if possible.

There's already one in common code. The right way to fix this seems to
be to store 'base' and use it in further cpuid related calls.

> > +cpuid_count(base + 3, 0, , , , );
> > +printk("TSC frequency %ukHz\n", freq);
> > +}
> > +
> > +/* Busy-wait implementation based on tsc value. */
> > +static void wait(unsigned int ms)
> > +{
> > +uint64_t end = rdtsc() + (uint64_t)ms * (uint64_t)freq;
> > +
> > +while ( rdtsc() < end )
> > +pause();
> > +}
> 
> Rename to mdelay and move to a helper file?

OK, wasn't sure whether this would be helpful or not.

> > +
> > +void test_main(void)
> > +{
> [...]
> > +HPET_REG(HPET_Tn_CFG(nr)) &= ~HPET_TN_LEVEL;
> > +HPET_REG(HPET_STATUS) = 1 << nr;
> > +wait(200);
> > +if ( ((HPET_REG(HPET_STATUS) >> nr) & 1) )
> > +return xtf_failure("Fail: Status bit set for edge interrupt in 
> > periodic mode\n");
> > +
> 
> Is it possible to use shorter time in the test? This test as-is will run
> for 1 or 2 seconds which is a bit long as micro-kernel testing.

Likely, I can reduce the periods and waits to something smaller. Let
me use a define and then we can tweak this, but using a 1ms period
should be fine.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2 4/5] tools: xenpm: continue to support {set, get}-vcpu-migration-delay

[George Dunlap]

On 02/28/2018 03:17 PM, Dario Faggioli wrote:
> On Wed, 2018-02-28 at 15:02 +, George Dunlap wrote:
>> On 02/23/2018 04:41 PM, Dario Faggioli wrote:
>>> From this commit on, `xenpm {set,get}-vcpu-migration-delay'
>>>
>>> commands work again. But that is only for the sake of
>>> backward compatibility, and their use is deprecated, in
>>> favour of 'xl sched-credit -s [-c ] -m '.
>>>
>>> Signed-off-by: Dario Faggioli 
>>> Acked-by: Wei Liu 
>>
>> If we cared about strict behavioral compatibility, we would modify
>> the
>> xenpm function to set the migration delay for all cpupools; but I
>> think
>> we can worry about that if anyone complains. :-)
>>
> Yes, I thought about that. But, considering what would be required to
> implement such behavior, as compared to how many people (as far as we
> can tell, of course) use this feature, and use xenpm to change it, I
> also thought we are indeed fine "waiting and seeing".
> 
>>> @@ -1087,13 +1097,17 @@ void set_vcpu_migration_delay_func(int
>>> argc, char *argv[])
>>>  
>>>  void get_vcpu_migration_delay_func(int argc, char *argv[])
>>>  {
>>> -uint32_t value;
>>> +struct xen_sysctl_credit_schedule sparam;
>>> +
>>> +printf("WARNING: using xenpm for this purpose is deprecated."
>>> +   " Check out `xl sched-credit -s'\n");
>>
>> Should these warnings be to stderr rather than stdout, so that if
>> anything is manually parsing stout it will continue to work?
>>
> Again, I considered this, for that same reason. The reason why I
> decided for stdout is for maximizing the chances that anyone actually
> using this will see the warning (even if, e.g., they're redirecting
> stderr).

If they're redirecting stderr then they have explicitly decided to
ignore warnings and errors -- if they want to miss messages like this
they should be allowed to.  I would think it much more likely that
stdout would be redirected somewhere than stderr.

 -George

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

Re: [Xen-devel] [PATCH v2 3/7] x86/alt: Clean up the assembly used to generate alternatives

[Jan Beulich]

 >>> On 26.02.18 at 12:35,  wrote:
> * On the C side, switch to using local lables rather than hardcoded numbers.
>  * Rename parameters and lables to be consistent with alt_instr names, and
>consistent between the the C and asm versions.
>  * On the asm side, factor some expressions out into macros to aid clarity.
>  * Consistently declare section attributes.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 3/6] xen/sched: Improvements to the {alloc, free}_domdata() interfaces

[George Dunlap]

On 02/28/2018 02:14 PM, Andrew Cooper wrote:
> The main purpose of this change is for the subsequent cleanup it enables, but
> it stands on its own merits.
> 
> In principle, these hooks are optional, but the SCHED_OP() default aliases a
> memory allocation failure, which causes arinc653 to play the dangerous game of
> passing its priv pointer back, and remembering not to actually free it.
> 
> Redefine alloc_domdata to use ERR_PTR() for errors, NULL for nothing, and
> non-NULL for a real allocation, which allows the hook to become properly
> optional.  Redefine free_domdata to be idempotent.
> 
> For arinc653, this means the dummy hooks can be dropped entirely.  For the
> other schedulers, this means returning ERR_PTR(-ENOMEM) instead of NULL for
> memory allocation failures, and modifying the free hooks to cope with a NULL
> pointer.  While making the alterations, drop some spurious casts to void *.
> 
> Introduce and use proper wrappers for sched_{alloc,free}_domdata().  These are
> strictly better than SCHED_OP(), as the source code is visible to
> grep/cscope/tags, the generated code is better, and there can be proper
> per-hook defaults and checks.
> 
> Callers of the alloc hooks are switched to using IS_ERR(), rather than
> checking for NULL.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH v3] build: remove shim related targets

[Jan Beulich]

>>> On 28.02.18 at 16:02,  wrote:
> But that raises the question, if prefix=/usr/local this will become:
> 
> /usr/local/lib/usr/local/lib/xen/...

/usr/local/lib/debug/usr/local/lib/xen/...

> Should this instead be:
> 
> /usr/local/lib/usr/lib/xen/...

/usr/local/lib/debug/usr/lib/xen/...

> I don't think so, but want to be sure.

Neither, I would say (without knowing whether there are any
conventions for ${prefix}/lib/debug) - what has the full path got to
do in the middle in there? The more when it's /home/... or
something even more obscure?

Jan


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

Re: [Xen-devel] [PATCH 2/6] xen/credit2: Move repl_timer into struct csched2_dom

[George Dunlap]

On 02/28/2018 02:14 PM, Andrew Cooper wrote:
> For exactly the same reason as 418ae6021d.  Having a separate allocation is
> unnecessary and wasteful.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 

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

[Xen-devel] [PATCH] xen/arm: p2m: Prevent deadlock when using memaccess

[Julien Grall]

Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
assumed the read-write lock can be taken recursively. However, this
assumption is wrong and will lead to deadlock when the lock is
contended.

To avoid the nested lock, rework the locking in get_page_from_gva and
p2m_mem_access_check_and_get_page. The latter will now be called without
the p2m lock. The new locking in p2m_mem_accces_check_and_get_page will
not cover the translation of the VA to an IPA.

This is fine because we can't promise that the stage-1 page-table have
changed behind our back (they are under guest control). Modification in
the stage-2 page-table can now happen, but I can't issue any potential
issue here except with the break-before-make sequence used when updating
page-table. gva_to_ipa may fail if the sequence is executed at the same
on another CPU. In that case we would fallback in the software lookup
path.

Signed-off-by: Julien Grall 

---
This patch should be backported to Xen 4.10. There are other
potential optimization that I am working on. Although, I don't think
they are backport material.
---
 xen/arch/arm/mem_access.c | 8 ++--
 xen/arch/arm/p2m.c| 4 ++--
 xen/include/asm-arm/p2m.h | 4 
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index 0f2cbb81d3..11c2b03b7b 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -126,7 +126,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag,
  * is not mapped.
  */
 if ( guest_walk_tables(v, gva, , ) < 0 )
-goto err;
+return NULL;
 
 /*
  * Check permissions that are assumed by the caller. For instance in
@@ -139,11 +139,13 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag,
  * test for execute permissions this check can be left out.
  */
 if ( (flag & GV2M_WRITE) && !(perms & GV2M_WRITE) )
-goto err;
+return NULL;
 }
 
 gfn = gaddr_to_gfn(ipa);
 
+p2m_read_lock(p2m);
+
 /*
  * We do this first as this is faster in the default case when no
  * permission is set on the page.
@@ -216,6 +218,8 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag,
 page = NULL;
 
 err:
+p2m_read_unlock(p2m);
+
 return page;
 }
 
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 65e8b9c6ea..5de82aafe1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1449,11 +1449,11 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
vaddr_t va,
 }
 
 err:
+p2m_read_unlock(p2m);
+
 if ( !page && p2m->mem_access_enabled )
 page = p2m_mem_access_check_and_get_page(va, flags, v);
 
-p2m_read_unlock(p2m);
-
 return page;
 }
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index a0abc84ed8..45ef2cd58b 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -23,10 +23,6 @@ extern void memory_type_changed(struct domain *);
 struct p2m_domain {
 /*
  * Lock that protects updates to the p2m.
- *
- * Please note that we use this lock in a nested way by calling
- * access_guest_memory_by_ipa in guest_walk_(sd|ld). This must be
- * considered in the future implementation.
  */
 rwlock_t lock;
 
-- 
2.11.0


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

Re: [Xen-devel] kexec and xen/arch/x86/boot/head.S trampoline

[Andrew Cooper]

On 28/02/18 14:08, Trammell Hudson wrote:
> This is a belated followup to my post in 2016, which was a followup to a
> post by Ward Vandewege in 2008 about problems introduced by Xen 3.1.3's
> changes in the trampoline allocation code:
>
> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg01208.html
>
> I've been maintaining an out-of-tree patch for using Xen with coreboot
> and the Heads runtime since my previous post and finally decided to track
> down what in coreboot was causing the issue.  It turns out that it is
> not a coreboot problem, but caused by kexec.
>
> kexec allocates a 1 page segment at 0x0 and memsets most of it to zero,
> wiping out coreboot's EBDA structure, which xen's head.S consulted to
> allocate the trampoline.  Xen's code looks like this:

This sounds like a bug as and of itself.  I presume this is to do with
IVT handling?

>
> /* Set up trampoline segment 64k below EBDA */
> movzwl  0x40e,%ecx  /* EBDA segment */
> cmp $0xa000,%ecx/* sanity check (high) */
> jae 0f
> cmp $0x4000,%ecx/* sanity check (low) */
> jae 1f
> 0:
> movzwl  0x413,%ecx  /* use base memory size on failure */
> shl $10-4,%ecx
> 1:
> /*
>  * Compare the value in the BDA with the information from the
>  * multiboot structure (if available) and use the smallest.
>  */
> testb   $MBI_MEMLIMITS,(%ebx)
> jz  2f  /* not available? BDA value will be fine 
> */
> mov MB_mem_lower(%ebx),%edx
> cmp $0x100,%edx /* is the multiboot value too small? */
> jb  2f  /* if so, do not use it */
> shl $10-4,%edx
> cmp %ecx,%edx   /* compare with BDA value */
> cmovb   %edx,%ecx   /* and use the smaller */
>
> 2:  /* Reserve 64kb for the trampoline */
> sub $0x1000,%ecx
>
> Since 0x40e is zero, it goes into the base memory size fallback,
> which also results in %ecx being zero.  Since zero is less than whatever
> is in the MBI, Xen decides to use minus 0x1000 for the trampoline and faults
> soon afterwards as a result.

The original code which introduced this is 46fce9fd2b355, but I agree
that the obviously wrong when we fail the low sanity check.

> Are there reasons to prefer EBDA over mbi->mem_lower?
>
> If not, it seems that easiest way to patch it would be always trust the
> mbi lower memory value if the memlimits bit is set (which is what my
> out-of-tree patch did) and only fall back to EBDA data if the mbi->flags
> MEMLIMITS bit is not set.  And even then it would be good to to duplicate
> the guard for %ecx < 0x4000 || %ecx > 0xa000 when reading from 0x413
> and signal an error rather than faulting.

I think the expectation was that the EBDA would be more reliable than
mbi->mem_lower.  However, we recently hit a similar bug with PVH
handling (c/s a232346b1fe), and these days, the EBDA is quite likely not
to be present.

I think we probably can use mbi->mem_lower (if available and sane) by
default.  If the bootloader has messed that up, all bets are off
anyway.  Irrespective, we should fix the EBDA lower sanity check.

What is the current size of the trampoline?  ISTR Jan or Juergen (CC'd)
suggesting that there was some shrinking work which could be done.

~Andrew

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

Re: [Xen-devel] [PATCH 1/6] xen/domain: Reduce the quantity of initialisation for system domains

[George Dunlap]

On 02/28/2018 02:14 PM, Andrew Cooper wrote:
>  * System domains don't need watchdog initialisation or iomem/irq rangesets,
>and will not plausibly be a xenstore or hardware domain.
>  * The idle domain doesn't need scheduler initialisation (and in particular,
>removing this path allows for substantial scheduler cleanup), and isn't
>liable to ever need late_hwdom_init().
> 
> Move all of these initialisations pass the DOMCRF_dummy early exit, and into
> non-idle paths.  rangeset_domain_initialise() remains because it makes no
> allocations, but does initialise a linked list and spinlock.  The poolid
> parameter can be dropped as sched_init_domain()'s parameter is now
> unconditionally 0.
> 
> Signed-off-by: Andrew Cooper 

Looks good:

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH] xen-netfront: Fix hang on device removal

[Boris Ostrovsky]

On 02/28/2018 07:23 AM, Jason Andryuk wrote:
> A toolstack may delete the vif frontend and backend xenstore entries
> while xen-netfront is in the removal code path.  In that case, the
> checks for xenbus_read_driver_state would return XenbusStateUnknown, and
> xennet_remove would hang indefinitely.  This hang prevents system
> shutdown.
>
> xennet_remove must be able to handle XenbusStateUnknown, and
> netback_changed must also wake up the wake_queue for that state as well.
>
> Fixes: 5b5971df3bc2 ("xen-netfront: remove warning when unloading module")
>
> Signed-off-by: Jason Andryuk 
> Cc: Eduardo Otubo 

Reviewed-by: Boris Ostrovsky 



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

Re: [Xen-devel] [PATCH v2 4/5] tools: xenpm: continue to support {set, get}-vcpu-migration-delay

[Dario Faggioli]

On Wed, 2018-02-28 at 15:02 +, George Dunlap wrote:
> On 02/23/2018 04:41 PM, Dario Faggioli wrote:
> > From this commit on, `xenpm {set,get}-vcpu-migration-delay'
> > 
> > commands work again. But that is only for the sake of
> > backward compatibility, and their use is deprecated, in
> > favour of 'xl sched-credit -s [-c ] -m '.
> > 
> > Signed-off-by: Dario Faggioli 
> > Acked-by: Wei Liu 
> 
> If we cared about strict behavioral compatibility, we would modify
> the
> xenpm function to set the migration delay for all cpupools; but I
> think
> we can worry about that if anyone complains. :-)
> 
Yes, I thought about that. But, considering what would be required to
implement such behavior, as compared to how many people (as far as we
can tell, of course) use this feature, and use xenpm to change it, I
also thought we are indeed fine "waiting and seeing".

> > @@ -1087,13 +1097,17 @@ void set_vcpu_migration_delay_func(int
> > argc, char *argv[])
> >  
> >  void get_vcpu_migration_delay_func(int argc, char *argv[])
> >  {
> > -uint32_t value;
> > +struct xen_sysctl_credit_schedule sparam;
> > +
> > +printf("WARNING: using xenpm for this purpose is deprecated."
> > +   " Check out `xl sched-credit -s'\n");
> 
> Should these warnings be to stderr rather than stdout, so that if
> anything is manually parsing stout it will continue to work?
> 
Again, I considered this, for that same reason. The reason why I
decided for stdout is for maximizing the chances that anyone actually
using this will see the warning (even if, e.g., they're redirecting
stderr).

But I am fine with both, actually, just let me know what's considered
best.

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

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

Re: [Xen-devel] [PATCH v3] build: remove shim related targets

[Roger Pau Monné]

On Wed, Feb 28, 2018 at 06:25:23AM -0700, Jan Beulich wrote:
> >>> On 28.02.18 at 14:02,  wrote:
> > On Wed, Feb 28, 2018 at 05:29:06AM -0700, Jan Beulich wrote:
> >> >>> On 28.02.18 at 12:47,  wrote:
> >> > On Wed, Feb 28, 2018 at 04:02:53AM -0700, Jan Beulich wrote:
> >> >> >>> On 21.02.18 at 13:22,  wrote:
> >> >> > --- a/tools/firmware/Makefile
> >> >> > +++ b/tools/firmware/Makefile
> >> >> > @@ -8,6 +8,7 @@ endif
> >> >> >  # hvmloader is a 32-bit protected mode binary.
> >> >> >  TARGET  := hvmloader/hvmloader
> >> >> >  INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
> >> >> > +DEBG_DIR := $(DESTDIR)$(DEBUG_DIR)$(XENFIRMWAREDIR)
> >> >> 
> >> >> This is screwing up my build, and looking again I can't see how
> >> >> this can be right: Both $(XENFIRMWAREDIR) and $(DEBUG_DIR)
> >> >> are supposed to be ${prefix}-able, yet there clearly should not
> >> >> be an infix resulting from the construction of this path.
> >> > 
> >> > By being prefixable you mean that both XENFIRMWAREDIR and DEBUG_DIR
> >> > can be relative paths?
> >> 
> >> Both should be possible to live in /usr/lib or /usr/local/lib,
> >> for example.
> > 
> > I'm afraid I don't see the issue, could you provide the values of
> > DESTDIR, DEBUG_DIR and XENFIRMWAREDIR that are causing the issue?
> 
> My build issue is because of some tweaking I have to do in order to
> be able to run the tools from the build directory (it's quite sad that
> this still isn't supported "out of the box").
> 
> > Is this because you end up with something like:
> > 
> > /usr/local/lib/debug/usr/local/... in the debug path?
> 
> Indeed (except the first "local" you show wrongly isn't there), just
> that there's some /home/jbeulich/.../ infix, but _no_ such prefix
> (DESTDIR for the reason mentioned above can't be set to
> /home/jbeulich/..., or [I don't recall] either the build breaks or
> things don't work in the end, but needs to be forced to / on the
> make command line; as said I have a compensating tweak
> elsewhere so that the full resulting path is correct everywhere
> _except_ now for DEBG_DIR).

OK, I *think* I understand what's missing here. This would be more
correct as $(DESTDIR)$(prefix)$(DEBUG_DIR)$(XENFIRMWAREDIR).

It looks like DEBUG_DIR wants to be set in Paths.mk.in as you
suggested.

But that raises the question, if prefix=/usr/local this will become:

/usr/local/lib/usr/local/lib/xen/...

Should this instead be:

/usr/local/lib/usr/lib/xen/...

I don't think so, but want to be sure.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2 4/5] tools: xenpm: continue to support {set, get}-vcpu-migration-delay

[George Dunlap]

On 02/23/2018 04:41 PM, Dario Faggioli wrote:
> Now that it is possible to get and set the migration
> delay via the SCHEDOP sysctl, use that in xenpm, instead
> of the special purpose libxc interface (which will be
> removed in a following commit).
> 
> The sysctl, however, requires a cpupool-id argument,
> for knowing on which scheduler it is operating on. In
> this case, since we don't want to alter xenpm's command
> line interface, we always use '0', which means xenpm
> will always act on the default cpupool ('Pool-0').
> 
>>From this commit on, `xenpm {set,get}-vcpu-migration-delay'
> commands work again. But that is only for the sake of
> backward compatibility, and their use is deprecated, in
> favour of 'xl sched-credit -s [-c ] -m '.
> 
> Signed-off-by: Dario Faggioli 
> Acked-by: Wei Liu 

If we cared about strict behavioral compatibility, we would modify the
xenpm function to set the migration delay for all cpupools; but I think
we can worry about that if anyone complains. :-)

One comment...

> @@ -1087,13 +1097,17 @@ void set_vcpu_migration_delay_func(int argc, char 
> *argv[])
>  
>  void get_vcpu_migration_delay_func(int argc, char *argv[])
>  {
> -uint32_t value;
> +struct xen_sysctl_credit_schedule sparam;
> +
> +printf("WARNING: using xenpm for this purpose is deprecated."
> +   " Check out `xl sched-credit -s'\n");

Should these warnings be to stderr rather than stdout, so that if
anything is manually parsing stout it will continue to work?

Everything else looks good, thanks.

 -George

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

Re: [Xen-devel] [PATCH] xen/pirq: fix error path cleanup when binding MSIs

[Boris Ostrovsky]

On 02/28/2018 04:22 AM, Shah, Amit wrote:
> On Mi, 2018-02-28 at 09:19 +, Roger Pau Monne wrote:
>> Current cleanup in the error path of xen_bind_pirq_msi_to_irq is
>> wrong. First of all there's an off-by-one in the cleanup loop, which
>> can lead to unbinding wrong IRQs.
>>
>> Secondly IRQs not bound won't be freed, thus leaking IRQ numbers.
>>
>> Note that there's no need to differentiate between bound and unbound
>> IRQs when freeing them, __unbind_from_irq will deal with both of them
>> correctly.
>>
>> Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
>> Reported-by: Hooman Mirhadi 
>> Signed-off-by: Roger Pau Monné 
>> ---
>> Cc: Boris Ostrovsky 
>> Cc: Juergen Gross 
>> Cc: Amit Shah 
>> CC: sta...@vger.kernel.org
>> Cc: xen-devel@lists.xenproject.org
>> ---
>>  drivers/xen/events/events_base.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/xen/events/events_base.c
>> b/drivers/xen/events/events_base.c
>> index b241bfa529ce..159faf1269fb 100644
>> --- a/drivers/xen/events/events_base.c
>> +++ b/drivers/xen/events/events_base.c
>> @@ -763,8 +763,8 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev,
>> struct msi_desc *msidesc,
>>  mutex_unlock(_mapping_update_lock);
>>  return irq;
>>  error_irq:
>> -for (; i >= 0; i--)
>> -__unbind_from_irq(irq + i);
>> +while (nvec--)
>> +__unbind_from_irq(irq + nvec);
>>  mutex_unlock(_mapping_update_lock);
>>  return ret;
>>  }
> Reviewed-by: Amit Shah 

Reviewed-by: Boris Ostrovsky 

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

[Xen-devel] Ping: Ping#3: [PATCH v3] x86/HVM: don't #GP/#SS on wrapping virt->linear translations

[Jan Beulich]

>>> On 06.12.17 at 08:44,  wrote:
 On 04.12.17 at 17:39,  wrote:
> > On 04/12/17 10:16, Jan Beulich wrote:
> > On 25.08.17 at 16:59,  wrote:
> >> On 10.08.17 at 09:19,  wrote:
> >>> On 10.07.17 at 12:39,  wrote:
> > Real hardware wraps silently in most cases, so we should behave the
> > same. Also split real and VM86 mode handling, as the latter really
> > ought to have limit checks applied.
> >
> > Signed-off-by: Jan Beulich 
> > ---
> > v3: Restore 32-bit wrap check for AMD.
> > v2: Extend to non-64-bit modes. Reduce 64-bit check to a single
> > is_canonical_address() invocation.
> >> Same here - I think I've been carrying this for long enough.
> > 
> > I'm not sure what to say.  I'm not comfortable taking this change
> > without a regression test in place, which also serves to demonstrate the
> > correctness of the change.
> > 
> > Its simply a matter of time, not any other objection to the change.
> 
> Well, I had sent you a tentative XTF test long ago (non-publicly
> at the time, I believe). Here it is again. I'll send a second change
> in a minute, which iirc is necessary as prereq to the one here.
> 
> Jan

No matter that hopefully no-one will exercise us currently getting
things wrong, I'd still like to re-raise the fact that the original bug
fix in this thread has been pending for a really long time, and this
XTF test has now also been sent almost 3 months ago.

Jan

> add split memory access tests
> 
> Add tests to verify that accesses crossing the upper address boundary
> are being handled similarly with and without the emulator involved.
> 
> Signed-off-by: Jan Beulich 
> ---
> v2: Use FS overrides. Add 64-bit and PV tests. Remove stray '-s from
> log messages. Add "X" (ex_record_fault_eax) constraints.
> 
> --- /dev/null
> +++ b/tests/split-access/Makefile
> @@ -0,0 +1,9 @@
> +include $(ROOT)/build/common.mk
> +
> +NAME  := split-access
> +CATEGORY  := functional
> +TEST-ENVS := $(ALL_ENVIRONMENTS)
> +
> +obj-perenv += main.o
> +
> +include $(ROOT)/build/gen.mk
> --- /dev/null
> +++ b/tests/split-access/main.c
> @@ -0,0 +1,251 @@
> +/**
> + * @file tests/split-access/main.c
> + * @ref test-split-access
> + *
> + * @page test-split-access split-access
> + *
> + * @todo Docs for test-split-access
> + *
> + * @see tests/split-access/main.c
> + */
> +#include 
> +
> +#include 
> +#include 
> +
> +const char test_title[] = "Split memory access insns";
> +
> +const void *volatile boundary = NULL;
> +
> +/* Keep the compiler from leveraging undefined behavior. */
> +#define touch(x) ({ asm ( "" : "+g" (x) ); })
> +
> +void do_mov(bool force)
> +{
> +const unsigned long *ptr = boundary;
> +
> +touch(ptr);
> +for ( --ptr; ; )
> +{
> +unsigned long val;
> +exinfo_t fault = 0;
> +
> +asm volatile ( "test %[fep], %[fep];"
> +   "jz 1f;"
> +   _ASM_XEN_FEP
> +   "1: mov %%fs:%[src],%[dst]; 2:"
> +   _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
> +   : [dst] "=r" (val), "+a" (fault)
> +   : [src] "m" (*ptr), [fep] "q" (force),
> + "X" (ex_record_fault_eax) );
> +if ( fault )
> +xtf_warning("Got %pe for %p\n", _p(fault), ptr);
> +else if ( val != *ptr )
> +xtf_failure("%lx != %lx for %p\n", val, *ptr, ptr);
> +
> +touch(ptr);
> +if ( ptr == boundary )
> +break;
> +
> +ptr = (void *)(long)ptr + 1;
> +}
> +}
> +
> +void do_lfs(bool force)
> +{
> +const struct __packed { unsigned long off; uint16_t sel; } *ptr = 
> boundary;
> +
> +touch(ptr);
> +for ( --ptr; ; )
> +{
> +unsigned long off;
> +exinfo_t fault = 0;
> +
> +asm volatile ( "test %[fep], %[fep];"
> +   "jz 1f;"
> +   _ASM_XEN_FEP
> +   "1: lfs %%fs:%[src],%[dst]; 2:"
> +   _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
> +   : [dst] "=r" (off), "+a" (fault)
> +   : [src] "m" (*ptr), [fep] "q" (force),
> + "X" (ex_record_fault_eax) );
> +if ( fault )
> +xtf_warning("Got %pe for %p\n", _p(fault), ptr);
> +else if ( off != ptr->off )
> +xtf_failure("%lx != %lx for %p\n", off, ptr->off, ptr);
> +
> +touch(ptr);
> +if ( ptr == boundary )
> +break;
> +
> +ptr = (void *)(long)ptr + 1;
> +}
> +}
> +
> +#ifdef CONFIG_HVM
> +void do_lidt(bool force)
> +{
> +const desc_ptr *ptr = boundary;
> +
> +touch(ptr);
> +for ( --ptr; ; )
> +{
> +exinfo_t fault = 0;
> +
> +asm volatile ( "test %[fep], %[fep];"
> +   "jz 1f;"
> +