>>> On 18.07.18 at 18:36, wrote:
> On 18/07/18 17:16, Jan Beulich wrote:
> On 18.07.18 at 18:05, wrote:
>>> On 18/07/18 15:48, Jan Beulich wrote:
>>> On 18.07.18 at 14:30, wrote:
> Backporting notes: This is safe in the restore case, but only back as far
> as
> the introduct
>>> On 18.07.18 at 19:20, wrote:
> It turns out that Xen has never enforced that a domain remain within the
> xstate features advertised in CPUID.
>
> The check of new_bv against xfeature_mask ensures that a domain stays within
> the set of features that Xen has enabled in hardware (and therefore
>>> On 18.07.18 at 19:20, wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -707,12 +707,27 @@ int handle_xsetbv(u32 index, u64 new_bv)
> if ( index != XCR_XFEATURE_ENABLED_MASK )
> return -EOPNOTSUPP;
>
> -if ( (new_bv & ~xcr0_max) ||
> - (new_bv
>>> On 18.07.18 at 23:38, wrote:
> On certain occasions platform might generate NMIs during kexec transition.
> It could be cascades of NMIs following the first one, escalated Master
> Aborts following IOMMU shutdown on the transition itself, etc.
> Purgatory code is now unprepared for any sort of
flight 125287 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125287/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 10 debian-install fail REGR. vs. 125169
Tests which did n
On 19/07/2018 08:10, Jan Beulich wrote:
>
>> @@ -694,18 +699,18 @@ int validate_xstate(u64 xcr0, u64 xcr0_accum, const
>> struct xsave_hdr *hdr)
>> int handle_xsetbv(u32 index, u64 new_bv)
>> {
>> struct vcpu *curr = current;
>> +const struct cpuid_policy *cp = curr->domain->arch.cpuid;
On Tue, Jul 17, 2018 at 02:38:06PM +0100, Paul Durrant wrote:
> This patch modifies the declaration of the entry points to the IOMMU
> sub-system to use bfn_t and mfn_t in place of unsigned long. A subsequent
> patch will similarly modify the methods in the iommu_ops structure.
>
> Signed-off-by:
On Tue, Jul 17, 2018 at 02:38:05PM +0100, Paul Durrant wrote:
> ...meaning 'bus frame number' i.e. a frame number mapped in the IOMMU
> rather than the MMU.
>
> This patch is a largely cosmetic change that substitutes the terms 'gfn'
> and 'gaddr' for 'bfn' and 'baddr' in all the places where the
On Tue, Jul 17, 2018 at 02:38:07PM +0100, Paul Durrant wrote:
> This patch modifies the methods in struct iommu_ops to use type-safe BFN
> and MFN. This follows on from the prior patch that modified the functions
> exported in xen/iommu.h.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
_
The xen_drm_front_gem_get_sg_table() function is supposed to return
error pointer. The current code, would trigger a NULL dereference in
drm_gem_map_dma_buf().
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/dr
On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
>
> >
> > On Jul 2, 2018, at 8:42 AM, Alexandru Isaila > om> wrote:
> >
> > From: Isaila Alexandru
> >
> > This patch adds access rights for the NPT pages. The access rights
> > are
> > saved in a radix tree with the root saved in p2m_dom
On 07/19/2018 11:18 AM, Isaila Alexandru wrote:
> On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
>>
>>>
>>> On Jul 2, 2018, at 8:42 AM, Alexandru Isaila >> om> wrote:
>>>
>>> From: Isaila Alexandru
>>>
>>> This patch adds access rights for the NPT pages. The access rights
>>> are
>>> saved
>>> On 19.07.18 at 09:59, wrote:
> On 19/07/2018 08:10, Jan Beulich wrote:
>>
>>> @@ -694,18 +699,18 @@ int validate_xstate(u64 xcr0, u64 xcr0_accum, const
>>> struct xsave_hdr *hdr)
>>> int handle_xsetbv(u32 index, u64 new_bv)
>>> {
>>> struct vcpu *curr = current;
>>> +const struct c
>>> On 19.07.18 at 01:48, wrote:
> On Wed, Jul 18, 2018 at 02:21:53AM -0600, Jan Beulich wrote:
>> Reportedly Intel CPUs which can't broadcast #MC to all targeted
>> cores/threads because some have CR4.MCE clear will shut down. Therefore
>> we want to keep CR4.MCE enabled when offlining a CPU, and
On 19/07/2018 09:21, Jan Beulich wrote:
On 19.07.18 at 09:59, wrote:
>> On 19/07/2018 08:10, Jan Beulich wrote:
@@ -694,18 +699,18 @@ int validate_xstate(u64 xcr0, u64 xcr0_accum, const
struct xsave_hdr *hdr)
int handle_xsetbv(u32 index, u64 new_bv)
{
struct v
>>> On 19.07.18 at 10:18, wrote:
> On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
>> > On Jul 2, 2018, at 8:42 AM, Alexandru Isaila > > @@ -112,8 +117,37 @@ static unsigned long p2m_type_to_flags(const
>> > struct p2m_domain *p2m,
>> > flags |= _PAGE_PWT;
>> > ASSER
>>> On 19.07.18 at 10:26, wrote:
> On 19/07/2018 09:21, Jan Beulich wrote:
> On 19.07.18 at 09:59, wrote:
>>> On 19/07/2018 08:10, Jan Beulich wrote:
> @@ -694,18 +699,18 @@ int validate_xstate(u64 xcr0, u64 xcr0_accum, const
> struct xsave_hdr *hdr)
> int handle_xsetbv(u32 index, u
On 07/19/2018 11:30 AM, Jan Beulich wrote:
On 19.07.18 at 10:18, wrote:
>> On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
On Jul 2, 2018, at 8:42 AM, Alexandru Isaila >>> +break;
+case p2m_access_x:
+flags &= ~_PAGE_RW;
+
flight 74988 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74988/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 74961
jobs:
build-amd64 pass
build-armh
On 19/07/2018 09:34, Jan Beulich wrote:
On 19.07.18 at 10:26, wrote:
>> On 19/07/2018 09:21, Jan Beulich wrote:
>> On 19.07.18 at 09:59, wrote:
On 19/07/2018 08:10, Jan Beulich wrote:
>> @@ -694,18 +699,18 @@ int validate_xstate(u64 xcr0, u64 xcr0_accum,
>> const
>> struct
On Tue, Jul 17, 2018 at 02:38:10PM +0100, Paul Durrant wrote:
> Ranges that should be considered reserved in the IOMMU are not necessarily
> limited to RMRRs. If iommu_inclusive_mapping is set then any frame number
> falling within an E820 reserved region should also be considered as
> reserved in
Hi, Dan!
Thank you for the patch and sorry I was clumsy sending v3.
Do you want me to send v3 now with the fixes for both Xen and CMA?
Thank you,
Oleksandr
On 07/19/2018 11:11 AM, Dan Carpenter wrote:
The xen_drm_front_gem_get_sg_table() function is supposed to return
error pointer. The cu
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced
Does anybody see any reasons why this should get into mmotm tree?
I do not want to rush this in but if general feeling is to push it for
the upcoming merge window then I will not object.
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lis
Hi Stefano,
On 18/07/18 18:10, Stefano Stabellini wrote:
On Tue, 17 Jul 2018, Julien Grall wrote:
Hi Stefano,
On 17/07/2018 21:05, Stefano Stabellini wrote:
On Mon, 9 Jul 2018, Julien Grall wrote:
Hi,
On 07/07/18 00:11, Stefano Stabellini wrote:
Introduce an is_console option to allow cert
On Thu, Jul 19, 2018 at 12:06:38PM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dan!
>
> Thank you for the patch and sorry I was clumsy sending v3.
>
> Do you want me to send v3 now with the fixes for both Xen and CMA?
>
> Thank you,
Sorry, I forgot that you had sent these earlier. After a whil
Oleksandr sent this patch already. Please disregard mine.
regards,
dan carpenter
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 07/19/2018 12:20 PM, Dan Carpenter wrote:
On Thu, Jul 19, 2018 at 12:06:38PM +0300, Oleksandr Andrushchenko wrote:
Hi, Dan!
Thank you for the patch and sorry I was clumsy sending v3.
Do you want me to send v3 now with the fixes for both Xen and CMA?
Thank you,
Sorry, I forgot that you had
From: Oleksandr Andrushchenko
Dan Carpenter has reported that there is the following static checker
warning:
drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
warn: 'sgt' can also be NULL
314 sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
315
316 if (!IS_ERR(sgt
On Tue, Jul 17, 2018 at 02:38:11PM +0100, Paul Durrant wrote:
[...]
> int compat_one_iommu_op(compat_iommu_op_buf_t *buf)
> {
> -compat_iommu_op_t cmp;
> +compat_iommu_op_t cmp = {};
> +size_t offset;
> +static const size_t op_size[] = {
> +[XEN_IOMMUOP_query_reserved] = s
On Tue, Jul 17, 2018 at 02:38:12PM +0100, Paul Durrant wrote:
> This patch adds a new method to the VT-d IOMMU implementation to find the
> MFN currently mapped by the specified BFN along with a wrapper function in
> generic IOMMU code to call the implementation if it exists.
>
> This functionalit
flight 125292 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125292/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 125253 REGR. vs.
124248
test-amd64-
>>> On 19.07.18 at 10:43, wrote:
> On 07/19/2018 11:30 AM, Jan Beulich wrote:
> On 19.07.18 at 10:18, wrote:
>>> On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
> On Jul 2, 2018, at 8:42 AM, Alexandru Isaila +break;
> +case p2m_access_x:
> +
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 19 July 2018 10:37
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org) ; Wei Liu
>
>>> On 19.07.18 at 10:59, wrote:
> On 19/07/2018 09:34, Jan Beulich wrote:
> On 19.07.18 at 10:26, wrote:
>>> On 19/07/2018 09:21, Jan Beulich wrote:
>>> On 19.07.18 at 09:59, wrote:
> On 19/07/2018 08:10, Jan Beulich wrote:
>>> @@ -694,18 +699,18 @@ int validate_xstate(u64 xcr0,
Reviewed-by: Dan Carpenter
regards,
dan carpenter
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
I've been considering to add a respective command line option for
quite a long time, but never got around to. Now that the TLBleed
information is public[1], we're at a point where we not only want,
but need this, and where perhaps it needs to be the default on
affected systems. The first 2 patches
On 07/19/2018 01:24 PM, Dan Carpenter wrote:
Reviewed-by: Dan Carpenter
Thank you,
if nobody objects I'll push it to drm-misc-next next Monday
regards,
dan carpenter
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproje
flight 125412 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125412/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
In order to be able to service #MC on offlined CPUs, the GDT, IDT,
stack, and per-CPU data (which includes the TSS) need to be kept
allocated. They should only be freed upon CPU removal (which we
currently don't support, so some code is becoming effectively dead for
the moment).
Note that for now
Reportedly Intel CPUs which can't broadcast #MC to all targeted
cores/threads because some have CR4.MCE clear will shut down. Therefore
we want to keep CR4.MCE enabled when offlining a CPU, and we need to
bring up all CPUs in order to be able to set CR4.MCE in the first place.
The use of clear_in_
Shared resources (L1 cache and TLB in particular) present a risk of
information leak via side channels. Provide a means to avoid use of
hyperthreads in such cases.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v3: Also change the actual option string to "smt". Don't default the
Drop unnecessary casts and use bool in favor of bool_t.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Roger Pau Monné
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -345,9 +345,9 @@ static inline int cpulist_scnprintf(char
typed
On 19/07/18 11:32, Jan Beulich wrote:
> Shared resources (L1 cache and TLB in particular) present a risk of
> information leak via side channels. Provide a means to avoid use of
> hyperthreads in such cases.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Roger Pau Monné
Reviewed-by: Andrew Coope
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far use of CPU
registers goes (as those can't change without any other instruction
executing in between), b
If panic is called before init_idle_domain on a tboot-launched system,
then Xen recursively faults in write_ptbase as seen below.
(XEN)[] write_ptbase+0/0x10
(XEN)[] tboot_shutdown+0x6b/0x260
(XEN)[] machine_restart+0xac/0x2d0
(XEN)[] write_ptbase+0/0x10
(XEN)[] panic+0x111/0x1
>>> On 19.07.18 at 12:37, wrote:
> On 19/07/18 11:32, Jan Beulich wrote:
>> Shared resources (L1 cache and TLB in particular) present a risk of
>> information leak via side channels. Provide a means to avoid use of
>> hyperthreads in such cases.
>>
>> Signed-off-by: Jan Beulich
>> Reviewed-by: Ro
The caching isn't actually implemented here, this is just setting the
stage.
Touching these anyway also
- make their return values gfn_t
- gva -> gla in their names
- name their input arguments gla
At the use sites do the conversion to gfn_t as suitable.
Signed-off-by: Jan Beulich
--- a/xen/ar
The caching isn't actually implemented here, this is just setting the
stage.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2572,6 +2572,18 @@ void hvm_dump_emulation_state(const char
hvmemul_ctxt->insn_buf);
}
+bool hvmemul_read_c
Checking the low 5 bits of CR3 is not the job of vmx_load_pdptrs().
Instead it should #GP upon bad PDPTE values, rather than causing a VM
entry failure.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1361,20 +1361,18 @@ static void vmx_set_interr
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far use of CPU
registers goes (as those can't change without any other instruction
executing in between), b
Since strictly speaking it is incorrect for guest_walk_tables() to read
L3 entries during PAE page walks, try to overcome this where possible by
pre-loading the values from hardware into the cache. Sadly the
information is available in the EPT case only. On the positive side for
NPT the spec spells
Correct indentation of a piece of code, adjusting comment style at the
same time. Constify gl3e pointers and drop a bogus (and useless once
corrected) cast.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3989,9 +3989,8 @@ sh_update_cr3(st
>>> On 19.07.18 at 12:39, wrote:
> If panic is called before init_idle_domain on a tboot-launched system,
> then Xen recursively faults in write_ptbase as seen below.
>
> (XEN)[] write_ptbase+0/0x10
> (XEN)[] tboot_shutdown+0x6b/0x260
> (XEN)[] machine_restart+0xac/0x2d0
> (XEN)[]
On 07/19/2018 11:32 AM, Jan Beulich wrote:
> Note: On one of my test systems the parked CPUs get _PSD data reported
> by Dom0 that is different from the non-parked ones (coord_type is
> 0xFC instead of 0xFE). Giving Dom0 enough vCPU-s eliminates this
> problem, so there is apparen
On 19/07/18 11:50, Jan Beulich wrote:
> Since strictly speaking it is incorrect for guest_walk_tables() to read
> L3 entries during PAE page walks, try to overcome this where possible by
> pre-loading the values from hardware into the cache. Sadly the
> information is available in the EPT case only
If xcr0_max exceeds xfeature_mask, then something is broken with the CPUID
policy derivation or auditing logic. If hardware rejects new_bv, then
something is broken with Xen's xstate logic.
In both cases, crash the domain with an obvious error message, to help
highlight the issues.
Signed-off-by
Andrew Cooper (2):
x86/xstate: Use a guests CPUID policy, rather than allowing all features
x86/xstate: Make errors in xstate calculations more obvious by crashing the
domain
xen/arch/x86/domctl.c| 2 +-
xen/arch/x86/hvm/hvm.c | 2 +-
xen/arch/x86/xstate.c| 37 +++
It turns out that Xen has never enforced that a domain remain within the
xstate features advertised in CPUID.
The check of new_bv against xfeature_mask ensures that a domain stays within
the set of features that Xen has enabled in hardware (and therefore isn't a
security problem), but this does me
>>> On 19.07.18 at 13:16, wrote:
> On 07/19/2018 11:32 AM, Jan Beulich wrote:
>> Note: On one of my test systems the parked CPUs get _PSD data reported
>> by Dom0 that is different from the non-parked ones (coord_type is
>> 0xFC instead of 0xFE). Giving Dom0 enough vCPU-s eliminates th
>>> On 19.07.18 at 13:15, wrote:
> On 19/07/18 11:50, Jan Beulich wrote:
>> Since strictly speaking it is incorrect for guest_walk_tables() to read
>> L3 entries during PAE page walks, try to overcome this where possible by
>> pre-loading the values from hardware into the cache. Sadly the
>> infor
On 19/07/18 12:47, Jan Beulich wrote:
On 19.07.18 at 13:15, wrote:
>> On 19/07/18 11:50, Jan Beulich wrote:
>>> Since strictly speaking it is incorrect for guest_walk_tables() to read
>>> L3 entries during PAE page walks, try to overcome this where possible by
>>> pre-loading the values from
flight 125407 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125407/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
flight 125300 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125300/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
On Jo, 2018-07-19 at 04:02 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 19.07.18 at 10:43, wrote:
> > On 07/19/2018 11:30 AM, Jan Beulich wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > > On 19.07.18 at 10:18, wrote:
> > > > On Mi, 2018-07-18 at 15:33 +, George Dunlap wr
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 July 2018 11:46
> To: xen-devel
> Cc: Razvan Cojocaru ; Andrew Cooper
> ; Paul Durrant ;
> George Dunlap ; ta...@tklengyel.com; Tim
> (Xen.org)
> Subject: [PATCH 1/6] x86/mm: add optional cache to GLA->GFN tran
flight 125421 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125421/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 July 2018 11:47
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; George Dunlap
> Subject: [PATCH 2/6] x86/mm: use optional cache in guest_walk_tables()
>
> The caching isn't actually implemented here, th
branch xen-unstable
xenbranch xen-unstable
job build-i386
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced pro
On a VM with only 1 vCPU, the locking fast paths will always be
successful. In this case, there is no need to use the the PV qspinlock
code which has higher overhead on the unlock side than the native
qspinlock code.
Signed-off-by: Waiman Long
---
arch/x86/xen/spinlock.c | 3 ++-
1 file changed,
Signed-off-by: Alexandru Isaila
---
Changes since V8:
- Add comment for the handler return values.
---
xen/arch/x86/cpu/mcheck/vmce.c | 1 +
xen/arch/x86/hvm/hpet.c| 2 +-
xen/arch/x86/hvm/hvm.c | 6 +-
xen/arch/x86/hvm/i8254.c | 2 +-
xen/arch/x86/hvm/irq.c
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
Changes since V12:
- Remove blank line
- Apply coding style to for_each.
---
xen/arch/x86/hvm/viridian.c | 30 +++---
1 file changed, 19 inser
Hi all,
This patch series addresses the ideea of saving data from a single vcpu
instance.
First it starts by adding *save_one functions, then it introduces a handler for
the
new save_one* funcs and makes use of it in the hvm_save and hvm_save_one funcs.
The final 2 patches are used for clean up.
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- hvm_save_cpu_xsave_states_one() returns the err from
_hvm_init_entry().
- hvm_save_cpu_xsave_states() returns err from
hvm_save_cpu_xsave_states_one();
-
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/cpu/mcheck/vmce.c | 1 -
xen/arch/x86/hvm/hpet.c| 2 +-
xen/arch/x86/hvm/hvm.c | 5 +
xen/arch/x86/hvm/i8254.c | 2 +-
xen/arch/x86/hvm/irq.c | 6 +++---
xen/arch/x86/hvm/mtrr.c| 2 +-
xen/arch/x86/hv
This patch is focused on moving the for loop to the caller so
now we can save info for a single vcpu instance with the save_one
handlers.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- Changed the CONTINUE return to return 0.
---
xen/arch/x86/hvm/hvm.c | 19 ---
xen/arch
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V9:
- Change return of the save_one func to return hvm_save_entry.
---
xen/arch/x86/hvm/hvm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x
This patch removes the redundant save functions and renames the
save_one* to save. It then changes the domain param to vcpu in the
save funcs.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- Remove enum return type for save funcs.
---
xen/arch/x86/cpu/mcheck/vmce.c | 19 ++-
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V12:
- Changed memset to {} init.
---
xen/arch/x86/hvm/hvm.c | 214 +
1 file changed, 111 insertions(+), 103 deletions(-)
diff --git a/xen
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
Reviewed-by: Paul Durrant
---
Changes since V11:
- hvm_save_cpu_msrs() returns err from hvm_save_cpu_msrs_one().
---
xen/arch/x86/hvm/hvm.c | 105 +++--
1 file
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since v11:
- hvm_save_mtrr_msr() now returns err from hvm_save_mtrr_msr_one().
Note: This patch is based on Roger Pau Monne's series[1]
---
xen/arch/x86/hvm/mtrr.c | 81 +++
This is used to save data from a single instance.
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- Removed the memset and added init with {}.
---
xen/arch/x86/cpu/mcheck/vmce.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x8
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 July 2018 11:49
> To: xen-devel
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew Cooper
> ; Paul Durrant ;
> George Dunlap ; Jun Nakajima
> ; Kevin Tian ; Boris
> Ostrovsky ; Tim (Xen.org)
> Subject: [PATCH
Fix the command to use shell syntax for environment variables.
Make it more explicite that the command `make` is going to modifie the
current directory.
Also include an example of what a container is.
Signed-off-by: Anthony PERARD
---
I'm attempted to change the short options by their long eq
On Thu, Jul 19, 2018 at 03:30:52PM +0100, Anthony PERARD wrote:
> Fix the command to use shell syntax for environment variables.
>
> Make it more explicite that the command `make` is going to modifie the
typo: explicit and modify.
> current directory.
>
> Also include an example of what a conta
On Thu, Jul 19, 2018 at 2:30 AM Jan Beulich wrote:
>
> >>> On 19.07.18 at 10:18, wrote:
> > On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
> >> > On Jul 2, 2018, at 8:42 AM, Alexandru Isaila >> > @@ -112,8 +117,37 @@ static unsigned long p2m_type_to_flags(const
> >> > struct p2m_domain *
flight 125426 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125426/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
On 12/07/18 11:24, Lars Kurth wrote:
>
>
> On 06/07/2018, 17:42, "Lars Kurth" wrote:
>
> Hi all, (I also moved the AB to BCC)
>
> I summarized the discussion in
> https://docs.google.com/document/d/1W7OuISUau-FtPG6tIinD4GXYFb-hKDjaqTj84pogNrA/edit?usp=sharing
>
>
> I m
flight 125432 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125432/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Thu, 19 Jul 2018, Jan Beulich wrote:
> > Signed-off-by: Christopher Clark
> > ---
> > Please use my gmail address for any correspondence to me.
>
> I think it is generally considered bad practice to have From: and S-o-b
> differ.
Why? That is perfectly fine. Signed-off-by is about copyright o
On Thu, 19 Jul 2018, Jan Beulich wrote:
> >>> On 18.07.18 at 18:59, wrote:
> > On 18/07/18 08:12, Jan Beulich wrote:
> > On 17.07.18 at 22:29, wrote:
> >>> On 07/07/2018 00:12, Stefano Stabellini wrote:
> Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
> mechanism
-usbdevice is deprecated as of QEMU 2.10.
This patch replace the few options documented in xl.cfg(5) by the
recommanded syntax. And if the option isn't recognize, simply use
-usbdevice with a warning, the options isn't entirely removed from QEMU
upstream.
Also, remove from the manual the sentence
flight 125434 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125434/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 125295
build-amd64
On 19/07/2018, 08:40, "Juergen Gross" wrote:
> **ACTION: George will put together a survey for the committers outlining
the issue and
> trade-offs and then go from there**
>
Ping? Anything new? I'd like to know the dates for 4.12...
Adding George: He was doing the
>>> Stefano Stabellini 07/19/18 7:00 PM >>>
>On Thu, 19 Jul 2018, Jan Beulich wrote:
>> > Signed-off-by: Christopher Clark
>> > ---
>> > Please use my gmail address for any correspondence to me.
>>
>> I think it is generally considered bad practice to have From: and S-o-b
>> differ.
>
>Why? Tha
>>> Andrew Cooper 07/19/18 1:55 PM >>>
>On 19/07/18 12:47, Jan Beulich wrote:
> On 19.07.18 at 13:15, wrote:
>>> On 19/07/18 11:50, Jan Beulich wrote:
Since strictly speaking it is incorrect for guest_walk_tables() to read
L3 entries during PAE page walks, try to overcome this where
>>> Tamas K Lengyel 07/19/18 5:09 PM >>>
>On Thu, Jul 19, 2018 at 2:30 AM Jan Beulich wrote:
> >>> On 19.07.18 at 10:18, wrote:
> > On Mi, 2018-07-18 at 15:33 +, George Dunlap wrote:
> >> > On Jul 2, 2018, at 8:42 AM, Alexandru Isaila > >> > +break;
>> >> > +case p2m_acce
flight 125304 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125304/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
test-armhf-armhf-xl-
On 19/07/18 19:37, Jan Beulich wrote:
Andrew Cooper 07/19/18 1:55 PM >>>
>> On 19/07/18 12:47, Jan Beulich wrote:
>> On 19.07.18 at 13:15, wrote:
On 19/07/18 11:50, Jan Beulich wrote:
> Since strictly speaking it is incorrect for guest_walk_tables() to read
> L3 entries duri
>>> Andrew Cooper 07/19/18 1:46 PM >>>
>Andrew Cooper (2):
>x86/xstate: Use a guests CPUID policy, rather than allowing all features
>x86/xstate: Make errors in xstate calculations more obvious by crashing the
>domain
Reviewed-by: Jan Beulich
___
X
1 - 100 of 126 matches
Mail list logo
