On 18/03/2019 14:58, Jan Beulich wrote:
On 18.03.19 at 15:11, wrote:
>> On 18/03/2019 13:20, Jan Beulich wrote:
>>> >>> On 18.03.19 at 12:27, wrote:
* Some of the single-byte versions specify "=q" as the output. This is a
remnent of the 32bit build and can be relaxed to "=r" i
On 25/03/2019 11:33, Wei Liu wrote:
> On Mon, Mar 25, 2019 at 11:21:44AM +, Wei Liu wrote:
>> On Fri, Mar 22, 2019 at 11:13:40AM +0000, Andrew Cooper wrote:
>>> CentOS 6 is probably the most frequently broken build, so adding it to CI
>>> would be a very good move.
On 25/03/2019 15:24, Jan Beulich wrote:
On 21.03.19 at 21:26, wrote:
>> It turns out that this code was previously dead.
> If it was entirely dead, why the rush to get the change into 4.12?
> (I suppose the later parts of description are then justifying why
> the code wasn't actually dead, an
On 26/03/2019 12:20, Jan Beulich wrote:
>>>> On 21.03.19 at 13:21, wrote:
>> When filling a policy, either from CPUID or an incomming leaf stream,
>> recalculate the synthesised vendor value. All callers are expected to want
>> this behaviour.
>>
>> S
On 26/03/2019 09:08, Jan Beulich wrote:
>>
Leave the warning which identifies the problematic devices, but drop the
remaining logic. This leaves the system in better overall state, and
working
in the same way that it did in previous releases.
>>> I wonder whether you've taken
On 26/03/2019 11:52, Jan Beulich wrote:
>>>> On 21.03.19 at 13:21, wrote:
>> Also introduce constants for the vendor strings in CPUID leaf 0.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
> albeit I'd appreciate if this was committed t
the Qemu upstream build
instead. Additionally, SeaBIOS requires GCC 4.6 or later, so skip it as well.
Signed-off-by: Andrew Cooper
---
CC: Wei Liu
CC: Doug Goldstein
v2:
* Skip SeaBIOS as well
I've already pushed this container to the registry, for testing purposes.
A sample pipeli
On 26/03/2019 12:08, Jan Beulich wrote:
On 21.03.19 at 13:21, wrote:
>> get_cpu_vendor() tries to do a number of things, and ends up doing none of
>> them well.
>>
>> For calculating the vendor itself, use x86_cpuid_lookup_vendor() which is
>> implemented in a far more efficient manner than l
On 26/03/2019 13:39, Jan Beulich wrote:
On 26.03.19 at 13:43, wrote:
>> On 26/03/2019 09:08, Jan Beulich wrote:
>> Leave the warning which identifies the problematic devices, but drop the
>> remaining logic. This leaves the system in better overall state, and
>> working
>> i
On 26/03/2019 14:39, Jan Beulich wrote:
On 26.03.19 at 15:23, wrote:
>> IMO especially in the CPUID case it is desirable to explicitly specify
>> the width of the data. Looking at nodes 0x8002 and following this
>> should be rather clear (and I even think get_model_name() should be
>> mod
in *d)
> }
>
> /*
> - * This function is used by cpu_hotplug code from stop_machine context
> + * This function is used by cpu_hotplug code via cpu notifier chain
> * and from cpupools to switch schedulers on a cpu.
> + * Caller must get domlist_read_lock.
s/get/hold/ ?
Wi
On 18/03/2019 13:11, Juergen Gross wrote:
> Add a helper cpu_notifier_call_chain() to call notifier_call_chain()
> for a cpu with a specified action, returning an errno value.
>
> This avoids coding the same pattern multiple times.
>
> Signed-off-by: Juergen Gross
> ---
> xen/common/cpu.c | 50 ++
On 18/03/2019 13:11, Juergen Gross wrote:
> Instead of freeing percpu areas during suspend and allocating them
> again when resuming keep them. Only free an area in case a cpu didn't
> come up again when resuming.
>
> Signed-off-by: Juergen Gross
Hmm - this is slightly problematic, given the dual
On 27/03/2019 17:32, Paul Durrant wrote:
> The Xen blkif protocol is confusing but discussion with the maintainer
> has clarified that sector based quantities in requests and the 'sectors'
> value advertized in xenstore should always be in terms of 512-byte
> units and not the advertised logical 's
On 27/03/2019 18:45, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It expects
> the register size to match the value size.
>
> The instruction clz is expecting the two operands to be the same size
> (i.e 32-bit or 64-bit). As the flsl function is dealing wi
On 27/03/2019 18:45, Julien Grall wrote:
> Clang will throw an error if a function is unused unless you tell
> to ignore it. This can be done using __maybe_unused.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/mm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/
On 27/03/2019 18:45, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
>
> The instructions msr/mrs are expecting a 64-bit register. This means the
> implementation of the 32-bit helpers is not correct. Th
This has been problematic since its introduction in Xen 4.3
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vvmx.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch
On 28/03/2019 09:55, Jan Beulich wrote:
On 27.03.19 at 19:45, wrote:
>> Clang uses "-target" option for cross-compilation.
> And all possible targets are always available? I'd like to point out
> that CROSS_COMPILE can be used for other than actual cross
> compilation, e.g. building with just
On 28/03/2019 10:28, Jan Beulich wrote:
On 28.03.19 at 11:14, wrote:
>> On 28/03/2019 09:55, Jan Beulich wrote:
>> On 27.03.19 at 19:45, wrote:
Clang uses "-target" option for cross-compilation.
>>> And all possible targets are always available? I'd like to point out
>>> that CROSS_
On 28/03/2019 11:40, Anthony PERARD wrote:
> On Wed, Mar 27, 2019 at 08:32:28PM +, Paul Durrant wrote:
>>> -Original Message-
>>> From: Andrew Cooper
>>> Sent: 27 March 2019 18:20
>>> To: Paul Durrant ; xen-devel@lists.xenproject.org;
On 28/03/2019 14:48, Jan Beulich wrote:
> I'm in particular after getting rid of asm/apicdef.h, but there are more
> no longer (or perhaps never having been) used ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
On 28/03/2019 14:49, Jan Beulich wrote:
> There's no need to log anything when what we "switch to" is what is in
> use already.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel
On 28/03/2019 14:49, Jan Beulich wrote:
> In order to be able to initialize x2APIC mode we need to parse
> respective ACPI tables early. Split amd_iov_detect() into two parts for
> this purpose, and call the initial part earlier on.
>
> Signed-off-by: Jan Beulich
Reviewed-by
f-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 28/03/2019 14:52, Jan Beulich wrote:
> Introduce a respective element in struct iommu_init_ops.
>
> Take the liberty and also switch intel_iommu_supports_eim() to bool/
> true/false, to fully match the hook's type.
>
> Signed-off-by: Jan Beulich
Rev
On 28/03/2019 14:53, Jan Beulich wrote:
> @@ -35,6 +35,8 @@ void print_vtd_entries(struct iommu *iom
> keyhandler_fn_t vtd_dump_iommu_info;
>
> bool intel_iommu_supports_eim(void);
> +int intel_iommu_enable_x2apic_IR(void);
> +void intel_iommu_disable_x2apic_IR(void);
Is there any particular r
On 28/03/2019 14:54, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -26,6 +26,19 @@
> const struct iommu_init_ops *__initdata iommu_init_ops;
> struct iommu_ops __read_mostly iommu_ops;
>
> +int __init iommu_hardware_setup(void)
>
On 28/03/2019 17:44, George Dunlap wrote:
> On 3/28/19 5:03 PM, Jan Beulich wrote:
>> Reported-by: George Dunlap
>> Signed-off-by: Jan Beulich
> That seems to fix all the ones related to the crashes I was seeing:
>
> Tested-by: George Dunlap
>
>> ---
>> This is surely a stable tree candidate, un
== OP_MEM && evex.opmsk )
> +if ( ea.type == OP_MEM && cpu_has_avx512f && evex.opmsk &&
> + _get_fpu(fpu_type = X86EMUL_FPU_opmask, ctxt, ops) == X86EMUL_OKAY )
The cpu_has_avx512f check is now redundant. It is fully encapsulated by
_get_fpu(
On 29/03/2019 09:36, Jan Beulich wrote:
On 29.03.19 at 10:19, wrote:
>> On 29/03/2019 07:42, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -3511,7 +3511,8 @@ x86_emulate(
>>> }
>>>
>>> /* With a memory o
On 29/03/2019 14:51, Jan Beulich wrote:
> Drop it entirely for %rbp - this register is not special purpose enough
> to warrant such special treatment. Add a comment to clarify the purpose
> of the canonicalization of %rip and %rsp.
>
> Signed-off-by: Jan Beulich
Acked-by
ioned correctly,
but only by virtue of confusing a discrete object and a single-entry array.
Change its type to match the intended semantics, and drop the redundant
initialisation in timer_init().
No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulic
On 29/03/2019 16:23, Jan Beulich wrote:
On 29.03.19 at 17:02, wrote:
>> --- a/xen/common/timer.c
>> +++ b/xen/common/timer.c
>> @@ -45,18 +45,27 @@ DEFINE_PER_CPU(s_time_t, timer_deadline);
>>
>>
>> /
>> * HEAP
uses new timers to be put on the list
rather than the heap, and for timer_softirq_action() to bootstrap itself
again.
This in practice leaks ts->heap every time a CPU is hot unplugged and
replugged. In the cpu notifier, free the heap after migrating all other
timers away.
Signed-off-by: An
On 29/03/2019 17:39, Rian Quinn wrote:
> Out of curiosity, has there been any research done on whether or not
> it makes more sense to just disable CPU threading with respect to
> overall performance? In some of the testing that we did with OpenXT,
> we noticed in some of our tests a performance in
On 29/03/2019 15:08, Juergen Gross wrote:
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 6b5d454630..d1a958143a 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -256,6 +256,7 @@ static void sched_spin_unlock_double(spinlock_t *lock1,
> spinlock_t *lock2
_first(&cpus);
> +
> +/* We can rely on previous vcpu being available. */
Only if you ASSERT(!is_idle_domain(d)), which is safe given the sole caller.
idle->vcpu[] can be sparse in some corner cases.
Ideally with both of these suggestions, Acked-by: Andrew Cooper
> +
On 29/03/2019 15:09, Juergen Gross wrote:
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 9b5527c1eb..0b5e5e566b 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -347,7 +347,7 @@ int sched_init_vcpu(struct vcpu *v)
> if ( (item = sched_alloc_item(v))
On 29/03/2019 19:20, George Dunlap wrote:
>
>> On Mar 29, 2019, at 4:14 PM, Jan Beulich wrote:
>>
> On 29.03.19 at 16:42, wrote:
On Mar 29, 2019, at 3:23 PM, Jan Beulich wrote:
>>> On 29.03.19 at 16:14, wrote:
> FAOD:
> 1. I don’t oppose this, but
> 2. I don’t support i
On 29/03/2019 15:09, Juergen Gross wrote:
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 8d579e2cf9..5d8f3255cb 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
On 01/04/2019 08:05, Dario Faggioli wrote:
> On Mon, 2019-04-01 at 08:06 +0200, Juergen Gross wrote:
>> On 30/03/2019 11:24, Juergen Gross wrote:
>>> I think its is easier to do it myself, as I'm touching nearly all
>>> of
>>> the call sites anyway.
>> And another thought I had: with RETPOLINE indi
On 01/04/2019 09:05, Jan Beulich wrote:
>>>> On 01.04.19 at 07:59, wrote:
>> On 30/03/2019 10:59, Juergen Gross wrote:
>>> On 29/03/2019 22:33, Andrew Cooper wrote:
>>>> If at all possible, I'd prefer to see about disentangling the bits which
>>
On 01/04/2019 09:01, Jan Beulich wrote:
>>>> On 30.03.19 at 10:59, wrote:
>> On 29/03/2019 22:33, Andrew Cooper wrote:
>>> If at all possible, I'd prefer to see about disentangling the bits which
>>> actually need external use, and putting them in sc
On 29/03/2019 15:09, Juergen Gross wrote:
> Make sure the number of vcpus is always a multiple of the scheduling
> granularity. Note that we don't support a scheduling granularity above
> one on ARM.
I'm afraid that I don't think this is a clever move. In turn, this
brings into question the appro
as no buisness using VCPUOP_get_physid, and shouldn't
be able to just because it happens to be pinned by admin choice. All uses of
is_pinned_vcpu() should be restricted to the hardware domain, so rename it to
is_hwdom_pinned_vcpu() to avoid future misuse.
Signed-off-by: Andrew Cooper
---
CC:
On 01/04/2019 11:39, Wei Liu wrote:
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 01/04/2019 13:21, Jan Beulich wrote:
On 01.04.19 at 12:09, wrote:
>> 3) cpumask_weight() is a surprisingly expensive function, and we use it all
>>over the place. It will almost certainly benefit from the use of popcnt.
> FTR this was something I was meaning to possibly do once the BM
now no writes to this MSR other
than Xen's microcode loading facilities, which means that the value held in
the MSR will be properly up-to-date. Forward it directly, without jumping
through any hoops.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Davi
On 29/03/2019 09:39, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -8547,6 +8547,9 @@ x86_emulate(
> invoke_stub("", "", "+m" (mask) : "a" (&mask));
> put_stub(stub);
>
> +if ( rc != X86EMUL_OKAY )
>
On 29/03/2019 10:56, Jan Beulich wrote:
On 29.03.19 at 11:02, wrote:
>> On 29/03/2019 09:36, Jan Beulich wrote:
>>> I'd like to put up the other option then: Rather than using
>>> _get_fpu() (and in particular the read_xcr() and read_cr() hooks)
>>> we could read the real XCR0 here. After all
; through any hoops.
> I agree with this, so
> Reviewed-by: Jan Beulich
Thanks, but I'll wait to see if we get a Shanghai answer in a reasonable
period of time.
>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Wei Liu
>> CC: Roger Pa
exception before gathering any elements."
>
> I realize this is all "may", but iirc I had tried it out on some of the
> hardware I have, and it indeed did so there.
That does only talk about the mismatched parts of the registers, but the
fact that it does call out the 0 ca
On 01/04/2019 11:32, Wei Liu wrote:
> The code suggests 0 is allowed. Zero is not a positive number.
>
> Signed-off-by: Wei Liu
I suspect you are opening a can of number theory worms with that commit
message, but the overall change is an improvement.
Acked-by: Andr
On 01/04/2019 11:32, Wei Liu wrote:
> String is unicode in 3 but bytes in 2. We need to call decode function
> when using Python 3.
>
> Reported-by: M A Young
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing
ady has code to handle
> that.
>
> Reported-by: M A Young
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 01/04/2019 11:32, Wei Liu wrote:
> 1. Explicitly import reduce because that's required in 3.
> 2. Change print to function.
> 3. Eliminate invocations of has_key.
>
> Signed-off-by: M A Young
> Signed-off-by: Wei Liu
Rev
is in practice leaks ts->heap every time a CPU is hot unplugged and
>> replugged. In the cpu notifier, free the heap after migrating all other
>> timers away.
>>
>> Signed-off-by: Andrew Cooper
> Could I talk you into using online/offline instead of plug/unplug,
> as
he else path dead.
> iommu_ops may have got set already during x2APIC IR enabling (see
> patch 6).
In which case a
/* x2apic setup may have previously initialised the IOMMU ops. */
or similar would do nicely, to explain this logic.
With that, Reviewed-by: Andrew Cooper
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ble_x2apic_IR(void)
>>> ... using iommu_{en,dis}able_x2apic() here to match the
>>> supports_x2apic() init hook.
>>>
>>>
>>> I don't think these shorter names are any more ambiguous, and loosing
>>> the _IR suffix doe
On 01/04/2019 09:40, Jan Beulich wrote:
On 30.03.19 at 11:42, wrote:
>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
> I think it would have been nice if you had mentioned the real
>
On 30/03/2019 10:42, Pu Wen wrote:
> +static const struct cpu_dev hygon_cpu_dev = {
> + .c_vendor = "Hygon",
> + .c_ident= { "HygonGenuine" },
> + .c_early_init = early_init_amd,
> + .c_init = init_hygon,
> +};
> +
> +int __init hygon_init_cpu(void)
> +{
> +
from its name,
> as it and all its callers get touched anyway.
>
> No functional change.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
up wrong this way (and which will need adjustment itself as
> well, to also consume the full value).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>> ; Razvan Cojocaru ; Konrad
>> Rzeszutek Wilk ; George Dunlap
>> ; Andrew Cooper ; Ian
>> Jackson ; Tim (Xen.org) ; Julien
>> Grall ; Tamas K Lengyel ; Jan
>> Beulich ; Roger Pau Monne
>> Subject: Re: [Xen-devel] [RFC PATCH 4/6] vm_event: Use slotted channels
>
On 30/03/2019 10:40, Pu Wen wrote:
> As a new x86 CPU vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
> is a joint venture between AMD and Haiguang Information Technology Co.,
> Ltd., aims at providing high performance x86 processors for China
> server market.
>
> The first generation Hygon pro
On 02/04/2019 06:34, Juergen Gross wrote:
> Especially in the scheduler area (schedule.c, cpupool.c) there is a
> rather complex handling involved when doing suspend and resume.
>
> This can be simplified a lot by not performing a complete cpu down and
> up cycle for the non-boot cpus, but keeping
On 02/04/2019 16:46, Jan Beulich wrote:
On 02.04.19 at 13:58, wrote:
>> On 2019/4/2 18:20, Jan Beulich wrote:
>>> On 02.04.19 at 08:46, wrote:
On 2019/4/1 16:41, Jan Beulich wrote:
> On 30.03.19 at 11:42, wrote:
>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families.
On 02/04/2019 17:14, Pu Wen wrote:
> On 2019/4/2 23:46, Jan Beulich wrote:
>> On 02.04.19 at 13:58, wrote:
>>> On 2019/4/2 18:20, Jan Beulich wrote:
On 02.04.19 at 08:46, wrote:
> On 2019/4/1 16:41, Jan Beulich wrote:
>> On 30.03.19 at 11:42, wrote:
>>> There is no MSR_INTEL_PLA
On 02/04/2019 17:42, Julien Grall wrote:
> diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
> index 97466a12b1..35a47c7229 100644
> --- a/xen/arch/arm/early_printk.c
> +++ b/xen/arch/arm/early_printk.c
> @@ -17,9 +17,10 @@
> void early_putch(char c);
> void early_flush(void)
code slightly to fold the exit paths, which
results in a minor reduction in compiled code size.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/common/cpu.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a
intended to be shorthands for a loop over cpu-{online,offline}.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
Slightly RFC. I'm not very happy with the contination situation, but -EBUSY
is the preexisting style and it seems like it is the only option
A future change is going to introduce two more cases. Instead of opcoding the
XSM checks and contine_hypercall logic, collect the data into local variables.
Switch the default return value to -EOPNOTSUPP to distinguish a bad op from a
bad cpu index.
Signed-off-by: Andrew Cooper
---
CC: Jan
This is some work which was discussed for L1TF and never got finished.
Testing for this work is what discovered the cpu online/offline memory leak.
Andrew Cooper (3):
xen/cpu: Distinguish "cpu already in that state" in cpu_{up,down}()
x86/sysctl: Clean up XEN_SYSCTL_cpu_hotplug
x8
On 03/04/2019 09:53, Jan Beulich wrote:
On 02.04.19 at 21:57, wrote:
>> --- a/xen/arch/x86/sysctl.c
>> +++ b/xen/arch/x86/sysctl.c
>> @@ -137,27 +137,35 @@ long arch_do_sysctl(
>> case XEN_SYSCTL_cpu_hotplug:
>> {
>> unsigned int cpu = sysctl->u.cpu_hotplug.cpu;
>> +
n}_helper() helpers with logic which understands siblings based on
>> their APIC_ID.
>>
>> Add libxc stubs, and extend xen-hptool with smt-{enable,disable} options.
>> These are intended to be shorthands for a loop over cpu-{online,offline}.
>>
>> Signed-off-by: Andr
eal problem is that your comment about NMI now makes the code read
as if everything is safe, and while this patch is an improvement (and
therefore ok on its own merits), it doesn't actually make the result #MC
safe.
3) Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 03/04/2019 11:44, Jan Beulich wrote:
On 03.04.19 at 12:17, wrote:
>> On 03/04/2019 10:33, Jan Beulich wrote:
>> On 02.04.19 at 21:57, wrote:
Slightly RFC. I'm not very happy with the contination situation, but
-EBUSY
is the preexisting style and it seems like it is th
On 03/04/2019 13:43, Jan Beulich wrote:
On 03.04.19 at 13:14, wrote:
>> On 03/04/2019 11:12, Jan Beulich wrote:
>> On 01.08.18 at 16:22, wrote:
When putting CPUs to sleep permanently, we should try to put them into
the most power conserving state possible. For now it is unclear
This was identified IRL at the safety summit, so I took the opportunity to
improve things.
The result of this series, and some other in-development bits, can be found
at:
https://andrewcoop-xen.readthedocs.io/en/docs-devel/index.html
Andrew Cooper (2):
docs/sphinx: Introduce a hypervisor
Include (and retrofit to the user guide) an introductory paragraph describing
the intended audience.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
---
docs
During a discussion in person, it was identified that Coverage doesn't
currently work for ARM yet. Also, there are a number of errors with the
existing coverage document.
Take the opportunity to rewrite it in RST, making it easier to follow for a
non-expert user.
Signed-off-by: Andrew C
s, they shouldn't use gfn/mfn terminology for their parameters.
Switch them to use straight uint64_t full addresses.
Finally, correct the dte_set_gcr3_table() to use the proper shift. Express
the shifts visually using MASK_EXTR() and literal masks, which IMO is the
clearest way to express the
On 13/03/2019 12:38, Jan Beulich wrote:
> In a few cases only a query is intended, i.e. without populating a
> possible PoD or paged out entry, when the intention is to replace the
> current entry anyway. Use get_gfn_query() there instead.
>
> Signed-off-by: Jan Beulich
Revi
On 13/03/2019 12:38, Jan Beulich wrote:
> Instead of the separate iommu_ret, the general rc can be used even for
> the IOMMU operations.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing li
On 13/03/2019 12:39, Jan Beulich wrote:
> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
> expensive (but still needed only for the toggle_guest_mode() path), the
> effect of the latter on the exit-to-guest path is not insignificant.
> Move the logic into toggle_guest_mode
On 13/03/2019 12:38, Jan Beulich wrote:
> When there's no XPTI-enabled PV domain at all, there's no need to issue
> respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
> record the creation of PV domains by bumping opt_xpti_* accordingly.
>
> Signed-off-by: Jan Beulich
> ---
> TBD:
These were made redundant by c/s 23058e7b3 "x86/shadow: put PV L1TF functions
under CONFIG_PV" but makes the code read as if outside of the ifdef.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/asm-x86/shadow.h | 4 ++--
1 file
On 04/04/2019 11:39, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 03 April 2019 19:08
>> To: Xen-devel
>> Cc: Andrew Cooper ; Jan Beulich
>> ; Wei Liu
>> ; Roger Pau Monne ; Bri
On 04/04/2019 13:29, Julien Grall wrote:
>
> On 04/04/2019 13:07, Artem Mygaiev wrote:
>> Hello Andrew
> Hi,
>
>> Minor note below.
>>
>> On Wed, 2019-04-03 at 16:00 +0100, Andrew Cooper wrote:
>>
>> [snip]
>>
>>> + For ARM builds, w
On 04/04/2019 13:46, Razvan Cojocaru wrote:
> On 4/3/19 6:30 PM, Jan Beulich wrote:
> On 03.04.19 at 17:17, wrote:
>>> On 4/3/19 5:58 PM, Jan Beulich wrote:
>>> On 03.04.19 at 16:29, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -3011,8 +3011,16 @@ in
ure. And point FETCHER to `false'
>> command if neither wget nor ftp is available, so any attempt to
>> download will result in error.
>>
>> Signed-off-by: Wei Liu
> Ping?
>
> This one is rather low risk. I intend to c
On 03/04/2019 10:38, Jan Beulich wrote:
On 03.04.19 at 11:06, wrote:
>> On 03/04/2019 09:53, Jan Beulich wrote:
>> On 02.04.19 at 21:57, wrote:
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -137,27 +137,35 @@ long arch_do_sysctl(
case XEN_SYSCTL_cpu_
On 04/04/2019 14:45, Pu Wen wrote:
> index 774ceac..75fefcf 100644
> --- a/xen/include/asm-x86/x86-vendors.h
> +++ b/xen/include/asm-x86/x86-vendors.h
> @@ -30,6 +30,11 @@
> #define X86_VENDOR_SHANGHAI_ECX 0x20206961U
> #define X86_VENDOR_SHANGHAI_EDX 0x68676e61U
>
> -#define X86_VENDOR_NUM 5
>
On 04/04/2019 15:04, Julien Grall wrote:
> At the moment, xen/lib/x86 is covered by the "REST". However, this is
> x86-only, so this can fall under the x86 maintainership.
>
> Signed-off-by: Julien Grall
Reviewed-by: Andrew Cooper
Sorry - this is alm
On 04/04/2019 15:11, Wei Liu wrote:
> Signed-off-by: Wei Liu
Sadly not. This is a char[8] field (so loses the \0 terminator), which
then gets passed to %s
I've got an overhaul to this area of code in the works, and am planning
to remove this field entirely,
~Andrew
___
On 04/04/2019 15:19, Wei Liu wrote:
> On Thu, Apr 04, 2019 at 03:18:49PM +0100, Andrew Cooper wrote:
>> On 04/04/2019 15:11, Wei Liu wrote:
>>> Signed-off-by: Wei Liu
>> Sadly not. This is a char[8] field (so loses the \0 terminator), which
>> then gets passed to %s
On 04/04/2019 15:20, Julien Grall wrote:
> Hi,
>
> On 04/04/2019 15:19, Jan Beulich wrote:
> On 04.04.19 at 16:04, wrote:
>>> At the moment, xen/lib/x86 is covered by the "REST". However, this is
>>> x86-only, so this can fall under the x86 maintainership.
>>>
>>> Signed-off-by: Julien Grall
as soon as guest EFER becomes equal to Xen EFER
> (almost any 64-bit VM) stale version of EFER is incorrectly
> loaded into a guest causing almost immediate guest failure.
>
> Signed-off-by: Igor Druzhinin
Reviewed-by: Andrew Cooper
___
Xe
On 16/10/2018 19:54, Andrew Cooper wrote:
> Hello,
>
> I realise this is an old CPU, but I've I've encountered a weird failure
> on it.
>
> Specifically:
>
> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 23 (0x17), Stepping 6
> (raw 00010676)
> [root@ha
1101 - 1200 of 11868 matches
Mail list logo
