>>> On 13.03.19 at 18:04, wrote:
> On 13/03/2019 10:30, Andrew Cooper wrote:
>> On 13/03/2019 07:39, Jan Beulich wrote:
>> On 12.03.19 at 17:53, wrote:
IIRC we agreed that systems with mixed CPU versions are not supported,
hence the same microcode blob should be used to update all t
>>> On 13.03.19 at 17:13, wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
>> Sent: 13 March 2019 13:15
>> To: Paul Durrant
>> Cc: Stefano Stabellini ; Wei Liu
>> ;
> Konrad Rzeszutek Wilk
>> ; George Dunlap ; A
>>> On 13.03.19 at 17:05, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
>> Jan Beulich
>> Sent: 13 March 2019 15:55
>>
>> >>> On 11.03.19 at 19:09, wrote:
>> > --- a/xen/include/asm-x86/msr.h
>> > +++ b/xen/include/asm-x86/msr.h
>> > @@ -328,7 +328,7 @@
>>> On 13.03.19 at 18:24, wrote:
> On 13/03/2019 15:04, Jan Beulich wrote:
> On 18.02.19 at 12:35, wrote:
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -2121,9 +2121,9 @@ void init_xenheap_pages(paddr_t ps, paddr_t pe)
>>>* Yuk! Ensure there is a one-page
>>> On 13.03.19 at 18:30, wrote:
> On 13/03/2019 15:20, Jan Beulich wrote:
> On 18.02.19 at 12:35, wrote:
>>> --- a/xen/common/domctl.c
>>> +++ b/xen/common/domctl.c
>>> @@ -205,7 +205,7 @@ void getdomaininfo(struct domain *d, struct
> xen_domctl_getdomaininfo *info)
>>> info->outstand
>>> On 13.03.19 at 18:34, wrote:
> On 13/03/2019 15:59, Jan Beulich wrote:
> On 13.03.19 at 16:48, wrote:
>>> On 13/03/2019 15:40, Jan Beulich wrote:
>>> On 13.03.19 at 16:24, wrote:
> On 13/03/2019 15:22, Jan Beulich wrote:
> On 18.02.19 at 12:36, wrote:
>>> --- a/xen/i
>>> On 13.03.19 at 19:41, wrote:
> On 13/03/2019 17:42, Julien Grall wrote:
>> On 13/03/2019 17:34, Andrew Cooper wrote:
>>> Given that "having an M2P" is now an x86-specific concept, I think
>>> phasing set_gpfn_from_mfn()'s use out of common code is the way to go.
>>
>> So you never expect other
>>> On 13.03.19 at 20:37, wrote:
> --- a/tools/misc/xen-cpuid.c
> +++ b/tools/misc/xen-cpuid.c
> @@ -127,6 +127,8 @@ static const char *str_7c0[32] =
> [14] = "avx512_vpopcntdq",
>
> [22] = "rdpid",
> +
> +[30] = "sgx-lc",
> };
>
> static const char *str_e7d[32] =
Hmm, to be h
flight 133755 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133755/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 130965
Tests
On 12/03/2019 20:46, David Hildenbrand wrote:
> On 12.03.19 19:23, David Hildenbrand wrote:
>> On 12.03.19 19:02, Boris Ostrovsky wrote:
>>> On 3/12/19 1:24 PM, Andrew Cooper wrote:
On 12/03/2019 17:18, David Hildenbrand wrote:
> On 12.03.19 18:14, Matthew Wilcox wrote:
>> On Tue, Mar
>>> On 05.03.19 at 14:14, wrote:
> From: Andrii Anisov
>
> The hypercall employs the same vcpu_register_runstate_memory_area
> structure for the interface, but requires registered area to not
> cross a page boundary.
>
> Signed-off-by: Andrii Anisov
While first of all you'll need to settle th
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 14 March 2019 07:48
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Wei Liu ; Stefano Stabellini
> ;
> xen-devel ; Konrad Rzeszutek Wilk
> ; Tim
>
>>> On 05.03.19 at 14:14, wrote:
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -305,6 +305,26 @@ static void update_runstate_area(struct vcpu *v)
> 1);
> }
> }
> +else if ( v->runstate_guest_type == RUNSTATE_PADDR )
> +{
> +
Dear Xen Developer mailing list,
I have been looking for detailed Information about the current status of Xen
hypervisor debugging. I checked the mailing list (questions mostly unanswered
or outdated), the repositories, and several search engine without a satisfying
answer to my question. Is th
> -Original Message-
> From: Markus Armbruster [mailto:arm...@redhat.com]
> Sent: 13 March 2019 17:45
> To: qemu-de...@nongnu.org
> Cc: sstabell...@kernel.org; Anthony Perard ; Paul
> Durrant
> ; xen-devel@lists.xenproject.org;
> qemu-bl...@nongnu.org
> Subject: [PATCH] xen-block: Replace
While doing some scheduler work I used debug trace for diagnosis of
problems during dom0 boot. This small series is the result of adapting
debug trace to my needs.
Juergen Gross (2):
xen/debug: make debugtrace configurable via Kconfig
xen/debug: make debugtrace more clever regarding repeating
In case debugtrace is writing to memory and the last entry is repeated
don't fill up the trace buffer, but modify the count prefix to "x-y "
style instead.
Signed-off-by: Juergen Gross
---
xen/drivers/char/console.c | 44 +---
1 file changed, 33 insertions
Instead of having to edit include/xen/lib.h for making debugtrace
available make it configurable via Kconfig.
Default is off, it is available only in expert mode or in debug builds.
Signed-off-by: Juergen Gross
---
xen/Kconfig.debug | 7 +++
xen/drivers/char/console.c | 2 +-
xen/i
flight 133765 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133765/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd-again 5 host-install(5) fail REGR. vs. 133707
version targeted
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Paul Durrant
> Sent: 13 March 2019 14:37
> To: 'Jan Beulich'
> Cc: Stefano Stabellini ; Wei Liu
> ; Konrad Rzeszutek Wilk
> ; Andrew Cooper ; Tim
> (Xen.org) ;
> George Dunlap ; Julien
While working on the scheduler I needed to modify some bits which are
worth to be considered as a stand-alone improvement IMO.
Juergen Gross (2):
xen: introduce a cpumask with all bits set
xen/sched: don't disable scheduler on cpus during suspend
xen/arch/x86/io_apic.c| 4 +-
xen/commo
There are several places in Xen allocating a cpumask on the stack and
setting all bits in it just to use it as an initial mask for allowing
all cpus.
Save the stack space and omit the need for runtime initialization by
defining a globally accessible cpumask_all variable.
Signed-off-by: Juergen Gr
Today there is special handling in cpu_disable_scheduler() for suspend
by forcing all vcpus to the boot cpu. In fact there is no need for that
as during resume the vcpus are put on the correct cpus again.
So we can just omit the call of cpu_disable_scheduler() when offlining
a cpu due to suspend a
On 14/03/2019 09:59, Juergen Gross wrote:
> There are several places in Xen allocating a cpumask on the stack and
> setting all bits in it just to use it as an initial mask for allowing
> all cpus.
>
> Save the stack space and omit the need for runtime initialization by
> defining a globally access
On 14/03/2019 11:04, Andrew Cooper wrote:
> On 14/03/2019 09:59, Juergen Gross wrote:
>> There are several places in Xen allocating a cpumask on the stack and
>> setting all bits in it just to use it as an initial mask for allowing
>> all cpus.
>>
>> Save the stack space and omit the need for runti
Hi Jan,
On 3/14/19 7:52 AM, Jan Beulich wrote:
On 13.03.19 at 18:24, wrote:
On 13/03/2019 15:04, Jan Beulich wrote:
On 18.02.19 at 12:35, wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2121,9 +2121,9 @@ void init_xenheap_pages(paddr_t ps, paddr_t pe)
* Yuk! E
On 14/03/2019 10:12, Julien Grall wrote:
> Hi Jan,
>
> On 3/14/19 7:52 AM, Jan Beulich wrote:
> On 13.03.19 at 18:24, wrote:
>>> On 13/03/2019 15:04, Jan Beulich wrote:
>>> On 18.02.19 at 12:35, wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2121,
Hi Andrew,
On 3/14/19 10:14 AM, Andrew Cooper wrote:
On 14/03/2019 10:12, Julien Grall wrote:
Hi Jan,
On 3/14/19 7:52 AM, Jan Beulich wrote:
On 13.03.19 at 18:24, wrote:
On 13/03/2019 15:04, Jan Beulich wrote:
On 18.02.19 at 12:35, wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/pa
On 3/14/19 9:59 AM, Juergen Gross wrote:
> There are several places in Xen allocating a cpumask on the stack and
> setting all bits in it just to use it as an initial mask for allowing
> all cpus.
>
> Save the stack space and omit the need for runtime initialization by
> defining a globally access
flight 133757 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133757/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 133672
Tests which did not suc
On 14/03/2019 08:20, Jan Beulich wrote:
On 13.03.19 at 20:37, wrote:
>> --- a/tools/misc/xen-cpuid.c
>> +++ b/tools/misc/xen-cpuid.c
>> @@ -127,6 +127,8 @@ static const char *str_7c0[32] =
>> [14] = "avx512_vpopcntdq",
>>
>> [22] = "rdpid",
>> +
>> +[30] = "sgx-lc",
>> };
>>
On 19/12/2018 15:08, Jan Beulich wrote:
> Bring libxl's in line with the public header, and update xen-cpuid's to
> the latest information available in Intel's documentation (SDM ver 068
> and ISA extensions ver 035), with (as before) the exception on MAWAU.
>
> Some pre-existing strings get change
...from arch_domain_shutdown/pause/unpause().
A subsequent patch will introduce an implementaion of synthetic timers
which will also need freeze/thaw hooks, so make the exported hooks more
generic and call through to (re-named and static) time_ref_count_freeze/thaw
functions.
NOTE: This patch als
...where there is more than one dereference inside a function.
This shortens the code and makes it more readable. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
xen/arch/x86/hvm/viridia
...inside viridian_page_msr and viridian_guest_os_id_msr unions.
There's no need to name it and the code is shortened by not doing so.
No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v4:
- New in v4
---
xen
Whilst the reference tsc page does not currently need to be kept mapped
after it is initially set up (or updated after migrate), the code can
be simplified by using the common guest page map/unmap and dump functions.
New functionality added by a subsequent patch will also require the page to
kept m
This series adds three new enlightenments:
- Synthetic timers, which depends on the...
- Synthetic interrupt controller (or SynIC)
- Synthetic cluster IPI
All these enlightenments are implemented in current versions of QEMU/KVM
so this series closes the gap.
Paul Durrant (11):
viridian: add in
Currently the time module lacks vcpu context save helpers and the synic
module lacks domain context save helpers. These helpers are not yet
required but subsequent patches will require at least some of them so this
patch completes the set to avoid introducing them in an ad-hoc way.
Signed-off-by:
This patch introduces an implementation of the SCONTROL, SVERSION, SIEFP,
SIMP, EOM and SINT0-15 SynIC MSRs. No message source is added and, as such,
nothing will yet generate a synthetic interrupt. A subsequent patch will
add an implementation of synthetic timers which will need the infrastructure
This patch simply adds domain and vcpu init/deinit hooks into the synic
and time modules and wires them into viridian_[domain|vcpu]_[init|deinit]().
Only one of the hooks is currently needed (to unmap the 'VP Assist' page)
but subsequent patches will make use of the others.
NOTE: To perform the un
Currently the viridian_domain and viridian_vcpu structures are inline in
the hvm_domain and hvm_vcpu structures respectively. Subsequent patches
will need to add sizable extra fields to the viridian structures which
will cause the PAGE_SIZE limit of the overall vcpu structure to be
exceeded. This p
This patch adds domain and vcpu init hooks for viridian features. The init
hooks do not yet do anything; the functionality will be added to by
subsequent patches.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
v5:
- Put the
This patch adds an implementation of the hypercall as documented in the
specification [1], section 10.5.2. This enlightenment, as with others, is
advertised by CPUID leaf 0x4004 and is under control of a new
'hcall_ipi' option in libxl.
If used, this enlightenment should mean the guest only ta
This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs
and hence a the first SynIC message source.
The new (and documented) 'stimer' viridian enlightenment group may be
specified to enable this feature.
While in the neighbourhood, this patch adds a missing check for an
attemp
flight 133756 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133756/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
132889
test-am
>>> On 14.03.19 at 11:14, wrote:
> You do know that mfn_add(mfn, -1) will DTRT?
It will, but imo it looks slightly odd in particular in e.g.
for ( ...; ...; mfn_add(mfn, -1) ), hence I didn't suggest it. But
I don't object either.
Jan
___
Xen-devel
Am Wed, 13 Mar 2019 03:18:39 -0600
schrieb "Jan Beulich" :
> The discontinuity is still there, and so far you've failed to explain
> why a discontinuity is what you want here.
In v12 you asked for some data about the ranges. With new data the ranges are:
2.20GHz 29khz
2.30GHz 105khz
2.40GHz 3524
Add new subcommand "get-hypervisor-config" to xl config to print the
hypervisor .config file.
To be able to reuse already existing decompressing code in libxenguest
xc_inflate_buffer() has to be moved to libxenguest.h.
Signed-off-by: Juergen Gross
---
V2:
- rename subcommand to get-hypervisor-
Add a sysctl interface for obtaining the .config file used to build
the hypervisor. The mechanism is inspired by the Linux kernel's one.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich (apart from XSM changes)
---
V2:
- bump sysctl interface version
- check pad to be zero (Wei Liu)
- only
Add "xl get-hypervisor-config" printing the .config used to build the
currently running hypervisor.
Juergen Gross (2):
xen: add interface for obtaining .config from hypervisor
tools: add new xl command get-hypervisor-config
.gitignore | 2 ++
docs/man/xl.1.pod.in
On 14/03/2019 11:47, Jan Beulich wrote:
On 14.03.19 at 11:14, wrote:
>> You do know that mfn_add(mfn, -1) will DTRT?
> It will, but imo it looks slightly odd in particular in e.g.
> for ( ...; ...; mfn_add(mfn, -1) ), hence I didn't suggest it. But
> I don't object either.
Well - in mathemat
On Thu, Mar 14, 2019 at 12:59:37PM +0100, Juergen Gross wrote:
> Add new subcommand "get-hypervisor-config" to xl config to print the
> hypervisor .config file.
>
> To be able to reuse already existing decompressing code in libxenguest
> xc_inflate_buffer() has to be moved to libxenguest.h.
>
>
On Thu, Mar 14, 2019 at 12:59:36PM +0100, Juergen Gross wrote:
> Add a sysctl interface for obtaining the .config file used to build
> the hypervisor. The mechanism is inspired by the Linux kernel's one.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Jan Beulich (apart from XSM changes)
Review
On 13/03/2019 08:02, Jan Beulich wrote:
On 13.03.19 at 08:54, wrote:
> On 13.03.19 at 06:02, wrote:
>>> On Tue, Mar 12, 2019 at 05:07:51PM -0700, Raj, Ashok wrote:
On Mon, Mar 11, 2019 at 03:57:35PM +0800, Chao Gao wrote:
> +if ( cpu == cpumask_first(per_cpu(cpu_sibling_mask
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-o
To control the runtime behavior on L1TF vulnerable platforms better, the
command line option l1tf-barrier is introduced. This option controls
whether on vulnerable x86 platforms the lfence instruction is used to
prevent speculative execution from bypassing the evaluation of
conditionals that are pr
Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
L1 cache is problematic, because when hyperthreading is used as well, a
guest running on the sibling core can leak this potentially secret data.
To prevent these speculative accesses, we block speculation after
accessing the
Checks of domain properties, such as is_hardware_domain or is_hvm_domain,
might be bypassed by speculatively executing these instructions. A reason
for bypassing these checks is that these macros access the domain
structure via a pointer, and check a certain field. Since this memory
access is slow,
When checking for being an hvm domain, or PV domain, we have to make
sure that speculation cannot bypass that check, and eventually access
data that should not end up in cache for the current domain type.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by:
Guests can issue grant table operations and provide guest controlled
data to them. This data is also used for memory loads. To avoid
speculative out-of-bound accesses, we use the array_index_nospec macro
where applicable. However, there are also memory accesses that cannot
be protected by a single
The params array in hvm can be accessed with get and set functions.
As the index is guest controlled, make sure no out-of-bound accesses
can be performed.
As we cannot influence how future compilers might modify the
instructions that enforce the bounds, we furthermore block speculation,
so that th
The get_page_from_gfn method returns a pointer to a page that belongs
to a gfn. Before returning the pointer, the gfn is checked for being
valid. Under speculation, these checks can be bypassed, so that
the function get_page is still executed partially. Consequently, the
function page_get_owner_and
When issuing a vcpu_op hypercall, guests have control over the
vcpuid variable. In the old code, this allowed to perform
speculative out-of-bound accesses. To block this, we make use
of the domain_vcpu function.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
On Wed, Mar 13, 2019 at 02:02:55AM -0600, Jan Beulich wrote:
On 13.03.19 at 08:54, wrote:
> On 13.03.19 at 06:02, wrote:
>>> On Tue, Mar 12, 2019 at 05:07:51PM -0700, Raj, Ashok wrote:
On Mon, Mar 11, 2019 at 03:57:35PM +0800, Chao Gao wrote:
> +if ( cpu == cpumask_first(per_
Currently the value is saved directly in struct hvm_vcpu. This patch simply
co-locates it with other saved MSR values. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Reviewed-by: Kevin Tian
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: Jun Nakajima
Saving and restoring the value of this MSR is currently handled by
implementation-specific code despite it being architectural. This patch
moves handling of accesses to this MSR from hvm.c into the msr.c, thus
allowing the common MSR save/restore code to handle it.
NOTE: Because vmx_get/set_guest_
Saving and restoring the value of this MSR is currently handled by
implementation-specific code despite it being architectural. This patch
moves handling of accesses to this MSR from hvm.c into the msr.c, thus
allowing the common MSR save/restore code to handle it.
This patch also adds proper chec
These hvm_funcs are no longer required since no MSR values are saved or
restored by implementation-specific code.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v2:
- Re-instate err check on loop in hvm_load_cpu_msrs()
---
xen/a
Paul Durrant (4):
x86: stop handling MSR_IA32_BNDCFGS save/restore in implementation
code
x86: move the saved value of MSR_IA32_XSS into struct vcpu_msrs
x86: stop handling MSR_IA32_XSS save/restore in implementation code
x86: remove defunct init/load/save_msr() hvm_funcs
xen/arch/x86
>>> On 14.03.19 at 14:01, wrote:
> On Wed, Mar 13, 2019 at 02:02:55AM -0600, Jan Beulich wrote:
> On 13.03.19 at 08:54, wrote:
>> On 13.03.19 at 06:02, wrote:
On Tue, Mar 12, 2019 at 05:07:51PM -0700, Raj, Ashok wrote:
>On Mon, Mar 11, 2019 at 03:57:35PM +0800, Chao Gao wrote:
>
>>> On 14.03.19 at 10:59, wrote:
> @@ -1892,8 +1891,7 @@ static void __init check_timer(void)
> vector = IRQ0_VECTOR;
> clear_irq_vector(0);
>
> -cpumask_setall(&mask_all);
> -if ((ret = bind_irq_vector(0, vector, &mask_all)))
> +if ((ret = bind_irq_vector(0, vector, &cpuma
From: Oleksandr Andrushchenko
Currently on driver resume we remove all the network queues and
destroy shared Tx/Rx rings leaving the driver in its current state
and never signaling the backend of this frontend's state change.
This leads to the number of consequences:
- when frontend withdraws gra
>>> On 14.03.19 at 13:50, wrote:
> Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
> L1 cache is problematic, because when hyperthreading is used as well, a
> guest running on the sibling core can leak this potentially secret data.
>
> To prevent these speculative accesse
>>> On 14.03.19 at 13:50, wrote:
> When issuing a vcpu_op hypercall, guests have control over the
> vcpuid variable. In the old code, this allowed to perform
> speculative out-of-bound accesses. To block this, we make use
> of the domain_vcpu function.
>
> This is part of the speculative hardenin
On 3/14/19 14:19, Jan Beulich wrote:
On 14.03.19 at 13:50, wrote:
>> Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
>> L1 cache is problematic, because when hyperthreading is used as well, a
>> guest running on the sibling core can leak this potentially secret data.
On 14/03/2019 14:12, Jan Beulich wrote:
On 14.03.19 at 10:59, wrote:
>> @@ -1892,8 +1891,7 @@ static void __init check_timer(void)
>> vector = IRQ0_VECTOR;
>> clear_irq_vector(0);
>>
>> -cpumask_setall(&mask_all);
>> -if ((ret = bind_irq_vector(0, vector, &mask_all)))
>> +
>>> On 14.03.19 at 10:37, wrote:
> Instead of having to edit include/xen/lib.h for making debugtrace
> available make it configurable via Kconfig.
>
> Default is off, it is available only in expert mode or in debug builds.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
>>> On 14.03.19 at 10:37, wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -1225,13 +1225,28 @@ void debugtrace_dump(void)
> watchdog_enable();
> }
>
> +static void debugtrace_add_to_buf(char *buf)
> +{
> +char *p;
> +
> +for ( p = buf; *p != '\0';
>>> On 14.03.19 at 14:01, wrote:
> @@ -1215,10 +1196,15 @@ static bool vmx_set_guest_bndcfgs(struct vcpu *v, u64
> val)
> return true;
> }
>
> -static bool vmx_get_guest_bndcfgs(struct vcpu *v, u64 *val)
> +static bool vmx_get_guest_bndcfgs(const struct vcpu *cv, u64 *val)
> {
> +str
On 14/03/2019 14:33, Jan Beulich wrote:
On 14.03.19 at 10:37, wrote:
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -1225,13 +1225,28 @@ void debugtrace_dump(void)
>> watchdog_enable();
>> }
>>
>> +static void debugtrace_add_to_buf(char *buf)
>> +{
>> +
On 14/03/2019 13:38, Juergen Gross wrote:
> On 14/03/2019 14:33, Jan Beulich wrote:
> On 14.03.19 at 10:37, wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -1225,13 +1225,28 @@ void debugtrace_dump(void)
>>> watchdog_enable();
>>> }
>>>
>>> +stat
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 14 March 2019 13:39
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu
> ; Jun Nakajima ; Kevin Tian
> ; xen-
> devel
> Subject: Re: [PATCH v3 1/4] x86: stop handling MSR_IA32_BNDCFGS save/rest
I am still confused about suspend/resume for the front drivers,
for instance, block front [1] does implement full/proper reconnect
on .resume, but net front only does this partially.
Could anyone please shed some light on suspend/resume design?
Thank you,
Oleksandr
On 3/14/19 3:17 PM, Oleksandr
Am Wed, 13 Mar 2019 03:18:39 -0600
schrieb "Jan Beulich" :
> I'm sorry, but I continue to object to this adjustment getting done
> both by default _and_ not in a per-guest manner. As said before,
> you can't demand guests to run NTP, and hence you can't expect
> them to get along with a few hundre
These hvm_funcs are no longer required since no MSR values are saved or
restored by implementation-specific code.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
v2:
- Re-instate err check on loop in hvm_load_cpu_msrs()
---
xen/a
Saving and restoring the value of this MSR is currently handled by
implementation-specific code despite it being architectural. This patch
moves handling of accesses to this MSR from hvm.c into the msr.c, thus
allowing the common MSR save/restore code to handle it.
This patch also adds proper chec
Saving and restoring the value of this MSR is currently handled by
implementation-specific code despite it being architectural. This patch
moves handling of accesses to this MSR from hvm.c into the msr.c, thus
allowing the common MSR save/restore code to handle it.
NOTE: Because vmx_get/set_guest_
*** BLURB HERE ***
Paul Durrant (4):
x86: stop handling MSR_IA32_BNDCFGS save/restore in implementation
code
x86: move the saved value of MSR_IA32_XSS into struct vcpu_msrs
x86: stop handling MSR_IA32_XSS save/restore in implementation code
x86: remove defunct init/load/save_msr() hvm_
Currently the value is saved directly in struct hvm_vcpu. This patch simply
co-locates it with other saved MSR values. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Reviewed-by: Kevin Tian
---
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: Jun Nakajima
> -Original Message-
> From: Jason Andryuk [mailto:jandr...@gmail.com]
> Sent: 13 March 2019 18:12
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org;
> marma...@invisiblethingslab.com; Stefano
> Stabellini ; Anthony Perard
> ; Paolo Bonzini
> ; Richard Hender
It is common that build hosts are isolated from outside world. They
don't necessarily have wget or ftp installed.
Turn the error into warning in configure. 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: We
On 14/03/2019 14:50, Olaf Hering wrote:
> Am Wed, 13 Mar 2019 03:18:39 -0600
> schrieb "Jan Beulich" :
>
>> I'm sorry, but I continue to object to this adjustment getting done
>> both by default _and_ not in a per-guest manner. As said before,
>> you can't demand guests to run NTP, and hence you c
>>> On 14.03.19 at 12:25, wrote:
> @@ -131,13 +238,69 @@ int viridian_synic_rdmsr(const struct vcpu *v, uint32_t
> idx, uint64_t *val)
> *val = ((uint64_t)icr2 << 32) | icr;
> break;
> }
> +
> case HV_X64_MSR_TPR:
> *val = vlapic_get_reg(vcpu_vlapic(v), APIC_T
Hi,
On 3/14/19 8:37 AM, Juergen Gross wrote:
On 12/03/2019 20:46, David Hildenbrand wrote:
On 12.03.19 19:23, David Hildenbrand wrote:
I guess something like this could do the trick if I understood it correctly:
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 39b229f9e256..d3
Am Thu, 14 Mar 2019 15:10:16 +0100
schrieb Juergen Gross :
> This would be the least intrusive change allowing maximum flexibility
> IMO.
I think earlier attempts did alter the tooling.
But that would not help with existing domUs started on hosts that do not have
that property.
A global knob wou
>>> On 14.03.19 at 14:40, wrote:
> On 14/03/2019 13:38, Juergen Gross wrote:
>> On 14/03/2019 14:33, Jan Beulich wrote:
>> On 14.03.19 at 10:37, wrote:
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1225,13 +1225,28 @@ void debugtrace_dump(void)
On 14.03.19 15:12, Julien Grall wrote:
> Hi,
>
> On 3/14/19 8:37 AM, Juergen Gross wrote:
>> On 12/03/2019 20:46, David Hildenbrand wrote:
>>> On 12.03.19 19:23, David Hildenbrand wrote:
>>>
>>> I guess something like this could do the trick if I understood it correctly:
>>>
>>> diff --git a/drive
On 14/03/2019 15:12, Julien Grall wrote:
> Hi,
>
> On 3/14/19 8:37 AM, Juergen Gross wrote:
>> On 12/03/2019 20:46, David Hildenbrand wrote:
>>> On 12.03.19 19:23, David Hildenbrand wrote:
>>>
>>> I guess something like this could do the trick if I understood it
>>> correctly:
>>>
>>> diff --git a
On 14.03.19 15:15, Juergen Gross wrote:
> On 14/03/2019 15:12, Julien Grall wrote:
>> Hi,
>>
>> On 3/14/19 8:37 AM, Juergen Gross wrote:
>>> On 12/03/2019 20:46, David Hildenbrand wrote:
On 12.03.19 19:23, David Hildenbrand wrote:
I guess something like this could do the trick if I u
>>> On 14.03.19 at 14:50, wrote:
> In staging the change would affect HVM and PVH. I never ran PVH,
> I have to assume it behaves like HVM in this regard.
And again you makie it look as if PV wasn't also going through that
same path. Yet all that's there at the top of the function is
if ( is
1 - 100 of 185 matches
Mail list logo
