Signed-off-by: Jan Beulich
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -88,6 +88,26 @@ Braces should be omitted for blocks with
if ( condition )
single_statement();
+Types
+-
+
+Use basic C types and C standard mandated typedef-s where possible (and
+with preference in this order). This
On 02/16/2018 01:17 PM, Jan Beulich wrote:
On 16.02.18 at 11:22, wrote:
>> The emulation layers of Xen lack PCID support, and as we only offer
>> PCID to HAP guests, all writes to CR3 are handled by hardware,
>> except when introspection is involved. Consequently, trying to set
>> CR3 when th
>>> On 19.02.18 at 09:48, wrote:
> On 02/16/2018 01:17 PM, Jan Beulich wrote:
> On 16.02.18 at 11:22, wrote:
>>> The emulation layers of Xen lack PCID support, and as we only offer
>>> PCID to HAP guests, all writes to CR3 are handled by hardware,
>>> except when introspection is involved. Co
Ping?
> On Vi, 2017-10-06 at 13:02 +0300, Alexandru Isaila wrote:
> >
> > This patch adds the hvm_save_one_cpu_ctxt() function.
> > It optimizes by only pausing the vcpu on all HVMSR_PER_VCPU save
> > callbacks where only data for one VCPU is required.
> >
> > Signed-off-by: Alexandru Isaila
> >
>
On 02/19/2018 10:53 AM, Jan Beulich wrote:
On 19.02.18 at 09:48, wrote:
>> On 02/16/2018 01:17 PM, Jan Beulich wrote:
>> On 16.02.18 at 11:22, wrote:
The emulation layers of Xen lack PCID support, and as we only offer
PCID to HAP guests, all writes to CR3 are handled by hardwar
flight 119582 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
118324
test-amd64-
On 24/01/18 16:26, George Dunlap wrote:
> On Wed, Jan 24, 2018 at 3:20 PM, Juergen Gross wrote:
>> On 24/01/18 16:07, George Dunlap wrote:
>>> On Wed, Jan 24, 2018 at 2:10 PM, Boris Ostrovsky
>>> wrote:
On 01/24/2018 07:06 AM, Juergen Gross wrote:
> On 24/01/18 11:54, Roger Pau Monné wro
Add pvh_get_root_pointer() for Xen PVH guests to communicate the
address of the RSDP table given to the kernel via Xen start info.
This makes the kernel boot again in PVH mode after on recent Xen the
RSDP was moved to higher addresses. So up to that change it was pure
luck that the legacy method t
The Xen PVH boot protocol passes vital information to the kernel via
a start_info block. One of the data transferred is the physical address
of the RSDP table.
Unfortunately PVH support in the kernel didn't use that passed address
for RSDP, but relied on the legacy mechanism searching for the RSDP
Add a new struct x86_init_acpi to x86_init_ops. For now it contains
only one init function to get the RSDP table address.
Cc: # 4.11
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/acpi.h | 7 +++
arch/x86/include/asm/x86_init.h | 9 +
arch/x86/kernel/x86_init.c | 5 +
Add an architecture specific function to get the address of the RSDP
table. Per default it will just return 0 indicating falling back to
the current mechanism.
Cc: # 4.11
Signed-off-by: Juergen Gross
---
drivers/acpi/osl.c | 5 -
include/linux/acpi.h | 7 +++
2 files changed, 11 inser
On 19/02/18 10:47, Sander Eikelenboom wrote:
> On 24/01/18 16:26, George Dunlap wrote:
>> On Wed, Jan 24, 2018 at 3:20 PM, Juergen Gross wrote:
>>> On 24/01/18 16:07, George Dunlap wrote:
On Wed, Jan 24, 2018 at 2:10 PM, Boris Ostrovsky
wrote:
> On 01/24/2018 07:06 AM, Juergen Gross
On 2/19/2018 11:09 AM, Juergen Gross wrote:
The Xen PVH boot protocol passes vital information to the kernel via
a start_info block. One of the data transferred is the physical address
of the RSDP table.
Unfortunately PVH support in the kernel didn't use that passed address
for RSDP, but relied
flight 119602 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119602/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
Raw policy contains the actual values from H/W MSRs. Add PLATFORM_INFO
msr to the policy during probe_cpuid_faulting().
Host policy may have certain features disabled if Xen decides not
to use them. For now, make Host policy equal to Raw policy with
cpuid_faulting availability dependent on X86_FEA
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
The config register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
This is based on Linux commit 79717e4ac09c, written by Andre Pr
Jan Beulich writes ("[PATCH RFC] CODING_STYLE: document intended usage of
types"):
> +Types
> +-
> +
> +Use basic C types and C standard mandated typedef-s where possible (and
> +with preference in this order). This in particular means to avoid u8,
> +u16, etc despite those types continuing t
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
The target register handlers are v2 emulation specific, so their
implementation lives entirely in vgic-mmio-v2.c.
We copy the old VGIC behaviour of assigning an IRQ to the first VCPU
set in the target mask instead of making it possibly pending o
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
Triggering an IPI via this register is v2 specific, so the
implementation lives entirely in vgic-mmio-v2.c.
This is based on Linux commit 55cc01fb9004, written by Andre Przywara.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic/vgic-mmio-v2.c
On 19/02/18 07:50, Jan Beulich wrote:
On 16.02.18 at 18:02, wrote:
>> On 16/02/18 16:21, Jan Beulich wrote:
>> On 16.02.18 at 16:50, wrote:
On 16/02/18 08:00, Jan Beulich wrote:
On 15.02.18 at 17:53, wrote:
>> On 15/02/18 16:03, Jan Beulich wrote:
>>> --- a/xen/arc
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
As this register is v2 specific, its implementation lives entirely
in vgic-mmio-v2.c.
This register allows setting the source mask of an IPI.
This is based on Linux commit ed40213ef9b0, written by Andre Przywara.
Signed-off-by: Andre Przywara
---
flight 119592 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken in 119521
build-armhf-pvops5
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
The VGIC supports virtual IRQs to be connected to a hardware IRQ, so
when a guest EOIs the virtual interrupt, it affects the state of that
corresponding interrupt on the hardware side at the same time.
Implement the interface that the Xen arch/core co
Hi,
On 16/02/18 15:39, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> Create vgic-mmio-v2.c to describe GICv2 emulation specific handlers
>> using the initializer macros provided by the VGIC MMIO framework.
>> Provide a function to register the GICv2 distributor r
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
When we dump guest state on the Xen console, we also print the state of
IRQs that are on a VCPU.
Add the code to dump the state of an IRQ handled by the new VGIC.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic/vgic.c | 13 +
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
The target register handlers are v2 emulation specific, so their
implementation lives entirely in vgic-mmio-v2.c.
We copy the old VGIC behaviour of assigning an IRQ to the first VCPU
set in the target mask instead of making it possibly pending on
mult
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
The Xen core code requires an interrupt controller emulation to implement
arch_move_irqs(), to move the affinity of an hardware mapped virtual IRQ
to another core. In the moment we don't implement this
physical-follow-virtual regime in our new VGIC, s
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
This patch implements the function which is called by Xen when it wants
to register the virtual GIC.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic/vgic-init.c | 62 +++
xen/arch/arm/vgic/vgic.h
Hi,
On 16/02/18 16:57, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> As the enable register handlers are shared between the v2 and v3
>> emulation, their implementation goes into vgic-mmio.c, to be easily
>> referenced from the v3 emulation as well later.
>>
>> S
>>> On 16.02.18 at 18:11, wrote:
> On 16/02/18 15:39, Jan Beulich wrote:
>> Since both kernel and user mode run in ring 3, they run in the same
>> "predictor mode". While the kernel could take care of this itself, doing
>> so would be yet another item distinguishing PV from native. Additionally
>>
>>> On 19.02.18 at 12:46, wrote:
> Jan Beulich writes ("[PATCH RFC] CODING_STYLE: document intended usage of
> types"):
>> +Types
>> +-
>> +
>> +Use basic C types and C standard mandated typedef-s where possible (and
>> +with preference in this order). This in particular means to avoid u8,
>
Hi all,
This series more capabilities to the common list. I've tested and added
CPUID and EVENT INTERRUPT to the list.
Cheers,
Alexandru Isaila
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xe
Signed-off-by: Alexandru Isaila
---
xen/include/asm-x86/monitor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 59a2610..7a9e1e8 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
At this moment the CPUID events for the AMD architecture are not
forwarded to the monitor layer.
This patch adds the CPUID event to the common capabilities and then
forwards the event to the monitor layer.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/svm/svm.c| 8 +++-
xen/inclu
On 02/19/2018 03:07 PM, Alexandru Isaila wrote:
> Signed-off-by: Alexandru Isaila
> ---
> xen/include/asm-x86/monitor.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index 59a2610..7a9e1e8 100644
> --- a/x
>>> On 16.02.18 at 18:46, wrote:
> We're noticing a reproducible system boot hang on certain
> post-Skylake platforms where the BIOS is configured in
> legacy boot mode with x2APIC disabled. The system stalls
> immediately after writing the first SMP initialization
> sequence into APIC ICR.
>
> T
On 19/02/18 08:44, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
>
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -88,6 +88,26 @@ Braces should be omitted for blocks with
> if ( condition )
> single_statement();
>
> +Types
> +-
> +
> +Use basic C types and C standard mandated typedef
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
This patch allocates and initializes the data structures used to model
the vgic distributor and virtual cpu interfaces. At that stage the
number of IRQs and number of virtual CPUs is frozen.
This is based on Linux commit ad275b8bb1e6, written by Eric
The ELF note the shim build inserts causes mkelf32 to choke on the
second program header. However, the output of mkelf32 isn't really
needed when building inside tools/firmware/ - an attempt to build it is
made solely because of a wrong dependency.
Further changes to the make logic will be needed
>>> On 19.02.18 at 14:12, wrote:
> On 19/02/18 08:44, Jan Beulich wrote:
>> --- a/CODING_STYLE
>> +++ b/CODING_STYLE
>> @@ -88,6 +88,26 @@ Braces should be omitted for blocks with
>> if ( condition )
>> single_statement();
>>
>> +Types
>> +-
>> +
>> +Use basic C types and C standard ma
Jan Beulich writes ("Re: [PATCH RFC] CODING_STYLE: document intended usage of
types"):
> Types to be used for addresses - from a really generic pov -
> depend on the architecture. Iirc there are some where a signed
> type is the more natural representation, while on x86 and ARM
> we'd certainly us
On Mon, Feb 19, 2018 at 12:27 PM, Rafael J. Wysocki
wrote:
> On 2/19/2018 11:09 AM, Juergen Gross wrote:
>>
>> The Xen PVH boot protocol passes vital information to the kernel via
>> a start_info block. One of the data transferred is the physical address
>> of the RSDP table.
>>
>> Unfortunately P
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
At the moment we allocate exactly one page for struct vcpu on ARM, also
have a check in place to prevent it growing beyond 4KB.
As the struct includes the state of all 32 private (per-VCPU) interrupts,
we are at 3840 bytes on arm64 at the moment alrea
flight 119626 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119626/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 119569 pass
in 119626
test-amd64-amd64-amd
On 19/02/18 12:41, Andre Przywara wrote:
Hi,
Hi,
On 16/02/18 16:57, Julien Grall wrote:
On 09/02/18 14:39, Andre Przywara wrote:
+ spin_lock_irqsave(&desc->lock, flags);
+ if ( enable )
+ {
+ gic_set_irq_type(desc, irq_type == VGIC_CONFIG_LEVEL ?
+ IRQ_TYPE
When indirect_thunk_asm.h is instantiated directly into assembly files
CONFIG_INDIRECT_THUNK might not be defined, and thus using .if against
it is wrong.
Add a check to define CONFIG_INDIRECT_THUNK to 0 if not defined, so
that using .if CONFIG_INDIRECT_THUNK is always correct.
This suppresses th
Hello,
The following series re-enable the integrated clang assembler when the
features required in order to build Xen are available.
First 2 patches remove the unconditional addition of -no-integrated-as
to CFLAGS (only adding it to AFLAGS like it was done before). Finally
patches 3 and 4 remove
If the assembler is not used. This happens when using cc -E or cc -S
for example. GCC will just ignore the -Wa,... when the assembler is
not called, but clang will complain loudly and fail.
Also enable passing -Wa,-I$(BASEDIR)/include to clang now that it's
safe to do so.
Signed-off-by: Roger Pau
Or else switch off the integrated assembler. This is relevant for
older clang versions which integrated assembler don't support .skip
with labels.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stab
If the required features are meet by the integrated clang assembler
(support for .includes and propagation of .macro-s between asm()-s)
do not disable it.
Only switch off the non integrated assembler for assembly file, like
it was done prior to "x86: Support indirect thunks from assembly
code".
S
We're noticing a reproducible system boot hang on certain
post-Skylake platforms where the BIOS is configured in
legacy boot mode with x2APIC disabled. The system stalls
immediately after writing the first SMP initialization
sequence into APIC ICR.
The cause of the problem is watchdog NMI handler
On 19/02/18 14:23, Igor Druzhinin wrote:
> We're noticing a reproducible system boot hang on certain
> post-Skylake platforms where the BIOS is configured in
These are Skylake, not post-Skylake.
> legacy boot mode with x2APIC disabled. The system stalls
> immediately after writing the first SMP i
On Mon, Feb 19, 2018 at 06:23:09AM -0700, Jan Beulich wrote:
> The ELF note the shim build inserts causes mkelf32 to choke on the
> second program header. However, the output of mkelf32 isn't really
> needed when building inside tools/firmware/ - an attempt to build it is
> made solely because of a
On Fri, Feb 16, 2018 at 12:49:57PM +, Andrew Cooper wrote:
> On 16/02/18 12:10, Roger Pau Monne wrote:
> > diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
> > index d93166fb92..811d4c10ae 100644
> > --- a/xen/include/asm-x86/hvm/vcpu.h
> > +++ b/xen/include/asm-x86/
On 19/02/18 15:04, Roger Pau Monné wrote:
> On Fri, Feb 16, 2018 at 12:49:57PM +, Andrew Cooper wrote:
>> On 16/02/18 12:10, Roger Pau Monne wrote:
>>> diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
>>> index d93166fb92..811d4c10ae 100644
>>> --- a/xen/include/asm-
>>> On 19.02.18 at 15:56, wrote:
> I also assume that passing --notes to mkelf32 when building the shim
> (regardless of whether the linker supports build ID or not) should
> also fix the issue?
I guess so, but I simply didn't have the time to figure out (and test)
yet another Makefile adjustment
>>> On 19.02.18 at 14:39, wrote:
> Jan Beulich writes ("Re: [PATCH RFC] CODING_STYLE: document intended usage of
> types"):
>> Types to be used for addresses - from a really generic pov -
>> depend on the architecture. Iirc there are some where a signed
>> type is the more natural representation,
>>> On 19.02.18 at 15:23, wrote:
> We're noticing a reproducible system boot hang on certain
> post-Skylake platforms where the BIOS is configured in
> legacy boot mode with x2APIC disabled. The system stalls
> immediately after writing the first SMP initialization
> sequence into APIC ICR.
>
> T
On 19/02/18 15:18, Jan Beulich wrote:
On 19.02.18 at 15:23, wrote:
>> We're noticing a reproducible system boot hang on certain
>> post-Skylake platforms where the BIOS is configured in
>> legacy boot mode with x2APIC disabled. The system stalls
>> immediately after writing the first SMP init
On Mon, Feb 19, 2018 at 6:07 AM, Alexandru Isaila
wrote:
> At this moment the CPUID events for the AMD architecture are not
> forwarded to the monitor layer.
>
> This patch adds the CPUID event to the common capabilities and then
> forwards the event to the monitor layer.
>
> Signed-off-by: Alexan
On 02/19/2018 05:25 PM, Tamas K Lengyel wrote:
> On Mon, Feb 19, 2018 at 6:07 AM, Alexandru Isaila
> wrote:
>> At this moment the CPUID events for the AMD architecture are not
>> forwarded to the monitor layer.
>>
>> This patch adds the CPUID event to the common capabilities and then
>> forwards t
>>> On 19.02.18 at 16:20, wrote:
> On 19/02/18 15:18, Jan Beulich wrote:
> On 19.02.18 at 15:23, wrote:
>>> We're noticing a reproducible system boot hang on certain
>>> post-Skylake platforms where the BIOS is configured in
>>> legacy boot mode with x2APIC disabled. The system stalls
>>> imm
Hi,
On 16/02/18 17:16, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> The pending register handlers are shared between the v2 and v3
>> emulation, so their implementation goes into vgic-mmio.c, to be easily
>> referenced from the v3 emulation as well later.
>> For
>>> On 19.02.18 at 12:29, wrote:
> Raw policy contains the actual values from H/W MSRs. Add PLATFORM_INFO
> msr to the policy during probe_cpuid_faulting().
>
> Host policy may have certain features disabled if Xen decides not
> to use them. For now, make Host policy equal to Raw policy with
> cp
>>> On 19.02.18 at 16:25, wrote:
> On Mon, Feb 19, 2018 at 6:07 AM, Alexandru Isaila
> wrote:
>> @@ -1822,7 +1823,12 @@ static void svm_vmexit_do_cpuid(struct cpu_user_regs
>> *regs)
>> regs->rcx = res.c;
>> regs->rdx = res.d;
>>
>> -__update_guest_eip(regs, inst_len);
>> +rc
On 19/02/18 15:32, Andre Przywara wrote:
Hi,
Hi Andre,
On 16/02/18 17:16, Julien Grall wrote:
On 09/02/18 14:39, Andre Przywara wrote:
+
+ /* Loop over all IRQs affected by this read */
+ for ( i = 0; i < len * 8; i++ )
+ {
+ struct vgic_irq *irq = vgic_get_irq(vcpu->domai
>>> On 19.02.18 at 15:16, wrote:
> ---
> xen/arch/x86/Makefile | 6 +++---
> xen/arch/x86/Rules.mk | 5 +
> xen/include/Makefile | 2 +-
> 3 files changed, 5 insertions(+), 8 deletions(-)
What about the "%.i: %.c", "%.s: %.c", and "%.s: %.S" rules
near the end of xen/Rules.mk?
Jan
__
Hi,
On 19/02/18 13:21, Julien Grall wrote:
> Hi,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> This patch allocates and initializes the data structures used to model
>> the vgic distributor and virtual cpu interfaces. At that stage the
>> number of IRQs and number of virtual CPUs is frozen.
>>
On 19/02/18 15:53, Andre Przywara wrote:
Hi,
On 19/02/18 13:21, Julien Grall wrote:
Hi,
On 09/02/18 14:39, Andre Przywara wrote:
This patch allocates and initializes the data structures used to model
the vgic distributor and virtual cpu interfaces. At that stage the
number of IRQs and numbe
>>> On 19.02.18 at 15:16, wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -157,9 +157,9 @@ ifndef XEN_HAS_CHECKPOLICY
> endif
>
> # as-insn: Check whether assembler supports an instruction.
> -# Usage: cflags-y += $(call as-insn "insn",option-yes,option-no)
> +# Usage: cflags-y += $(call as-in
On Mon, Feb 19, 2018 at 08:43:51AM -0700, Jan Beulich wrote:
> >>> On 19.02.18 at 15:16, wrote:
> > ---
> > xen/arch/x86/Makefile | 6 +++---
> > xen/arch/x86/Rules.mk | 5 +
> > xen/include/Makefile | 2 +-
> > 3 files changed, 5 insertions(+), 8 deletions(-)
>
> What about the "%.i: %.c",
>>> On 19.02.18 at 15:16, wrote:
> When indirect_thunk_asm.h is instantiated directly into assembly files
> CONFIG_INDIRECT_THUNK might not be defined, and thus using .if against
> it is wrong.
>
> Add a check to define CONFIG_INDIRECT_THUNK to 0 if not defined, so
> that using .if CONFIG_INDIREC
>>> On 19.02.18 at 15:16, wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -72,7 +72,11 @@ AFLAGS-y+= -D__ASSEMBLY__
>
> # Older clang's built-in assembler doesn't understand .skip with labels:
> # https://bugs.llvm.org/show_bug.cgi?id=27369
> -AFLAGS-$(clang) +=
On Mon, Feb 19, 2018 at 06:23:09AM -0700, Jan Beulich wrote:
> The ELF note the shim build inserts causes mkelf32 to choke on the
> second program header. However, the output of mkelf32 isn't really
> needed when building inside tools/firmware/ - an attempt to build it is
> made solely because of a
On Mon, 19 Feb 2018 14:48:37 +
Andrew Cooper wrote:
>On 19/02/18 14:23, Igor Druzhinin wrote:
>> We're noticing a reproducible system boot hang on certain
>> post-Skylake platforms where the BIOS is configured in
>
>These are Skylake, not post-Skylake.
Well, strictly speaking, any platform
>>> On 19.02.18 at 17:05, wrote:
> On Mon, Feb 19, 2018 at 08:43:51AM -0700, Jan Beulich wrote:
>> >>> On 19.02.18 at 15:16, wrote:
>> > ---
>> > xen/arch/x86/Makefile | 6 +++---
>> > xen/arch/x86/Rules.mk | 5 +
>> > xen/include/Makefile | 2 +-
>> > 3 files changed, 5 insertions(+), 8 de
On Mon, Feb 19, 2018 at 09:10:42AM -0700, Jan Beulich wrote:
> >>> On 19.02.18 at 15:16, wrote:
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -72,7 +72,11 @@ AFLAGS-y+= -D__ASSEMBLY__
> >
> > # Older clang's built-in assembler doesn't understand .skip with labels:
> > #
On Mon, Feb 19, 2018 at 09:14:30AM -0700, Jan Beulich wrote:
> >>> On 19.02.18 at 17:05, wrote:
> > On Mon, Feb 19, 2018 at 08:43:51AM -0700, Jan Beulich wrote:
> >> >>> On 19.02.18 at 15:16, wrote:
> >> > ---
> >> > xen/arch/x86/Makefile | 6 +++---
> >> > xen/arch/x86/Rules.mk | 5 +
> >> >
On Mon, Feb 19, 2018 at 08:57:15AM -0700, Jan Beulich wrote:
> >>> On 19.02.18 at 15:16, wrote:
> > --- a/xen/arch/x86/Rules.mk
> > +++ b/xen/arch/x86/Rules.mk
> > @@ -44,3 +44,17 @@ endif
> >
> > # Set up the assembler include path properly for older toolchains.
> > CFLAGS += -Wa,-I$(BASEDIR)
Hello,
Im getting this Hypercall [op = 0x0040001a ] on xen trace but can't figure
out which operation this is.
Using old Xen 4.4.1.
Looking at documentation and also using grep into source code couldn't
figure out which hypercall this is.
Can someone help clarify this?
--
Atenciosamente,
Char
On Mon, Feb 19, 2018 at 04:23:33PM +, Charles Gonçalves wrote:
> Hello,
>
> Im getting this Hypercall [op = 0x0040001a ] on xen trace but can't figure
> out which operation this is.
I guess 0x1a is the hypercall number (26 in decimal), which matches to
__HYPERVISOR_mmuext_op. See xen/include
>>> On 15.02.18 at 13:52, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -510,6 +510,8 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
> void write_ptbase(struct vcpu *v)
> {
> write_cr3(v->arch.cr3);
> +/* Setting copy_l4 unconditionally does no harm. */
> +get_cpu_inf
On Tue, Feb 13, 2018 at 05:49:59PM -0800, Dongwon Kim wrote:
> This patch series contains the implementation of a new device driver,
> hyper_DMABUF driver, which provides a way to expand the boundary of
> Linux DMA-BUF sharing to across different VM instances in Multi-OS platform
> enabled by a Hyp
flight 119657 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119657/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, Feb 19, 2018 at 02:16:18PM +, Roger Pau Monne wrote:
> If the required features are meet by the integrated clang assembler
^ met
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject
On Mon, Feb 19, 2018 at 04:23:33PM +, Charles Gonçalves wrote:
> Hello,
>
> Im getting this Hypercall [op = 0x0040001a ] on xen trace but can't figure
> out which operation this is.
>
> Using old Xen 4.4.1.
> Looking at documentation and also using grep into source code couldn't
> figure ou
On Fri, Feb 16, 2018 at 04:35:14PM -0500, Rich Persaud wrote:
> On Feb 16, 2018, at 14:02, Andrew Cooper wrote:
> >
> > IMO, PCI Passthrough is a trainwreck, and it is a miracle it functions
> > at all.
>
> Would that statement apply to other hypervisors like KVM, VMware ESX or
> Hyper-V, i.e.
On 19/02/18 17:59, Jan Beulich wrote:
On 15.02.18 at 13:52, wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -510,6 +510,8 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>> void write_ptbase(struct vcpu *v)
>> {
>> write_cr3(v->arch.cr3);
>> +/* Setting copy_l4 uncon
On 16/02/18 20:54, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 16, 2018 at 07:02:39PM +, Andrew Cooper wrote:
>> On 16/02/18 18:51, Marek Marczykowski-Górecki wrote:
>>> On Fri, Feb 16, 2018 at 05:52:50PM +, Andrew Cooper wrote:
On 16/02/18 17:48, Marek Marczykowski-Górecki wrote:
On 16/02/18 20:02, Andrew Cooper wrote:
> On 16/02/18 18:51, Marek Marczykowski-Górecki wrote:
>> On Fri, Feb 16, 2018 at 05:52:50PM +, Andrew Cooper wrote:
>>> On 16/02/18 17:48, Marek Marczykowski-Górecki wrote:
Hi,
As in the subject, the guest crashes on boot, before kernel ou
On Mon, Feb 19, 2018 at 06:23:40PM +0100, Juergen Gross wrote:
> On 16/02/18 20:54, Marek Marczykowski-Górecki wrote:
> > Just before the BUG(), there is a call to xen_raw_console_write(). But
> > apparently it was too early...
>
> Depends.
>
> With a debug enabled hypervisor and appropriate log
On Mon, Feb 19, 2018 at 05:13:11PM +, Wei Liu wrote:
> On Mon, Feb 19, 2018 at 04:23:33PM +, Charles Gonçalves wrote:
> > Hello,
> >
> > Im getting this Hypercall [op = 0x0040001a ] on xen trace but can't figure
> > out which operation this is.
> >
> > Using old Xen 4.4.1.
> > Looking at
On 19/02/18 18:29, Marek Marczykowski-Górecki wrote:
> On Mon, Feb 19, 2018 at 06:23:40PM +0100, Juergen Gross wrote:
>> On 16/02/18 20:54, Marek Marczykowski-Górecki wrote:
>>> Just before the BUG(), there is a call to xen_raw_console_write(). But
>>> apparently it was too early...
>>
>> Depends.
On 19/02/18 17:46, Juergen Gross wrote:
> On 19/02/18 18:29, Marek Marczykowski-Górecki wrote:
>> On Mon, Feb 19, 2018 at 06:23:40PM +0100, Juergen Gross wrote:
>>> On 16/02/18 20:54, Marek Marczykowski-Górecki wrote:
Just before the BUG(), there is a call to xen_raw_console_write(). But
We're noticing a reproducible system boot hang on certain
Skylake platforms where the BIOS is configured in legacy
boot mode with x2APIC disabled. The system stalls immediately
after writing the first SMP initialization sequence into APIC ICR.
The cause of the problem is watchdog NMI handler execu
flight 119638 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119638/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 10 debian-install fail REGR. vs. 119582
test-armhf-armhf-xl
flight 119669 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119669/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Sat, 17 Feb 2018, Julien Grall wrote:
> Hi,
>
> On 17/02/2018 00:31, Stefano Stabellini wrote:
> > On Fri, 16 Feb 2018, Julien Grall wrote:
> > > On 16/02/2018 21:15, Stefano Stabellini wrote:
> > > > On Fri, 16 Feb 2018, Julien Grall wrote:
> > > > > On 16/02/2018 20:50, Stefano Stabellini wro
On 19/02/2018 20:28, Stefano Stabellini wrote:
On Sat, 17 Feb 2018, Julien Grall wrote:
Hi,
On 17/02/2018 00:31, Stefano Stabellini wrote:
On Fri, 16 Feb 2018, Julien Grall wrote:
On 16/02/2018 21:15, Stefano Stabellini wrote:
On Fri, 16 Feb 2018, Julien Grall wrote:
On 16/02/2018 20:50,
On Mon, 19 Feb 2018, Julien Grall wrote:
> On 19/02/2018 20:28, Stefano Stabellini wrote:
> > On Sat, 17 Feb 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 17/02/2018 00:31, Stefano Stabellini wrote:
> > > > On Fri, 16 Feb 2018, Julien Grall wrote:
> > > > > On 16/02/2018 21:15, Stefano Stabel
1 - 100 of 125 matches
Mail list logo
