On 08/08/2019 01:31, Marek Marczykowski-Górecki wrote:
> When booting Xen via xen.efi, there is /mapbs option to workaround
> certain platform issues (added in f36886bdf4 "EFI/early: add /mapbs to
> map EfiBootServices{Code,Data}"). Add support for efi=mapbs on Xen
> cmdline for the same effect and
On 08/08/2019 10:08, Jan Beulich wrote:
> On 08.08.2019 10:33, Andrew Cooper wrote:
>> On 08/08/2019 05:50, Juergen Gross wrote:
>>> On 07.08.19 20:11, Andrew Cooper wrote:
>>>>
>>>> Its not exactly the easiest to dump to follow.
>>>>
>&
On 08/08/2019 10:36, Juergen Gross wrote:
> On 08.08.19 10:33, Andrew Cooper wrote:
>> On 08/08/2019 05:50, Juergen Gross wrote:
>>> On 07.08.19 20:11, Andrew Cooper wrote:
>>>>
>>>>
>>>> Its not exactly the easiest to dump to follow.
>&g
On 08/08/2019 10:13, Julien Grall wrote:
> Hi Jan,
>
> On 08/08/2019 10:04, Jan Beulich wrote:
>> On 08.08.2019 10:43, Andrew Cooper wrote:
>>> On 08/08/2019 07:22, Jan Beulich wrote:
>>>> On 07.08.2019 21:41, Andrew Cooper wrote:
>>>>> --- /d
the instruction size suffixes without introducing ambiguity.
* Misc style changes.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v3:
* Retain "q"
v2:
* Correct comment WRT 32bit builds and "=q" constraints
* Drop semicolons after the l
On 08/08/2019 12:53, Juergen Gross wrote:
> On 08.08.19 12:28, Julien Grall wrote:
>>
>>
>> On 08/08/2019 08:51, Juergen Gross wrote:
>>> On 08.08.19 08:58, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
Do we have an implied assumption somewhere that unsigned short is
On 08/08/2019 21:59, Sander Eikelenboom wrote:
> Hi Andrew,
>
> It seems the pvshim patches in xen-unstable staging break the build on my
> machine.
> I cloned a fresh tree to be sure, haven't checked which of the two commits
> causes it:
> 060f4eee0fb408b316548775ab921e16b7acd0e0 or
> 32b1d6288
On 08/08/2019 22:16, Sander Eikelenboom wrote:
> On 08/08/2019 23:05, Andrew Cooper wrote:
>> On 08/08/2019 21:59, Sander Eikelenboom wrote:
>>> Hi Andrew,
>>>
>>> It seems the pvshim patches in xen-unstable staging break the build on my
>>> machine.
On 08/08/2019 23:34, Sander Eikelenboom wrote:
> On 08/08/2019 23:14, Andrew Cooper wrote:
>> On 08/08/2019 22:16, Sander Eikelenboom wrote:
>>> On 08/08/2019 23:05, Andrew Cooper wrote:
>>>> On 08/08/2019 21:59, Sander Eikelenboom wrote:
>>>>> Hi Andre
this patch to perform the rename.
Preferably with this done, Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 09/08/2019 11:40, Jan Beulich wrote:
> Signed-off-by: Andrew Cooper
>
> Introduce SEL2GDT(). Correct GDT indices in public header.
"Correct" here is ambiguous because it implies there is a breakage.
You appear to have reversed FLAT_RING3_CS64 and DS32 (retaining the
ori
Xen, being 64bit only these days, has no use for a 32bit Ring 0 code segment.
Delete __HYPERVISOR_CS32 and remove it from the GDTs. Also delete
__HYPERVISOR_CS64 and use __HYPERVISOR_CS uniformly.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch
On 09/08/2019 12:34, Jan Beulich wrote:
> On 09.08.2019 13:05, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [Xen-devel] [PATCH 2/2]
>> tools/tests/cpu-policy: disable -Wformat-overflow"):
>>> Would you mind clarifying which 12 you mean to change to 13?
>>> The one in "%.12s" would, if changed and
On 09/08/2019 13:43, Jan Beulich wrote:
> On 09.08.2019 14:19, Andrew Cooper wrote:
>> On 09/08/2019 11:40, Jan Beulich wrote:
>>> Signed-off-by: Andrew Cooper
>>>
>>> Introduce SEL2GDT(). Correct GDT indices in public header.
>>
>> "Cor
ng important bit of logic across a newline.
Preferably with this changed, but definitely with the commit message
fixed, Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 09/08/2019 13:32, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
> ---
> TBD: Especially with how the previous patch now works I'm unconvinced of
> the utility of the linker script alignment check. It in particular
> doesn't check the property we're after in this patch, i.e. the fact
Drop the
redirection and update all callers to use tss_page properly.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
RFC, and based on my requested changes for patch 2.
---
xen/arch/x86/cpu/common.c | 8
xen/arch/x86/hvm/vmx/vmcs.c | 2 +-
On 09/08/2019 16:17, Andrew Cooper wrote:
> The _struct suffix on tss_struct is quite redundant. Rename it to tss64 to
> mirror the existing tss32 structure we have in HVM's Task Switch logic.
>
> The per-cpu name having an init_ prefix is also wrong. There is exactly one
&
On 09/08/2019 14:18, Jan Beulich wrote:
> On 09.08.2019 15:07, Andrew Cooper wrote:
>> On 09/08/2019 13:43, Jan Beulich wrote:
>>> On 09.08.2019 14:19, Andrew Cooper wrote:
>>>> On 09/08/2019 11:40, Jan Beulich wrote:
>>>>> --- /dev/null
>>
On 09/08/2019 13:50, Jan Beulich wrote:
> On 09.08.2019 14:39, Andrew Cooper wrote:
>> Xen, being 64bit only these days, has no use for a 32bit Ring 0 code
>> segment.
>>
>> Delete __HYPERVISOR_CS32 and remove it from the GDTs. Also delete
>> __HYPERVISOR_CS64
scrub any state
from the previous vcpu. Other properties of %cs/%ss loads prevent those
segments from being leaky.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
RFC for now. I've demonstrated leakage when I posion in Xen and recover in an
HVM guest.
On 12/08/2019 08:23, Jan Beulich wrote:
> @@ -747,16 +747,10 @@ void load_system_tables(void)
> .bitmap = IOBMP_INVALID_OFFSET,
> };
>
> - _set_tssldt_desc(
> - gdt + TSS_ENTRY,
> - (unsigned long)tss,
> - offsetof(struct tss_struct, __cacheline_filler) - 1,
On 12/08/2019 08:32, Jan Beulich wrote:
> On 09.08.2019 12:40, Jan Beulich wrote:
>> There is plenty more cleanup which can be done in the future. As we are
>> 64-bit, there is no need for load_TR() to keep the TSS in sync
>> between the two
>> GDTs, which means it can drop all sgdt/lgdt instructi
On 12/08/2019 12:04, Jan Beulich wrote:
> On 12.08.2019 12:29, Andrew Cooper wrote:
>> On 12/08/2019 08:23, Jan Beulich wrote:
>>> @@ -747,16 +747,10 @@ void load_system_tables(void)
>>> .bitmap = IOBMP_INVALID_OFFSET,
>>> };
>>&
On 12/08/2019 15:53, George Dunlap wrote:
> On 8/8/19 10:13 AM, Julien Grall wrote:
>> Hi Jan,
>>
>> On 08/08/2019 10:04, Jan Beulich wrote:
>>> On 08.08.2019 10:43, Andrew Cooper wrote:
>>>> On 08/08/2019 07:22, Jan Beulich wrote:
>>>>>
mov/shr is easier to follow than shld, and doesn't have a merge dependency on
the previous value of %edx. Shorten the rest of the code by streamlining the
comments.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
In addition to being clearer to follow
sole.
Use spin_lock_irqsave() instead to cope with interrupts already being
disabled.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Jun Nakajima
CC: Kevin Tian
I'm fairly confident that the AMD side of things is fine, because
enable_iommu() is
It is never written to.
This was an oversight when it was moved from asm into C.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/desc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/desc.c b/xen/arch/x86
e LDT is guaranteed to be NUL.
The TR is still correct in the GDT, but needs the busy bit clearing before we
can reload it.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
A slightly different option would be to call load_system_tables() rather than
opencoding
This started off as "get rid of load_TR()" as identified in the TSS cleanup
series, and morphed slightly.
Andrew Cooper (3):
x86/suspend: Sanity check more properties in enter_state()
x86/desc: Move boot_gdtr into .rodata
x86/suspend: Simplify system table handling on resume
xe
The logic depends on being run on CPU0, and in IDLE context. Having this
explicitly identified allows for simplification of the whole S3 path.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/acpi/power.c | 2 ++
1 file changed, 2 insertions
... to avoid having multiple spin_unlock_irqrestore() calls.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
Interestingly GCC 6.3 managed to fold disable_iommu() automatically. There is
some
On 12/08/2019 09:00, Jan Beulich wrote:
> On 09.08.2019 19:16, Andrew Cooper wrote:
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -1914,7 +1914,7 @@ By default SSBD will be mitigated at runtime
>> (i.e `ssbd=runtime
On 12/08/2019 21:27, Julien Grall wrote:
> When freeing a p2m entry, all the sub-tree behind it will also be freed.
> This may include intermediate page-tables or any l3 entry requiring to
> drop a reference (e.g for foreign pages). As soon as pages are freed,
> they may be re-used by Xen or anothe
kernels (fixed in 4.9) and RHEL/CentOS/OEL
5.2 and 5.3 kernels (fixed in 5.4). RHEL 4 as a major version went out of
support in 2017, whereas the 5.2/5.3 kernels went out of support when 5.4 was
released in 2009.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
These domctls exist to work around bugs in obsolete 32bit PV guests. They are
no longer useful.
Andrew Cooper (2):
xen: Drop XEN_DOMCTL_suppress_spurious_page_faults
xen: Drop XEN_DOMCTL_{get,set}_machine_address_size
tools/libxc/include/xenctrl.h | 9
tools/libxc
the 32bit RHEL/CentOS 4.{5..7} kernels (fixed in 4.8). RHEL 4 as a major
version when out if support in 2017.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Ian Jackson
CC: Marek Marczykowski-Górecki
CC: Daniel De Graaf
---
tools/libxc/include
On 09/08/2019 00:28, Sander Eikelenboom wrote:
> On 09/08/2019 00:44, Andrew Cooper wrote:
>> On 08/08/2019 23:34, Sander Eikelenboom wrote:
>>> On 08/08/2019 23:14, Andrew Cooper wrote:
>>>> On 08/08/2019 22:16, Sander Eikelenboom wrote:
>>>>> On 08/
) is not at file
scope. However, it can be worked around by using a local variable.
Spotted by Gitlab CI.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/smpboot.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --gi
On 13/08/2019 12:51, Sander Eikelenboom wrote:
> On 13/08/2019 13:21, Andrew Cooper wrote:
>> On 09/08/2019 00:28, Sander Eikelenboom wrote:
>>> On 09/08/2019 00:44, Andrew Cooper wrote:
>>>> On 08/08/2019 23:34, Sander Eikelenboom wrote:
>>>>> On 08/
ds one charater more than devBridge[], so allocate one byte
more. Replace a raw 16 in the snprintf() call with a sizeof() expression
instead.
Finally, libxenstat, unlike most of the rest of the Xen, doesn't use -Werror
which is why this issue went unnoticed in CI. Fix this.
Signed-
really is unused.
Spotted by Travis-CI.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/xenstat/libxenstat/src/xenstat.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/tools/xenstat/libxenstat/src/xenstat.c
b/tools/xenstat/libxenstat/src/xenstat.c
index
On 13/08/2019 15:48, Anthony PERARD wrote:
> Handle += of both strings and lists.
>
> If += is used for config options expected to be numbers, then a
> warning is printed and the config option ignored (because xl ignores
> config options with errors).
>
> This is to be used for development purposes
On 13/08/2019 16:30, Anthony PERARD wrote:
> On Tue, Aug 13, 2019 at 04:06:33PM +0100, Andrew Cooper wrote:
>> On 13/08/2019 15:48, Anthony PERARD wrote:
>>> Handle += of both strings and lists.
>>>
>>> If += is used for config options expected to be numbers, t
On 24/01/2019 22:10, Andrew Cooper wrote:
> On 24/01/2019 21:42, Julien Grall wrote:
>> Hi Andrew,
>>
>> On 12/21/18 1:46 PM, Andrew Cooper wrote:
>>> All of this code lives inside CONFIG_PV which means gfn == mfn, and the
>>> fill_ro_mpt() calls clearly s
On 13/08/2019 22:03, Sander Eikelenboom wrote:
> On 13/08/2019 15:31, Andrew Cooper wrote:
>> On 13/08/2019 12:51, Sander Eikelenboom wrote:
>>> On 13/08/2019 13:21, Andrew Cooper wrote:
>>>> On 09/08/2019 00:28, Sander Eikelenboom wrote:
>>>>> On 09/
On 13/08/2019 22:02, YOUNG, MICHAEL A. wrote:
> I have been looking at the pygrub code to see if it is possible to cope
> with grub files with BLSCFG and spotted this minor issue in GrubConf.py
> where the code intends to replace ${saved_entry} and ${next_entry} with 0
> but doesn't succeed.
>
>
Introduce a new ENDDATA() helper which sets type and size together.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/boot/x86_64.S | 18 +-
xen/include/asm-x86/config.h | 5 +
2 files changed, 14 insertions(+), 9
On 13/08/2019 22:02, YOUNG, MICHAEL A. wrote:
> I have been looking at the pygrub code to see if it is possible to cope
> with grub files with BLSCFG and spotted this minor issue in GrubConf.py
> where the code intends to replace ${saved_entry} and ${next_entry} with 0
> but doesn't succeed.
>
>
On 14/08/2019 13:00, Wei Liu wrote:
> On Wed, Aug 14, 2019 at 11:44:04AM +0100, Andrew Cooper wrote:
> [...]
>> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
>> index 22dc795eea..35705441ff 100644
>> --- a/xen/include/asm-x86/config.h
>
On 14/08/2019 13:51, George Dunlap wrote:
> On 8/7/19 5:03 PM, Jan Beulich wrote:
>> Whatever we do in Xen, it'll only allow to work around that issue.
>> An actual fix belongs in the kernel(s). For this reason I suppose
>> what we're talking about here is a feature (from Xen's pov), not a
>> bug f
On 14/08/2019 00:16, Sander Eikelenboom wrote:
> On 13/08/2019 23:05, Andrew Cooper wrote:
>> On 13/08/2019 22:03, Sander Eikelenboom wrote:
>>> On 13/08/2019 15:31, Andrew Cooper wrote:
>>>> On 13/08/2019 12:51, Sander Eikelenboom wrote:
>>>>> On 13/
On 01/07/2019 12:47, Jan Beulich wrote:
> On top of the AVX512 series I'd like to put out for review/discussion
>
> 1: generalize wbinvd() hook
> 2: support WBNOINVD
> 3: generalize invlpg() hook
> 4: move INVPCID_TYPE_* to x86-defns.h
> 5: support INVPCID
> 6: support MOVDIR{I,64B} insns
Do you h
On 15/08/2019 16:42, Wieczorkiewicz, Pawel wrote:
> Thanks Julien. I will do that next time (unless you guys want me to
> re-send all this ;-)).
>
> BTW, I also pushed my changes onto the xenbits server:
> http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary
> http
On 16/08/2019 20:51, Johnson, Ethan wrote:
> Hi all,
>
> I have some follow-up questions about Xen's usage and layout of memory,
> building on the ones I asked here a few weeks ago (which were quite
> helpfully answered: see
> https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg01513
On 18/08/2019 18:20, Wei Liu wrote:
> On Fri, Jun 21, 2019 at 11:30:05AM +0200, Olaf Hering wrote:
>> xl(1) opens xl.conf in XEN_CONFIG_DIR.
>> Substitute this variable also in the man page.
>>
>> Signed-off-by: Olaf Hering
>> ---
>> docs/man/xl.1.pod.in | 2 +-
>> docs/man/xl.conf.5.pod.in
On 19/08/2019 03:23, Michał Kowalczyk wrote:
> diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
> index 7c6a2328d2..fcaa3eeaf1 100644
> --- a/xen/arch/x86/boot/trampoline.S
> +++ b/xen/arch/x86/boot/trampoline.S
> @@ -85,7 +85,7 @@ trampoline_gdt:
> .long tram
On 19/08/2019 11:08, Julien Grall wrote:
> Hi Andrew,
>
> On 8/13/19 7:04 PM, Andrew Cooper wrote:
>> On 24/01/2019 22:10, Andrew Cooper wrote:
>>> On 24/01/2019 21:42, Julien Grall wrote:
>>>> Hi Andrew,
>>>>
>>>> On 12/21/18 1:46
Andrew Cooper (3):
x86/boot: Further minor GDT corrections
x86/boot: Reposition trampoline data
x86/boot: Drop all use of lmsw
xen/arch/x86/boot/head.S | 2 +-
xen/arch/x86/boot/trampoline.S| 78 +--
xen/arch/x86/boot/wakeup.S| 5
nal change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/boot/trampoline.S | 67 ++
1 file changed, 28 insertions(+), 39 deletions(-)
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/tr
: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
The trampoline GDT access bits were actually noticed when trying to clean up
our boot time pagetables and map the trampoline read-only.
---
xen/arch/x86/boot/head.S | 2 +-
xen/arch/x86/boot/trampoline.S| 15
: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/boot/trampoline.S | 12 ++--
xen/arch/x86/boot/wakeup.S | 5 +++--
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
index
On 19/08/2019 14:50, Michał Kowalczyk wrote:
> On 8/19/19 11:04 AM, Andrew Cooper wrote:
>> On 19/08/2019 03:23, Michał Kowalczyk wrote:
>>> diff --git a/xen/arch/x86/boot/trampoline.S b/xen/arch/x86/boot/trampoline.S
>>> index 7c6a2328d2..fcaa3eeaf1 100644
>>>
On 19/08/2019 15:42, Ross Lagerwall wrote:
> On 8/14/19 1:23 PM, Pawel Wieczorkiewicz wrote:
>> A lot of legitimate error messages were hidden behind debug printk
>> only. Most of these messages can be triggered by loading a malformed
>> hotpatch payload and are priceless for understanding issues w
On 19/08/2019 14:56, Michał Kowalczyk wrote:
> On 8/19/19 3:52 PM, Andrew Cooper wrote:
>> On 19/08/2019 14:50, Michał Kowalczyk wrote:
>>> On 8/19/19 11:04 AM, Andrew Cooper wrote:
>>>> On 19/08/2019 03:23, Michał Kowalczyk wrote:
>>>>> diff --git
On 19/08/2019 19:01, Julien Grall wrote:
> Commit b5e6e1ee8da "xen/console: Don't treat NUL character as the end
> of the buffer" extended sercon_puts to take the number of character
> to print in argument.
>
> Sadly, a couple of couple of the callers in debugtrace_dump_worker()
> were not converte
This is a subset of a previously posted series, because support for this
workaround has been outstanding for far too long.
Andrew Cooper (2):
x86/feature: Generalise synth and introduce a bug word
x86/AMD: Fix handling of x87 exception pointers on Fam17h hardware
tools/libxl/libxl_cpuid.c
Future changes are going to want to use cpu_bug_* in a mannor similar to
Linux. Introduce one bug word, and generalise the calculation of
NCAPINTS.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v2:
* Rebase
---
xen/include/asm-x86/cpufeatures.h | 67
n AMD hardware where RSTR_FP_ERR_PTRS is not advertised. Optimise the
workaround path by dropping the data-dependent unpredictable conditions which
will evalute to true for all 64bit OSes and most 32bit ones.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v2:
* Use
On 19/08/2019 19:37, Julien Grall wrote:
> Hi Andrew,
>
> On 8/19/19 7:04 PM, Andrew Cooper wrote:
>> On 19/08/2019 19:01, Julien Grall wrote:
>>> Commit b5e6e1ee8da "xen/console: Don't treat NUL character as the end
>>> of the buffer" extended se
On 20/08/2019 19:03, Andreas Kinzler wrote:
> While AMD Ryzen 2700X was working perfectly in my tests with Windows
> 10, the new 3700X does not even boot a Windows HVM. With viridian=1
> you get BSOD HAL_MEMORY_ALLOCATION and with viridian=0 you get
> "multiprocessor config not supported".
>
> xl d
On 20/08/2019 19:03, Andreas Kinzler wrote:
> While AMD Ryzen 2700X was working perfectly in my tests with Windows
> 10, the new 3700X does not even boot a Windows HVM. With viridian=1
> you get BSOD HAL_MEMORY_ALLOCATION and with viridian=0 you get
> "multiprocessor config not supported".
>
> xl d
On 30/07/2019 15:54, Jan Beulich wrote:
>> @@ -622,14 +622,22 @@ static void *hvmemul_map_linear_addr(
>>}
>>
>>if ( p2mt == p2m_ioreq_server )
>> -{
>> -err = NULL;
>>goto out;
>> -}
>>
>>AS
On 20/08/2019 21:36, Andreas Kinzler wrote:
> On 20.08.2019 20:12, Andrew Cooper wrote:
>>> Xen version 4.10.2. dom0 kernel 4.13.16. The BIOS version is unchanged
>>> from 2700X (working) to 3700X (crashing).
>> So you've done a Zen v1 => Zen v2 CPU upgra
On 21/08/2019 10:13, Paul Durrant wrote:
>> -Original Message-
>> From: Roger Pau Monne
>> Sent: 21 August 2019 09:52
>> To: Paul Durrant
>> Cc: xen-devel@lists.xenproject.org; Jan Beulich ; Andrew
>> Cooper
>> ; Wei L
On 21/08/2019 11:04, Pawel Wieczorkiewicz wrote:
> diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
> index dd8b47a1fa..18b9684aeb 100644
> --- a/xen/common/livepatch_elf.c
> +++ b/xen/common/livepatch_elf.c
> @@ -55,7 +55,7 @@ static int elf_resolve_sections(struct livepatch_el
On 22/08/2019 03:06, Johnson, Ethan wrote:
> On 8/17/2019 7:04 AM, Andrew Cooper wrote:
>>> Similarly, to what extent does the dom0 (or other such
>>> privileged domain) utilize "foreign memory maps" to reach into another
>>> guest's memory? I unde
On 22/08/2019 21:57, Rich Persaud wrote:
>> On Aug 22, 2019, at 09:51, Andrew Cooper wrote:
>>
>>> On 22/08/2019 03:06, Johnson, Ethan wrote:
>>>
>>> For HVM, obviously anything that can't be virtualized natively by the
>>> hardware needs to
On 22/08/2019 16:06, Rian Quinn wrote:
> I can at least confirm that no emulation is needed to execute a Linux
> guest, even with the Xen PVH interface, but I don't think that works
> out of the box today with Xen, something we are currently working on
> and will hopefully have some more data near
On 22/08/2019 18:36, Tamas K Lengyel wrote:
>>> I've found a number of files in the Xen source tree which seem to be
>>> related to instruction/x86 platform emulation:
>>>
>>> arch/x86/x86_emulate.c
>>> arch/x86/hvm/emulate.c
>>> arch/x86/hvm/vmx/realmode.c
>>> arch/x86/hvm/svm/emulate.c
>>> arch/x
On 23/08/2019 00:06, Tamas K Lengyel wrote:
> On Thu, Aug 22, 2019 at 4:40 PM Andrew Cooper
> wrote:
>> On 22/08/2019 21:57, Rich Persaud wrote:
>>>> On Aug 22, 2019, at 09:51, Andrew Cooper wrote:
>>>>
>>>>> On 22/08/2019 03:06, Johnson, E
On 16/08/2019 18:19, Paul Durrant wrote:
> The hap_enabled() macro can determine whether the feature is available
> using the domain 'options'; there is no need for a separate flag.
>
> NOTE: Furthermore, by extending sanitiziing of the domain 'options', the
s/ii/i/
> diff --git a/xen/arch/x86/do
On 23/08/2019 13:23, Andrew Cooper wrote:
> On 16/08/2019 18:19, Paul Durrant wrote:
>> The hap_enabled() macro can determine whether the feature is available
>> using the domain 'options'; there is no need for a separate flag.
>>
>> NOTE: Furthermore, b
6 version get_page_from_gfn
> - s/%#PRI_/%PRI_/
This doesn't appear to have happened everywhere. There are two viridian
examples and one in guest_wrmsr_xen(). Can be fixed on commit.
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen
On 19/08/2019 15:26, Julien Grall wrote:
> diff --git a/xen/include/public/vcpu.h b/xen/include/public/vcpu.h
> index 3623af932f..dc4c6a72a0 100644
> --- a/xen/include/public/vcpu.h
> +++ b/xen/include/public/vcpu.h
> @@ -182,7 +182,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_set_singleshot_timer_t);
> */
We are now down to 0 SVM maintainers who are active and wish to hold the
position. Fall back to general x86 maintenance until this position changes.
Signed-off-by: Andrew Cooper
---
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: George
found is at
the reset vector for a firmware which doesn't start in a
virtualisation-aware way.
Given how big a hammer WBINVD is, I reckon we should just nop it out.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
> ---
> v2: Use cache_op() as hook name. Convert mac
ead. That eventually resulted in a crash
> during IOMMU construction on systems without shared PTs enabled.
>
> While here fixup compat M2P entries as well.
>
> Signed-off-by: Igor Druzhinin
Reviewed-by: Andrew Cooper
___
Xen-devel ma
On 27/08/2019 11:59, Juergen Gross wrote:
> +static void *
> +sched_idle_alloc_vdata(const struct scheduler *ops, struct vcpu *v,
> + void *dd)
> +{
> +/* Any non-NULL pointer is fine here. */
> +return (void *)1UL;
As an observation, the vdata interface (and others,
On 27/08/2019 11:44, Andrew Cooper wrote:
>> I was also uncertain about the new cache_flush_permitted() instance -
>> generally I think it wouldn't be too bad if we allowed line flushes in
>> all cases, in which case the checks in the ->wbinvd_intercept() handlers
>
On 01/07/2019 12:56, Jan Beulich wrote:
> Rev 035 of Intel's ISA extensions document does not state intercept
> behavior for the insn (I've been in-officially told that the distinction
unofficially.
> is going to be by exit qualification, as I would have assumed
> considering that this way it's s
lich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
isn't terribly useful.
Preferably with this done, Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
iour to speed up handling of INV{EPT,VPID}
which trap unconditionally.
However, this is how the instruction is described in the SDM, and
INVPCID should usually execute without trapping, so the unconditional
read should be fine.
Reviewed-by: Andrew Cooper
... rather than leaving the user with no hint as to where to debug next.
Signed-off-by: Andrew Cooper
---
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
---
livepatch-build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/livepatch-build b/livepatch-build
index 7068faf
On 01/07/2019 12:58, Jan Beulich wrote:
> Note that the ISA extensions document revision 035 doesn't specify
> exception behavior for ModRM.mod != 0b11; assuming #UD here.
This has moved into the main SDM now. These instructions don't make
sense with reg/reg encodings, so I expect that encoding s
On 27/08/2019 16:08, Jan Beulich wrote:
> On 27.08.2019 16:47, Andrew Cooper wrote:
>> On 01/07/2019 12:56, Jan Beulich wrote:
>>> --- a/xen/arch/x86/pv/emul-priv-op.c
>>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>>> @@ -1121,7 +1121,7 @@ static int write_msr(unsign
On 27/08/2019 16:53, Jan Beulich wrote:
> On 27.08.2019 17:31, Andrew Cooper wrote:
>> On 01/07/2019 12:57, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -9124,6 +9126,48 @@ x86_e
On 27/08/2019 11:44, Andrew Cooper wrote:
>> I was also uncertain about the new cache_flush_permitted() instance -
>> generally I think it wouldn't be too bad if we allowed line flushes in
>> all cases, in which case the checks in the ->wbinvd_intercept() handlers
>
On 28/08/2019 08:14, Jan Beulich wrote:
> On 27.08.2019 19:27, Andrew Cooper wrote:
>> On 27/08/2019 16:53, Jan Beulich wrote:
>>> On 27.08.2019 17:31, Andrew Cooper wrote:
>>>> On 01/07/2019 12:57, Jan Beulich wrote:
>>>>> --- a/xen/arch/x86/x86_e
801 - 900 of 11868 matches
Mail list logo
