Hi Juergen,
After an extensive testing of your jgross1/sched-v3 branch in XenRT,
I'm happy to say that we've found no functional regressions so far
when running in the default (thread/cpu) mode.
Hopefully this gives some level of confidence to this series and the
plan about including it into 4.13
emory()
during a XENMEM_decrease_reservation request.
Signed-off-by: Sergey Dyasli
---
CC: Andrew Cooper
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/common/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 7364f
for xen_swiotlb_fixup() to track the number
of pages that were made contiguous in MFN space and use the same bootmem
region while halving the memory requirements.
Signed-off-by: Sergey Dyasli
---
CC: Konrad Rzeszutek Wilk
CC: Boris Ostrovsky
CC: Juergen Gross
CC: Stefano Stabellini
CC: Paul Durr
;
in Xen's cmdline manually.
Fix the issue by initialising dma_bitsize even on single NUMA machines.
Signed-off-by: Sergey Dyasli
---
CC: Andrew Cooper
CC: Jan Beulich
CC: Julien Grall
CC: Wei Liu
CC: Boris Ostrovsky
CC: George Dunlap
CC: Roger Pau Monné
---
xen/common/page_alloc.c
On 07/01/2019 12:05, Jan Beulich wrote:
On 07.01.19 at 12:27, wrote:
>> Currently dma_bitsize is zero by default on single NUMA node machines.
>> This makes all alloc_domheap_pages() calls with MEMF_no_dma return NULL.
>>
>> There is only 1 user of MEMF_no_dma: dom0_memflags, which are used
>
;
in Xen's cmdline manually.
Fix the issue by ignoring MEMF_no_dma in cases when dma_bitsize is zero,
which means there is no DMA zone. This shouldn't cause any issues for
Dom0 because alloc_heap_pages() will first use higher memory addresses
for satisfying memory allocation requests.
S
Hi Juergen,
The latest round of testing revealed the following 3 Xen crashes:
1. vcpu_sleep_sync() <-- vlapic_init_sipi_action()
This was seen multiple times. It tends to happen on large Windows Server
VMs (>= 12 vCPUs).
https://paste.debian.net/1095844/
2. vcpu_sleep_sync() <-- vcpu_set_periodi
On 19/08/2019 02:25, Chao Gao wrote:
> This patch ports microcode improvement patches from linux kernel.
>
> Before you read any further: the early loading method is still the
> preferred one and you should always do that. The following patch is
> improving the late loading mechanism for long runn
Hi Chao,
On 19/08/2019 02:25, Chao Gao wrote:
> Previous change log:
> Changes in version 8:
> - block #NMI handling during microcode loading (Patch 16)
> - Don't assume that all CPUs in the system have loaded a same ucode.
> So when parsing a blob, we attempt to save a patch as long as it matc
On 19/08/2019 02:25, Chao Gao wrote:
> register an nmi callback. And this callback does busy-loop on threads
> which are waiting for loading completion. Control threads send NMI to
> slave threads to prevent NMI acceptance during ucode loading.
>
> Signed-off-by: Chao Gao
> ---
> Changes in v9:
>
On 27/08/2019 05:52, Chao Gao wrote:
> On Mon, Aug 26, 2019 at 04:07:59PM +0800, Chao Gao wrote:
>> On Fri, Aug 23, 2019 at 09:46:37AM +0100, Sergey Dyasli wrote:
>>> On 19/08/2019 02:25, Chao Gao wrote:
>>>> register an nmi callback. And this callback does busy-
On 11/03/2019 07:57, Chao Gao wrote:
> to replace the current per-cpu cache 'uci->mc'.
>
> Compared to the current per-cpu cache, the benefits of the global
> microcode cache are:
> 1. It reduces the work that need to be done on each CPU. Parsing ucode
> file is done once on one CPU. Other CPUs ne
On 11/03/2019 07:57, Chao Gao wrote:
> Updating microcode is less error prone when caches have been flushed and
> depending on what exactly the microcode is updating. For example, some
> of the issues around certain Broadwell parts can be addressed by doing a
> full cache flush.
>
> [linux commit:
Hi Chao,
Updating microcode in parallel by default should be fine, but I think
there are no guarantees that a parallel application will be fine for
all future microcodes. To retain the ability to update microcode on cores
sequentially and give some choice to a user, I developed the below patch.
C
On 11/03/2019 07:57, Chao Gao wrote:
> This patch provides a tool for late microcode update.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> Signed-off-by: Chao Gao
> ---
> tools/libxc/include/xenctrl.h | 1 +
> tools/libxc/xc_misc.c | 20 ++
> tools/misc/Makefile | 4 ++
retpoline_safe() functions.
Fix this by getting ucode revision early during boot and SMP bring up.
While at it, protect early_microcode_update_cpu() for cases when
microcode_ops is NULL.
Signed-off-by: Sergey Dyasli
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
CC
On 25/03/2019 17:08, Jan Beulich wrote:
On 25.03.19 at 12:12, wrote:
>> Currently cpu_sig struct is not updated during boot when either:
>>
>> 1. ucode_scan is set to false (e.g. no "ucode=scan" in cmdline)
>> 2. initrd does not contain a microcode blob
>
> What about "ucode="?
Yes,
Hello,
Trying to build a simple version of XSA-304 Live-Patch for 4.13 gives
the following error during LP upload:
(XEN) livepatch: lp: Unknown symbol: .LC7
Bisecting identified the first bad commit as:
commit 854a7ca60e35 "create-diff-object: Do not include all .rodata
sections"
Base
On 18/11/2019 16:47, Wieczorkiewicz, Pawel wrote:
>
>
>> On 18. Nov 2019, at 17:42, Sergey Dyasli wrote:
>>
>> Hello,
>>
>> Trying to build a simple version of XSA-304 Live-Patch for 4.13 gives
>> the following error during LP upload:
>>
On 19/11/2019 17:21, Wieczorkiewicz, Pawel wrote:
>
>
>> On 18. Nov 2019, at 18:41, Sergey Dyasli wrote:
>>
>> On 18/11/2019 17:28, Wieczorkiewicz, Pawel wrote:
>>>
>>> Could you build the lp with debug (-d) and provide me with the
>>> creat
uires ignoring -ENODATA in AMD-side code, otherwise
the message given to user is:
(XEN) Parsing microcode blob error -61
Which actually means that a ucode blob was parsed fine, but no matching
ucode was found.
Signed-off-by: Sergey Dyasli
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Roger Pau
the provided blob. This also requires ignoring -ENODATA in
AMD-side code, otherwise the message given to the user is:
(XEN) Parsing microcode blob error -61
Which actually means that a ucode blob was parsed fine, but no matching
ucode was found.
Signed-off-by: Sergey Dyasli
---
v1 -->
be found in the provided blob. This also requires ignoring
-ENODATA in AMD-side code, otherwise the message given to the user is:
(XEN) Parsing microcode blob error -61
Which actually means that a ucode blob was parsed fine, but no matching
ucode was found.
Signed-off-by: Sergey Dyasli
be found in the provided blob. This also requires ignoring
-ENODATA in AMD-side code, otherwise the message given to the user is:
(XEN) Parsing microcode blob error -61
Which actually means that a ucode blob was parsed fine, but no matching
ucode was found.
Signed-off-by: Sergey Dyasli
On 27/11/2019 10:04, Sergey Dyasli wrote:
> Currently if a user tries to live-load the same or older ucode revision
> than CPU already has, he will get a single message in Xen log like:
>
> (XEN) 128 cores are to update their microcode
>
> No actual ucode loading wi
On 27/11/2019 03:10, Chao Gao wrote:
> On Tue, Nov 26, 2019 at 03:41:53PM +0000, Sergey Dyasli wrote:
>> Currently if a user tries to live-load the same or older ucode revision
>> than CPU already has, he will get a single message in Xen log like:
>>
>>(XEN) 12
On 26/11/2019 18:37, Wieczorkiewicz, Pawel wrote:
> It looks like gcc plays the usual dirty tricks with local variables renaming:
>
> - xen-syms
> 7529: 82d0805fed50 8 OBJECT LOCAL DEFAULT 4230 lastpage.22857
> - livepatch
>289: 8 OBJECT GLOBAL DEFAULT UND
>
On 27/11/2019 15:22, Wieczorkiewicz, Pawel wrote:
>
>
>> On 27. Nov 2019, at 12:16, Sergey Dyasli wrote:
>>
>> On 26/11/2019 18:37, Wieczorkiewicz, Pawel wrote:
>>> It looks like gcc plays the usual dirty tricks with local variables
>>> renaming:
>
On 27/11/2019 18:17, Andrew Cooper wrote:
> On 21/11/2019 08:34, Jan Beulich wrote:
>> On 20.11.2019 18:13, Andrew Cooper wrote:
>>> On 20/11/2019 16:40, Jürgen Groß wrote:
On 20.11.19 17:30, Jan Beulich wrote:
> On 08.11.2019 12:18, Jan Beulich wrote:
>> The .file assembler directives
>
> With this change, I've built and successfully applied a trivial
> livepatch with Jan's patch applied and ENFORCE_UNIQUE_SYMBOLS turned on.
Can confirm the same with my test LP. So
Tested-by: Sergey Dyasli
can go to both this and Jan's patch I guess.
--
Thanks
us, in order to decide if string section should be
> included or not, all symbols must be evaluated first.
>
> Signed-off-by: Pawel Wieczorkiewicz
> Reported-by: Sergey Dyasli
Tested-by: Sergey Dyasli
This fixes creation/loading of my
From: Ross Lagerwall
Otherwise it produces lots of false positives.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
---
drivers/xen/grant-table.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index
This enables to use Outline instrumentation for Xen PV kernels.
KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
and hence disabled.
Rough edges in the patch are marked with XXX.
Signed-off-by: Sergey Dyasli
---
arch/x86/mm/init.c | 14 ++
arch/x86/mm
-3 are independent and quite self-contained.
Sergey Dyasli (1):
x86/xen: add basic KASAN support for PV kernel
Ross Lagerwall (2):
xen: teach KASAN about grant tables
xen/netback: Fix grant copy across page boundary with KASAN
arch/x86/mm/init.c| 14
arch/x86/mm
From: Ross Lagerwall
When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
allocations are aligned to the next power of 2 of the size does not
hold. Therefore, handle grant copies that cross page boundaries.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
h would be shown in tools like dmidecode.
But allow guests to see this information in Debug builds of Xen.
Signed-off-by: Sergey Dyasli
---
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Julien Grall
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Wei Liu
CC:
On 18/12/2019 11:06, Jan Beulich wrote:
> On 17.12.2019 16:46, Sergey Dyasli wrote:
>> Hide the following information that can help identify the running Xen
>> binary version:
>>
>> XENVER_extraversion
>> XENVER_compile_info
>> XENVER_capabiliti
Hi Juergen,
We recently did another quick test of core scheduling mode, and the following
failures were found:
1. live-patch apply failures:
(XEN) [ 1058.751974] livepatch: lp_1_1: Timed out on semaphore in CPU
quiesce phase 30/31
(XEN) [ 1058.751982] livepatch: lp_1_1 finished REPLACE
On 18/12/2019 09:24, Jürgen Groß wrote:
> On 17.12.19 15:08, Sergey Dyasli wrote:
>> This enables to use Outline instrumentation for Xen PV kernels.
>>
>> KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
>> and hence disabled.
>>
>> Rough
On 17/12/2019 18:06, Boris Ostrovsky wrote:
>
>
>> On Dec 17, 2019, at 9:08 AM, Sergey Dyasli wrote:
>>
>> This series allows to boot and run Xen PV kernels (Dom0 and DomU) with
>> CONFIG_KASAN=y. It has been used internally for some time now with good
>> r
Hi Juergen,
Looks like we've hit the first Xen crash with core scheduling patches applied.
The log is below. From my analysis it seems that CSCHED_PCPU is NULL.
I suspect this is connected to commit bb128adb
("sched: populate cpupool0 only after all cpus are up")
Could you take a look, please
Hello,
While testing pv-shim from a snapshot of staging 4.13 branch (with core-
scheduling patches applied), some sort of scheduling issues were uncovered
which usually leads to a guest lockup (sometimes with soft lockup messages
from Linux kernel).
This happens more frequently on SandyBridge CPU
After printing some debug information I see that:
SMP alternatives: switching to SMP code
(XEN) [1.473056] == d1v1 master_cpu 0, lock 83018e315ec8
(XEN) [1.473120] sched_null.c:344: 1 <-- d1v1
(XEN) [1.473165] == d1v1 master_cpu 1, lock 8301899c2f48
(XEN) [1.473223] Asserti
On 22/10/2019 10:27, Jürgen Groß wrote:
> And now a more sane patch to try.
>
The patch definitely fixes the issue for Null scheduler at least:
Tested-by: Sergey Dyasli
It's still a bit unnerving to have places where sched_set_res() is called
without unit_schedule_lock(),
the region type change for pv-shim mode.
Signed-off-by: Sergey Dyasli
---
The condition can be relaxed to be just !pvh_boot if there are no
plans to support VGA MMIO / ROMs for PVH guests.
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
CC: Juergen Gross
---
xen
On 28/10/2019 09:06, Jan Beulich wrote:
> On 28.10.2019 09:56, Sergey Dyasli wrote:
>> Converting a guest from PV to PV-in-PVH makes the guest to have 384k
>> less memory, which may confuse guest's balloon driver. This happens
>> because Xen unconditionally reserve
On 28/10/2019 11:33, Andrew Cooper wrote:
> On 28/10/2019 11:30, Jan Beulich wrote:
>> On 28.10.2019 12:15, Andrew Cooper wrote:
>>> On 28/10/2019 11:11, Jan Beulich wrote:
>>>> On 28.10.2019 12:08, Sergey Dyasli wrote:
>>>>> On 28/10/2019 09:06,
On 29/10/2019 10:19, Andrew Cooper wrote:
> On 29/10/2019 10:17, Sergey Dyasli wrote:
>> On 28/10/2019 11:33, Andrew Cooper wrote:
>>> For now, how about cpu_has_hypervisor ?
>>>
>>> Whatever the virtual environment, we should trust the provided memory map.
&g
On 28/10/2019 17:30, Stonehouse, Robert wrote:
> This is a heads-up as I have observed that the following commit (backported
> onto an Amazon 4.11 tree) causes kexec (and hence kdump) to fail.
>
> commit c719519a4183d0630121f6abeba420f49dbc3229
> Author: Jan Beulich
> AuthorDate: Fri Ju
Move early_cpu_init() to be near the top of __start_xen(). Since there
is no serial / vga output at that stage, introduce a new function
to print CPU information at the usual place during boot.
Finally, convert users of cpuid_ecx(1) & X86_FEATURE_HYPERVISOR.
Signed-off-by: Sergey Dyasli
--
egion type change in virtualised environments,
trusting whatever memory map our hypervisor has provided.
Signed-off-by: Sergey Dyasli
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
CC: Juergen Gross
---
xen/arch/x86/e820.c | 5 +++--
1 file changed, 3 insert
On 30/10/2019 15:32, Jan Beulich wrote:
> On 30.10.2019 15:54, Sergey Dyasli wrote:
>> @@ -317,11 +316,6 @@ void __init early_cpu_init(void)
>> c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
>> c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)]
egion type change in virtualised environments,
trusting whatever memory map our hypervisor has provided.
Take a refactoring opportunity to introduce early_cpu_has_hypervisor().
Signed-off-by: Sergey Dyasli
---
v2 --> v3:
- early_cpu_has_hypervisor() is added
CC: Jan Beulich
CC: Andrew Cooper
On 31/10/2019 11:07, Jan Beulich wrote:
> On 31.10.2019 11:56, Sergey Dyasli wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -274,6 +274,15 @@ static inline u32 phys_pkg_id(u32 cpuid_apic, int
>> index_msb)
>> return _phy
On 01/11/2019 20:25, Andrew Cooper wrote:
> We cache Long Mode and No Execute early on boot, so take the opportunity to
> cache HYPERVISOR early as well.
Either:
1. the description needs clarifying that the whole 1c featureset is
being stored, or
2. a mask should be applied to store only the hy
Hello,
The latest upstream fails to boot on AMD Rome with this:
(XEN) [ 10.082154] ENABLING IO-APIC IRQs
(XEN) [ 10.087789] -> Using new ACK method
(XEN) [ 10.093738] Assertion 'get_rte_index(rte) == offset' failed at
iommu_intr.c:328
Full log is available at https://paste.debian.net/111
This issue was discovered during internal testing.
Sergey Dyasli (2):
system_state: introduce SYS_STATE_smp_booted
common/page_alloc: don't idle-scrub before microcode update
xen/arch/arm/setup.c | 6 ++
xen/arch/x86/setup.c | 4
xen/common/page_alloc.c | 7 +++
The new state means that all secondary CPUs are up. On x86 this also
means that a microcode was (potentially) updated on all CPUs.
On ARM side of things, additionally set system_state to SYS_STATE_smp_boot
just before bringing up secondary CPUs.
Signed-off-by: Sergey Dyasli
---
xen/arch/arm
on 0x11 to 0x1e, d
[2J[1;1H[2J
Prevent this situation by disabling idle scrubbing until
SYS_STATE_smp_booted is reached.
Signed-off-by: Sergey Dyasli
---
xen/arch/arm/setup.c| 2 ++
xen/arch/x86/setup.c| 2 ++
xen/common/page_alloc.c | 7 +++
3 files changed, 11 insertions(+
On 27/11/2018 10:22, Jan Beulich wrote:
On 27.11.18 at 11:00, wrote:
>> The new state means that all secondary CPUs are up. On x86 this also
>> means that a microcode was (potentially) updated on all CPUs.
>
> I'm slightly concerned by such an x86 specific: Could we settle on
> a more generi
On 27/11/2018 10:15, Jan Beulich wrote:
>>>> On 27.11.18 at 11:10, wrote:
>> Hi,
>>
>> On 11/27/18 10:00 AM, Sergey Dyasli wrote:
>>> Some x86 CPUs has errata regarding microcode updates. The most notorious
>>> is Broadwell's BDX90: "Lo
Hi Juergen,
2 small requests from me below.
On Wed, 2018-04-18 at 10:30 +0200, Juergen Gross wrote:
> Instead of switching XPTI globally on or off add a per-domain flag for
> that purpose. This allows to modify the xpti boot parameter to support
> running dom0 without Meltdown mitigations. Using
boot
"xpti=dom0=0"
> parameter will achieve that.
>
> Move the xpti boot parameter handling to xen/arch/x86/pv/domain.c as
> it is pv-domain specific.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Jan Beulich
> ---
> V9:
> - adjust boot message (Sergey Dya
Commit 62b1879693e0 ("x86: further CPUID handling adjustments") added
FEATURESET_7d0 reporting but forgot to update calculate_raw_featureset()
function. As result, the value reported by xen-cpuid contains 0.
Fix that by properly filling raw_featureset[FEATURESET_7d0].
Signed-off-
e as it should be.
>
> Also the VVMCS GUEST_CR4 value should be updated to match the
> underlying value when syncing the VVMCS state.
>
> Fixes: 406817 ("vmx/hap: optimize CR4 trapping")
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jun Nakajima
> Cc: Kevin Tian
>
. Remove them.
Signed-off-by: Sergey Dyasli
---
Compile tested with aarch64 compiler.
---
xen/drivers/char/console.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 121073c8ed..47aff69869 100644
--- a/xen
On Thu, 2018-03-15 at 02:37 -0600, Jan Beulich wrote:
> > > > On 13.03.18 at 12:51, wrote:
> > > > > On 13.03.18 at 11:36, wrote:
> > >
> > > On 13/03/2018 10:13, Jan Beulich wrote:
> > > > The respective MSRs are write-only, and hence attempts by guests to
> > > > write to these are - as of 1f1
On Wed, 2018-03-21 at 19:52 +, Andrew Cooper wrote:
> On 28/02/18 16:09, Sergey Dyasli wrote:
> >
> > +struct {
> > +/* 0x0480 MSR_IA32_VMX_BASIC */
> > +union {
> > +uint64_t
On Wed, 2018-03-21 at 20:46 +, Andrew Cooper wrote:
> On 28/02/2018 16:09, Sergey Dyasli wrote:
> > +
> > +dp->vmx.pinbased_ctls.allowed_0.raw = VMX_PINBASED_CTLS_DEFAULT1;
> > +dp->vmx.pinbased_ctls.allowed_1.raw = VMX_PINBASED_CTLS_D
thes 3,4 and 5
- Other changes are provided on per-patch basis
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 CPUI
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
Reviewed-by: Andrew Cooper
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
Reviewed-by: Andrew Cooper
---
v5 --> v6:
- Updated reca
mx_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
---
v5 --> v6:
- Removed "_bits" and "_based" from union names
- Removed "_exiting" suffixes f
X MSRs.
Signed-off-by: Sergey Dyasli
Reviewed-by: Andrew Cooper
---
v5 --> v6:
- Moved VMX MSRs case to the read-only block in guest_wrmsr()
- Added Reviewed-by
---
xen/arch/x86/hvm/vmx/vmx.c | 6 --
xen/arch/x86/hvm/vmx/vvmx.c| 178 -
ed by guest_rd/wrmsr().
Signed-off-by: Sergey Dyasli
---
v5 --> v6:
- Replaced !cpu_has_vmx check with !hvm_max_cpuid_policy.basic.vmx
- Added a TODO reminder
- Added brackets around bit or expressions
---
xen/arch/x86/msr.c | 135 +
1 file chan
> /* 0x0140 MSR_INTEL_MISC_FEATURES_ENABLES */
> struct {
> -bool available; /* This MSR is non-architectural */
> bool cpuid_faulting;
> } misc_features_enables;
> };
Could you add comments saying that those 2 MSRs are always available
for all gu
o move
> the cpuid_faulting field to its appropriate position.
>
> Signed-off-by: Andrew Cooper
> ---
>
Reviewed-by: Sergey Dyasli
--
Thanks,
Sergey
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Tue, 2018-07-03 at 21:55 +0100, Andrew Cooper wrote:
> From: Sergey Dyasli
>
> This finally (after literally years of work!) marks the point where the
> toolstack can ask the hypervisor for the current CPUID configuration of a
> specific domain.
>
> Also extend xen-cpu
ter capture the code's intent.
Fixes 1a37f33ea613 ("mm: Place unscrubbed pages at the end of pagelist")
Signed-off-by: Sergey Dyasli
---
CC: Andrew Cooper
CC: George Dunlap
CC: Jan Beulich
CC: Julien Grall
CC: Wei Liu
CC: Boris Ostrovsky
---
xen/common/page_alloc.c | 8
aim of first_dirty that the block is scrubbed.
> > >
> > > Add the missing piece of logic and slightly update the comment for
> > > the predecessor case to better capture the code's intent.
> > >
> > > Fixes 1a37f33ea613 ("mm: Place unscrubbed pages a
On Mon, 2018-08-13 at 02:54 -0600, Jan Beulich wrote:
> > > > On 13.08.18 at 09:46, wrote:
> >
> > proposed topics so far:
> > * 4.10+ changes to Xen's memory scrubbing: discussion of the changes
> > that made to it in recent versions of Xen (4.10+) - Christopher
> > * Project Management
gned-off-by: Andrew Cooper
> Reviewed-by: Paul Durrant
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Sergey Dyasli
>
> v3:
> * Clean up after splitting the series. Retain appropriate R-by's
> ---
> xen/arch/x86/hvm/viridia
ing X86EMUL_* return values.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Sergey Dyasli
>
> v3:
> * Clean up after splitting the series.
> ---
> xen/arch/x86/msr.c
On Wed, 2018-09-12 at 10:12 +0100, Andrew Cooper wrote:
> On 12/09/18 09:29, Sergey Dyasli wrote:
> > On Tue, 2018-09-11 at 19:56 +0100, Andrew Cooper wrote:
> > > Rename them to guest_{rd,wr}msr_xen() for consistency, and because the
> > > _regs
> >
eviewed-by: Kevin Tian
> Reviewed-by: Paul Durrant
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Sergey Dyasli
>
> v3:
> * Split out of previous series. Retain appropriate R-by's
> v4:
> * Retain switch() for interp
On Wed, 2018-09-12 at 11:23 +0100, Andrew Cooper wrote:
> On 12/09/18 10:46, Sergey Dyasli wrote:
> > On Wed, 2018-09-12 at 10:12 +0100, Andrew Cooper wrote:
> > > On 12/09/18 09:29, Sergey Dyasli wrote:
> > > > On Tue, 2018-09-11 at 19:56 +0100, Andrew Cooper w
return scrubbed
pages to a caller unless MEMF_no_scrub flag was provided.
Signed-off-by: Sergey Dyasli
---
CC: Andrew Cooper
CC: Boris Ostrovsky
CC: George Dunlap
CC: Jan Beulich
CC: Julien Grall
CC: Tim Deegan
---
docs/misc/xen-command-line.markdown | 3 ++-
xen/common/page_alloc.c
On Mon, 2018-10-01 at 07:38 -0600, Jan Beulich wrote:
> > > > On 01.10.18 at 15:12, wrote:
> >
> > On 01/10/18 12:13, Jan Beulich wrote:
> > > > > > On 01.10.18 at 11:58, wrote:
> > > >
> > > > Having the allocator return unscrubbed pages is a potential security
> > > > concern: some domain can
On Mon, 2018-10-01 at 07:38 -0600, Jan Beulich wrote:
> > > > On 01.10.18 at 15:12, wrote:
> >
> > On 01/10/18 12:13, Jan Beulich wrote:
> > > > > > On 01.10.18 at 11:58, wrote:
> > > >
> > > > Having the allocator return unscrubbed pages is a potential security
> > > > concern: some domain can
On Mon, 2018-10-01 at 14:54 +0100, George Dunlap wrote:
> On 10/01/2018 02:44 PM, Sergey Dyasli wrote:
> > On Mon, 2018-10-01 at 07:38 -0600, Jan Beulich wrote:
> > > > > > On 01.10.18 at 15:12, wrote:
> > > >
> > > > On 01/10/18 12:13, Jan
On 01/10/18 12:13, Jan Beulich wrote:
On 01.10.18 at 11:58, wrote:
>> Having the allocator return unscrubbed pages is a potential security
>> concern: some domain can be given pages with memory contents of another
>> domain. This may happen, for example, if a domain voluntarily releases
>> it
anteed that the allocator will return scrubbed pages by doing
eager scrubbing during allocation (unless MEMF_no_scrub was provided).
Signed-off-by: Sergey Dyasli
---
CC: Andrew Cooper
CC: Boris Ostrovsky
CC: George Dunlap
CC: Jan Beulich
CC: Julien Grall
CC: Tim Deegan
---
docs/misc/xen-comman
by doing
eager scrubbing during allocation (unless MEMF_no_scrub was provided).
Use the new 'idle' option as the default one.
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- dropped comment about performance
- changed default to 'idle'
- changed type of opt_bootscrub to enum
-
As a convenient helper function and refactor the code to use it.
No functional change.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c | 17 -
xen/include/asm-x86/hvm/nestedhvm.h | 5 +
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a
And make nvmx_handle_vmclear() return the new errno in case the provided
address is the same as vmxon region address.
While at it, correct the return value for not-4KB-aligned case and for
invalid physaddr.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c| 23
These were found by running nested VMX tests from kvm-unit-tests.
Sergey Dyasli (6):
x86/vvmx: introduce vvmcx_valid()
x86/vvmx: correct vmfail() usage for vmptrld and vmclear
x86/vvmx: add VMX_INSN_VMPTRLD_WITH_VMXON_PTR errno
x86/vvmx: add VMX_INSN_VMCLEAR_WITH_VMXON_PTR errno
x86
The size of Xen's virtual vmcs region is 4096 bytes. Correctly report
it to the guest in case when VMCS shadowing is not available instead of
providing H/W value (which is usually smaller).
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c | 8
1 file changed, 8 inser
And make nvmx_handle_vmptrld() return the new errno in case the provided
address is the same as vmxon region address.
While at it, correct the return value for not-4KB-aligned case.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c| 10 --
xen/include/asm-x86/hvm/vmx
only:
1. During the first nested vmentry
2. After L1 has changed an appropriate vmcs field
3. After nvmx_purge_vvmcs() was previously called
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c | 104 +++-
1 file changed, 67 insertions(+), 37
Calling vmfail_valid() is correct only if vvmcx is valid. Modify
functions to use vmfail() instead which performs the necessary check.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c
1 - 100 of 265 matches
Mail list logo
