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 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_capab
hich 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:
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
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
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
Thus, 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
> 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,
Sergey
__
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
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 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 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:
>>
>>(X
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 l
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
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
---
v1 -->
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 Monné
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
>>> c
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:
>>
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"
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
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
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
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
CC: Wei
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)]
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 insertions(+), 2
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
--
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
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 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 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 reserves 640
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/arch/x86/
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(), but
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]
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
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,
()
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 7364fd2c33
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
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 b
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:
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
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
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() <--
Hi Juergen,
I've found another regression that happens only with sched-gran=core.
CentOS 5.11 (PV, CPUs: 32; RAM: 6GB) kernel hangs during suspend attempt.
The last kernel messages are:
CPU 1 offline: Remove Rx thread
CPU 2 offline: Remove Rx thread
Kernel: Linux localhost
On 24/07/2019 10:13, Juergen Gross wrote:
> The fix is a one-liner. :-)
>
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index f0bc5b3161..da9efb147f 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -2207,6 +2207,7 @@ static struct sched_unit
>
On 19/07/2019 14:57, Juergen Gross wrote:
> I have now a git branch with the two problems corrected and rebased to
> current staging available:
>
> github.com/jgross1/xen.git sched-v1b
Many thanks for the branch! As for the crashes, vcpu_sleep_sync() one
seems to be fixed now. But I can still
On 18/07/2019 15:48, Juergen Gross wrote:
> On 15.07.19 16:08, Sergey Dyasli wrote:
>> On 05/07/2019 14:56, Dario Faggioli wrote:
>>> On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
>>>> 1) This crash is quite likely to happen:
>>>>
>>
On 05/07/2019 14:17, Sergey Dyasli wrote:
> [2019-07-05 00:37:16 UTC] (XEN) [24907.482686] Watchdog timer detects that
> CPU30 is stuck!
> [2019-07-05 00:37:16 UTC] (XEN) [24907.514180] [ Xen-4.13.0-8.0.6-d
> x86_64 debug=y Not tainted ]
> [2019-07-05 00:
On 05/07/2019 14:56, Dario Faggioli wrote:
> On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
>> 1) This crash is quite likely to happen:
>>
>> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.220660] Watchdog timer detects
>> that CPU2 is stuck!
>> [2019-07-04
Hi Juergen,
I did some testing of this series (with sched-gran=core) and posting a couple of
crash backtraces here for your information.
Additionally, resuming a Debian 7 guest after suspend is broken.
I will be able to provide any additional information only after XenSummit :)
1) This crash
ram 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
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="?
oline_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: Cha
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 ++
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.
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
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
;
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.
Signed-off-
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 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 | 2
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: "Loading
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
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
11 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(+)
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 +++
xen
; https://bugs.llvm.org/show_bug.cgi?id=39707
>
> I haven't been able to find any other instances of such conditional
> expression that uses system_state together with an init variable or
> function.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Sergey Dyas
this process since there is little point
in scrubbing memory for Dom0.
Signed-off-by: Sergey Dyasli
---
v2:
- use MEMF_no_scrub in more calls
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
---
xen/arch/x86/hvm/dom0_build.c | 2 +-
xen/arch/x86/pv/dom0_bui
les changed, 47 insertions(+), 6 deletions(-)
Reviewed-by: Sergey Dyasli
Thanks
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 20/11/2018 17:16, Jan Beulich wrote:
On 20.11.18 at 18:00, wrote:
>> Now that idle scrub is the default option, all memory is marked as dirty
>> and alloc_domheap_pages() will do eager scrubbing by default. This can
>> lead to longer Dom0 construction and potentially to a watchdog
this process since there is little point
in scrubbing memory for Dom0 RAM.
Signed-off-by: Sergey Dyasli
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
---
xen/arch/x86/hvm/dom0_build.c | 2 +-
xen/arch/x86/pv/dom0_build.c | 5 +++--
2 files changed, 4 insert
Don't call vmsucceed() at the end of virtual_vmexit()
Reviewed-by: Sergey Dyasli
--
Thanks,
Sergey
> xen/arch/x86/hvm/vmx/vvmx.c | 22 +++---
> 1 file changed, 7 insertions(+), 15 deletions(-)
>
___
Xen-devel mailing list
Xen-de
think the description must be
changed.
--
Sergey
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Sergey Dyasli
> CC: Jun Nakajima
> CC: Kevin Tian
> ---
> xen/arch/x86/hvm/vmx/vvmx.c | 1 -
> 1 file changed, 1
Signed-off-by: Sergey Dyasli
---
CC: Jan Beulich
CC: Wei Liu
---
xen/common/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 88d1637247..08ee8cfbb9 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common
-off-by: Sergey Dyasli
Acked-by: Kevin Tian
---
v3:
- Added Acked-by
v2:
- Removal of enum vmx_ops_result and refactoring
---
xen/arch/x86/hvm/vmx/vvmx.c| 52 +-
xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
2 files changed, 30 insertions(+), 23 deletions(-)
diff
reasons, Xen maps bitmaps 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
Acked-by: Kevin Tian
---
v3:
- Added Acked-by
v2:
- slight commit message change
This allows to safely use nestedhvm functions that rely on the values
inside struct nestedvcpu independently of the nested virtualisation
(HVM_PARAM_NESTEDHVM) status of a domain.
Signed-off-by: Sergey Dyasli
---
v3:
- new patch
---
xen/arch/x86/hvm/hvm.c | 2 ++
1 file changed, 2 insertions
As a convenient helper function and refactor the code to use it.
No functional change.
Signed-off-by: Sergey Dyasli
Reviewed-by: Boris Ostrovsky
Reviewed-by: Wei Liu
Reviewed-by: Kevin Tian
---
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
v3:
- Added R-by
v2:
- Use
And use it in nvmx_handle_invept() and nvmx_handle_invvpid().
Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
---
v3:
- Added Acked-by
v2:
- new patch
---
xen/arch/x86/hvm/vmx/vvmx.c| 4 ++--
xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
2 files changed, 3 insertions(+), 2 deletions
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
Acked-by: Kevin Tian
---
v3:
- no changes
v2:
- Added Acked-by
---
xen/arch/x86
The size of Xen's virtual vmcs region is 4096 bytes (see comment about
Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). 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
Calling vmfail_valid() is correct only if vvmcx is valid. Modify
functions to use vmfail() instead which performs the necessary check.
While at it, add ASSERTs into vmfail_valid/invalid() to quickly catch
an incorrect usage in the future.
Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
These were found by running nested VMX tests from kvm-unit-tests.
v3:
- Removed 1/8 "x86/vvmx: introduce nvmx_vcpu_preinit()"
- Added 1/8 "x86/nestedhvm: init nv_vvmcxaddr in hvm_vcpu_initialise()"
- Added R-by and Acked-by to other patches
Sergey Dyasli (8):
x86/nestedhv
On 08/11/2018 15:18, Roger Pau Monné wrote:
> On Thu, Nov 08, 2018 at 02:48:40PM +0000, Sergey Dyasli wrote:
>> (CCing Roger)
>>
>> On 08/11/2018 11:07, Andrew Cooper wrote:
>>> On 08/11/18 10:31, Jan Beulich wrote:
>>>>>>> On 07.11.18 at 19:20,
(CCing Roger)
On 08/11/2018 11:07, Andrew Cooper wrote:
> On 08/11/18 10:31, Jan Beulich wrote:
>>>>> On 07.11.18 at 19:20, wrote:
>>> On 09/10/18 16:21, Sergey Dyasli wrote:
>>>> Scrubbing RAM during boot may take a long time on machines with lots
>
On 07/11/2018 13:28, Wei Liu wrote:
> On Tue, Nov 06, 2018 at 12:07:58PM +0000, Sergey Dyasli wrote:
>> The size of Xen's virtual vmcs region is 4096 bytes (see comment about
>> Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly report
>> it to the guest in cas
On 07/11/2018 18:20, Andrew Cooper wrote:
> On 09/10/18 16:21, Sergey Dyasli wrote:
>> Scrubbing RAM during boot may take a long time on machines with lots
>> of RAM. Add 'idle' option to bootscrub which marks all pages dirty
>> initially so they will eventually be scrubbed
On 07/11/2018 12:17, Wei Liu wrote:
> On Wed, Nov 07, 2018 at 11:11:49AM +0000, Sergey Dyasli wrote:
>> Scrubbing RAM during boot may take a long time on machines with lots
>> of RAM. Add 'idle' option to bootscrub which marks all pages dirty
>> initially so they will e
scrubbing during allocation (unless MEMF_no_scrub was provided).
Use the new 'idle' option as the default one.
Signed-off-by: Sergey Dyasli
Reviewed-by: Jan Beulich
---
v2 --> v3:
- Removed "= 0" from enum bootscrub_mode
- Removed num_online_nodes() from printk()
- Added Reviewed-b
The size of Xen's virtual vmcs region is 4096 bytes (see comment about
Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). 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
As a convenient helper function and refactor the code to use it.
No functional change.
Signed-off-by: Sergey Dyasli
---
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
v2:
- Use the new helper in nestedsvm.c
---
xen/arch/x86/hvm/svm/nestedsvm.c| 2 +-
xen/arch/x86/hvm
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
Acked-by: Kevin Tian
---
v2:
- Added Acked-by
---
xen/arch/x86/hvm/vmx/vvmx.c
These were found by running nested VMX tests from kvm-unit-tests.
Sergey Dyasli (8):
x86/vvmx: introduce nvmx_vcpu_preinit()
x86/nestedhvm: introduce vvmcx_valid()
x86/vvmx: add VMX_INSN_INVEPT_INVVPID_INVALID_OP errno
x86/vvmx: correct vmfail() usage for vmptrld and vmclear
x86/vvmx
reasons, Xen maps bitmaps 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
---
v2:
- slight commit message change
---
xen/arch/x86/hvm/vmx/vvmx.c | 105
Calling vmfail_valid() is correct only if vvmcx is valid. Modify
functions to use vmfail() instead which performs the necessary check.
While at it, add ASSERTs into vmfail_valid/invalid() to quickly catch
an incorrect usage in the future.
Signed-off-by: Sergey Dyasli
---
v2:
- Added ASSERTs
And call it during vmx_vcpu_initialise(). This allows to safely use
vvmx functions that rely on the values inside struct nestedvmx and
struct nestedvcpu, independently of the nested virtualisation
(HVM_PARAM_NESTEDHVM) status of a domain.
Signed-off-by: Sergey Dyasli
---
v2:
- new patch
---
xen
And use it in nvmx_handle_invept() and nvmx_handle_invvpid().
Signed-off-by: Sergey Dyasli
---
v2:
- new patch
---
xen/arch/x86/hvm/vmx/vvmx.c| 4 ++--
xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b
-off-by: Sergey Dyasli
---
v2:
- Removal of enum vmx_ops_result and refactoring
---
xen/arch/x86/hvm/vmx/vvmx.c| 52 +-
xen/include/asm-x86/hvm/vmx/vmcs.h | 1 +
2 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen
On 01/11/2018 02:22, Tian, Kevin wrote:
>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>> Sent: Tuesday, October 30, 2018 8:41 PM
>>
>> On 30/10/2018 07:41, Tian, Kevin wrote:
>>>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>>
On 30/10/2018 07:41, Tian, Kevin wrote:
>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>> Sent: Friday, October 12, 2018 11:28 PM
>>
>> As a convenient helper function and refactor the code to use it.
>>
>> No functional change.
>>
>> Sign
101 - 200 of 259 matches
Mail list logo
