On Tue, 2017-03-28 at 19:30 +0100, Julien Grall wrote:
> Hi Dario,
>
Hey,
> On 02/02/17 13:32, Dario Faggioli wrote:
> > On Thu, 2017-02-02 at 13:26 +, Julien Grall wrote:
> > >
> > Ok, sign me up for it then. We absolutely want it for 4.9, I agree.
>
> Do you have any update on this? This
On 03/29/17 21:11 -0700, Dan Williams wrote:
> On Sun, Mar 19, 2017 at 5:09 PM, Haozhong Zhang
> wrote:
> > xen-ndctl is a tool for users in Dom0 to setup the host pmem with Xen
> > hypervisor. It's used to specify the storage, which is either the
> > regular RAM or a pmem range, to manage the spe
flight 106989 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106989/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 libvirt-buildfail REGR. vs. 106829
Tests which did not suc
On Wed, Mar 29, 2017 at 03:39:10PM +0100, Roger Pau Monne wrote:
> Hello,
>
> This patch series introduce support for having a variable number of entries in
> vIO APICs, and also having a variable number of vIO APICs per domain. This
> functionality is not used by unprivileged guests, that are sti
On 03/29/17 21:20 -0700, Dan Williams wrote:
> On Sun, Mar 19, 2017 at 5:09 PM, Haozhong Zhang
> wrote:
> > This is v2 RFC patch series to add vNVDIMM support to HVM domains.
> > v1 can be found at
> > https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg00424.html.
> >
> > No label an
flight 106988 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106988/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d3017dd96bf96521cbb87a26bb9dd09f8aa5811d
baseline version:
ovmf 6e7ec25aaaf0dfc2b4c84
This patch is based on the implementation of ARM64, it introduces
alternative runtime patching to ARM32. This allows to patch assembly
instruction at runtime to either fix hardware bugs or optimize for
certain hardware features on ARM32 platform.
Xen hypervisor is using ARM execution state only on
Xen will do exception syndrome check while some types of exception
take place in EL2. The syndrome check code read the ESR_EL2 register
directly, but in some situation this register maybe overridden by
nested exception.
For example, if we re-enable IRQ before reading ESR_EL2 which means
Xen may en
The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
DomU in vcpu_initialise, we didn't know the domain's address size
information. We had to use compatible flags to initialize HCR_EL2,
and set HCR_RW for 64-bit domain
Different domains may have different HCR_EL2 flags. For example, the
64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
we give each domain a default HCR_EL2 value and save it in the vCPU's
context.
HCR_EL2 register has only one bit can be updated automatically without
explicit wr
We will set HCR_EL2 for each domain individually at the place where each
domain is created. vwfi will affect the behavior of VM trap. Initialize
the HCR_EL2 in init_traps is a generic setting for AT translations while
creating dom0. After dom0 has been created, the HCR_EL2 will use the saved
value
In order to distinguish guest-generated SErrors from hypervisor-generated
SErrors we have to place SError checking code in every EL1 -> EL2 paths.
That will cause overhead on entries due to dsb/isb.
However, not all platforms want to categorize SErrors. For example, a host
that is running with tru
From XSA-201, we know that, a guest could trigger SErrors when accessing
memory mapped HW in a non-conventional way. In the patches for XSA-201,
we crash the guest when we captured such asynchronous aborts to avoid data
corruption.
In order to distinguish guest-generated SErrors from hypervisor-ge
In the later patches of this series, we want to use the alternative
patching framework to avoid checking serror_op in every entries.
So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for
serror_op. When serror_op is not equal to SERROR_DIVERSE, this
feature will be set to cpu_hwcaps.
Cur
In the past, we'll set the HCR_EL2 while Xen is booting in init_traps.
And the command line parameter "vwfi" will affect the value of setting
HCR_EL2. So we placed the parse_vwfi in trap.c to avoid exporting vwfi
to other source files.
But in previous patch of this series, we had removed the HCR_E
Currently, ARM32 and ARM64 has different SError exception handlers.
These handlers include lots of code to check SError handle options
and code to distinguish guest-generated SErrors from hypervisor
SErrors.
The new helpers: do_trap_guest_serror and do_trap_hyp_serror are
wrappers of __do_trap_ser
The guest generated external data/instruction aborts can be treated
as guest SErrors. We already have a handler to handle the SErrors,
so we can reuse this handler to handle guest external aborts.
Signed-off-by: Wei Chen
Reviewed-by: Stefano Stabellini
---
xen/arch/arm/traps.c | 14 ++--
When guest triggers async aborts, in most platform, such aborts
will be routed to hypervisor. But we don't want the hypervisor
to handle such aborts, so we have to route such aborts back to
the guest.
This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
route such aborts back to the gu
Currently, we masked the Abort/SError bit in Xen exception entries.
So Xen could not capture any Abort/SError while it's running.
Now, Xen has the ability to handle the Abort/SError, we should unmask
the Abort/SError bit by default to let Xen capture Abort/SError while
it's running.
But in order t
In previous patches, we have provided the ability to synchronize
SErrors in exception entries. But we haven't synchronized SErrors
while returning to guest and doing context switch.
So we still have two risks:
1. Slipping hypervisor SErrors to guest. For example, hypervisor
triggers a SError wh
If there is a pending SError while we are doing context switch, if the
SError handle option is "FORWARD", We have to guranatee this serror to
be caught by current vCPU, otherwise it will be caught by next vCPU and
be forwarded to this wrong vCPU.
So we have to synchronize SError before switch to n
If there is a pending SError while we're returning from trap. If the
SError handle option is "DIVERSE", we have to prevent slipping this
hypervisor SError to guest. So we have to use the dsb/isb to guarantee
that the pending hypervisor SError would be caught in hypervisor before
return to guest.
S
We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError. This will add overhead to check
the option at every trap.
The ARM3
We want to move part of SErrors checking code from hyp_error assembly code
to a function. This new function will use this macro to distinguish the
guest SErrors from hypervisor SErrors. So we have to move this macro to
common header.
The VABORT_GEN_BY_GUEST macro used two symbols abort_guest_exit_
The HCR_EL2.VSE (HCR.VA for aarch32) bit can be used to generate a
virtual abort to guest. The HCR_EL2.VSE bit has a peculiar feature
of getting cleared when the guest has taken the abort (this is the
only bit that behaves as such in HCR_EL2 register).
This means that if we set the HCR_EL2.VSE bit
We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError. This will add overhead to check
the option at every trap.
The ARM6
We have introduced two helpers to handle the guest/hyp SErrors:
do_trap_guest_serror and do_trap_guest_hyp_serror. These handlers
can take the role of do_trap_guest_serror and reduce the assembly
code in the same time. So we use these two helpers to replace it
and drop it now.
Signed-off-by: Wei C
This run is configured for baseline tests only.
flight 71121 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 3 host-install(
On Wed, Mar 29, 2017 at 10:10:39AM +0100, Andrew Cooper wrote:
> On 29/03/17 10:03, Jan Beulich wrote:
> On 28.03.17 at 23:11, wrote:
> >> On 27/03/2017 10:10, Wei Liu wrote:
> >>> Prefix them with "mm_" and add declarations to asm-x86/mm.h.
> >>>
> >>> They will be needed when we split PV sp
flight 71123 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71123/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-pvops 3 host-install(3) broken like 71078
build-armhf
Hi,
On 29/03/17 13:38, Wei Liu wrote:
Cc Julien
On Wed, Mar 29, 2017 at 06:00:08AM -0600, Jan Beulich wrote:
On 29.03.17 at 13:15, wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -574,7 +574,7 @@ static unsigned long init_node_heap(int node, unsigned long
mfn,
fo
This run is configured for baseline tests only.
flight 71122 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71122/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-bootfail
Hi Juergen,
On 29/03/17 15:10, Juergen Gross wrote:
Cc-ing Julien, as this series is meant for 4.9.
George asked me a couple of weeks ago a "last posting date" exception
request for this series and I was happy with that.
Assuming the series gets the proper acked-by/reviewed-by tags:
Releas
Hi,
On 29/03/17 16:55, Wei Liu wrote:
On Wed, Mar 29, 2017 at 04:38:43PM +0100, Andrew Cooper wrote:
MEM_LOG() is just a thin wrapper around gdprintk(), obscuring some of the
common information. Inline it, and take the opportunity to correct some of
the printked information.
Some corrections,
On Mon, Mar 27, 2017 at 01:56:46PM +0100, Roger Pau Monne wrote:
> On Mon, Mar 27, 2017 at 06:19:19AM -0600, Jan Beulich wrote:
> > >>> On 27.03.17 at 12:44, wrote:
> > > The series has been tested with a PVHv2 Dom0 on a box with 3 IO APICs,
> > > although all devices are wired up into the first I
On Tue, Mar 28, 2017 at 06:26:14PM +0200, Juergen Gross wrote:
[...]
> +
> +static char *transaction_get_node_name(void *ctx, struct transaction *trans,
> +const char *name)
> +{
> + return talloc_asprintf(ctx, "%"PRIu64"/%s", trans->generation, name);
> +}
>
Hi Andre,
On Thu, Mar 16, 2017 at 4:50 PM, Andre Przywara wrote:
> The ITS uses device IDs to map LPIs to a device. Dom0 will later use
> those IDs, which we directly pass on to the host.
> For this we have to map each device that Dom0 may request to a host
> ITS device with the same identifier.
Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch"
added code that makes use of a new xenstore guest platform key called
'acpi_laptop_slate'. This path needs to be added to the documentation.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
On Thu, Mar 30, 2017 at 12:18:01PM +0100, Paul Durrant wrote:
> Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch"
> added code that makes use of a new xenstore guest platform key called
> 'acpi_laptop_slate'. This path needs to be added to the documentation.
>
> Signed-off-by:
On Wed, Mar 29, 2017 at 10:49:34AM -0400, Boris Ostrovsky wrote:
> A number of changes have been made to how we determine whether TSC
> is emulated (e.g. commit 4fc380ac0077 ("x86/time: don't use virtual TSC
> if host and guest frequencies are equal")).
>
> Update the man page to reflect those cha
This run is configured for baseline tests only.
flight 71124 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71124/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d3017dd96bf96521cbb87a26bb9dd09f8aa5811d
baseline v
On 22/03/17 10:59, Olaf Hering wrote:
> On Wed, Mar 22, Olaf Hering wrote:
>
>> Did the xc_shadow_control API change at some point?
> ... staging-4.5 works, while staging-4.6 does not.
Can you describe in a little more detail what you are testing?
I have tried reproducing your scenario, and I don
flight 106987 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106987/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
Am Thu, 30 Mar 2017 12:40:34 +0100
schrieb Andrew Cooper :
> On 22/03/17 10:59, Olaf Hering wrote:
> > On Wed, Mar 22, Olaf Hering wrote:
> >
> >> Did the xc_shadow_control API change at some point?
> > ... staging-4.5 works, while staging-4.6 does not.
>
> Can you describe in a little more
>>> On 30.03.17 at 12:56, wrote:
> On Mon, Mar 27, 2017 at 01:56:46PM +0100, Roger Pau Monne wrote:
>> On Mon, Mar 27, 2017 at 06:19:19AM -0600, Jan Beulich wrote:
>> > >>> On 27.03.17 at 12:44, wrote:
>> > > The series has been tested with a PVHv2 Dom0 on a box with 3 IO APICs,
>> > > although a
On 20/03/17 11:50, Jan Beulich wrote:
On 20.03.17 at 11:58, wrote:
>> ...rather than leaving fragments of old instructions in place. This reduces
>> the chances of something going further-wrong (as the debug trap will be
>> caught
>> and terminate the guest) in a cascade-failure where we en
>>> On 30.03.17 at 03:37, wrote:
> On 17-03-29 03:57:52, Jan Beulich wrote:
>> >>> On 29.03.17 at 03:36, wrote:
>> > On 17-03-29 09:20:21, Yi Sun wrote:
>> >> On 17-03-28 06:20:48, Jan Beulich wrote:
>> >> > >>> On 28.03.17 at 13:59, wrote:
>> >> > > I think we at least need a 'get_val()' hook.
>>> On 29.03.17 at 17:49, wrote:
> On 03/29/2017 06:04 PM, Razvan Cojocaru wrote:
>> On 03/29/2017 05:00 PM, Razvan Cojocaru wrote:
>>> On 03/29/2017 04:55 PM, Jan Beulich wrote:
>>> On 28.03.17 at 12:50, wrote:
> On 03/28/2017 01:47 PM, Jan Beulich wrote:
> On 28.03.17 at 12:27,
>>> On 30.03.17 at 13:56, wrote:
> On 20/03/17 11:50, Jan Beulich wrote:
> On 20.03.17 at 11:58, wrote:
>>> ...rather than leaving fragments of old instructions in place. This reduces
>>> the chances of something going further-wrong (as the debug trap will be
>>> caught
>>> and terminate th
On 17-03-30 05:55:52, Jan Beulich wrote:
> >>> On 30.03.17 at 03:37, wrote:
> > On 17-03-29 03:57:52, Jan Beulich wrote:
> >> >>> On 29.03.17 at 03:36, wrote:
> >> > On 17-03-29 09:20:21, Yi Sun wrote:
> >> >> On 17-03-28 06:20:48, Jan Beulich wrote:
> >> >> > >>> On 28.03.17 at 13:59, wrote:
>
On 03/30/2017 03:05 PM, Jan Beulich wrote:
On 29.03.17 at 17:49, wrote:
>> On 03/29/2017 06:04 PM, Razvan Cojocaru wrote:
>>> On 03/29/2017 05:00 PM, Razvan Cojocaru wrote:
On 03/29/2017 04:55 PM, Jan Beulich wrote:
On 28.03.17 at 12:50, wrote:
>> On 03/28/2017 01:47 PM, Ja
>>> On 30.03.17 at 12:07, wrote:
> Assuming exporting the functions are still necessary, I will use the
> suggested names.
Well, I've asked before: Are they really needed outside of PV-specific
code? It would be odd if so ...
Jan
___
Xen-devel mailin
>>> On 30.03.17 at 00:18, wrote:
> +static inline RING_IDX name##_mask(RING_IDX idx, RING_IDX ring_size)
> \
> +{
> \
> +return (idx & (ring_size - 1));
> \
> +}
On 30/03/17 13:17, Wei Liu wrote:
> On Tue, Mar 28, 2017 at 06:26:14PM +0200, Juergen Gross wrote:
> [...]
>> +
>> +static char *transaction_get_node_name(void *ctx, struct transaction *trans,
>> + const char *name)
>> +{
>> +return talloc_asprintf(ctx, "%"PRIu
>>> On 30.03.17 at 00:18, wrote:
> @@ -104,16 +105,22 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
> done >$@.new
> mv $@.new $@
>
> +headers99.chk: $(PUBLIC_C99_HEADERS) Makefile
> + rm -f $@.new $@
Why also $@?
> + $(foreach i, $(filter %.h,$^), $(CC) -x c -std=c99 -Wa
When booting using ACPI, not all MMIOs can be discovered by parsing the
static tables or the UEFI memory map. A lot of them will be described in
the DSDT. However, Xen does not have an AML parser which requires us to
find a different approach.
During the first discussions on supporting ACPI (see d
>>> On 30.03.17 at 00:18, wrote:
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -94,9 +94,12 @@ all: headers.chk headers99.chk headers++.chk
>
> PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard
> public/*.h public/*/*.h) $(public-y))
>
> -PUBLIC_C99_
On Thu, Mar 30, 2017 at 06:25:33AM -0600, Jan Beulich wrote:
> >>> On 30.03.17 at 12:07, wrote:
> > Assuming exporting the functions are still necessary, I will use the
> > suggested names.
>
> Well, I've asked before: Are they really needed outside of PV-specific
> code? It would be odd if so ..
Hi Julien,
On 03/30/2017 07:43 AM, Julien Grall wrote:
> When booting using ACPI, not all MMIOs can be discovered by parsing the
> static tables or the UEFI memory map. A lot of them will be described in
> the DSDT. However, Xen does not have an AML parser which requires us to
> find a different
Hi Wei,
On 30/03/17 10:02, Wei Chen wrote:
+/* Unconditional branch instructions */
+/*
+ * From ARM DDI 0406C.c Section A8.8.25. We can see blx has a H bit.
+ * In an ARM/Thumb instructions mixed running environment, this bit
+ * can be 1 or 0. Although Xen is only using the ARM instructions
+
On 03/30/2017 03:05 PM, Jan Beulich wrote:
> What I do note though is that you don't copy back the value
> __cmpxchg() returns, yet that's what is needed. *map may
> have changed again already.
Changing the code to:
1162 ret = __cmpxchg(map, old, new, bytes);
1163
1164 if ( ret != old )
1
On 30/03/17 13:52, Shanker Donthineni wrote:
> Hi Julien,
Hi Shanker,
> On 03/30/2017 07:43 AM, Julien Grall wrote:
>> Shanker: You mentioned offline that you tested the patch. May I add
>> your tested-by?
>
> Sure add my tested-by. If you want I can test one more time this mailing lis
On Thu, Mar 30, 2017 at 02:36:15PM +0200, Juergen Gross wrote:
> On 30/03/17 13:17, Wei Liu wrote:
> > On Tue, Mar 28, 2017 at 06:26:14PM +0200, Juergen Gross wrote:
> > [...]
> >> +
> >> +static char *transaction_get_node_name(void *ctx, struct transaction
> >> *trans,
> >> +
>>> On 29.03.17 at 17:38, wrote:
> @@ -1388,7 +1398,7 @@ static int alloc_l1_table(struct page_info *page)
> return 0;
>
> fail:
> -MEM_LOG("Failure in alloc_l1_table: entry %d", i);
> +gdprintk(XENLOG_WARNING, "Failure in alloc_l1_table: slot %#x\n", i);
Switching to slot (in he
The handling of transactions in xenstored is rather clumsy today:
- Each transaction in progress is keeping a local copy of the complete
xenstore data base
- A transaction will fail as soon as any node is being modified outside
the transaction
This is leading to a very bad behavior in case of
Hi Julien,
On 03/30/2017 07:58 AM, Julien Grall wrote:
>
> On 30/03/17 13:52, Shanker Donthineni wrote:
>> Hi Julien,
> Hi Shanker,
>
>> On 03/30/2017 07:43 AM, Julien Grall wrote:
>>> Shanker: You mentioned offline that you tested the patch. May I add
>>> your tested-by?
>> Sure add my t
Hi Wei,
On 30/03/17 10:13, Wei Chen wrote:
Xen will do exception syndrome check while some types of exception
take place in EL2. The syndrome check code read the ESR_EL2 register
directly, but in some situation this register maybe overridden by
nested exception.
For example, if we re-enable IRQ
Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch"
added code to provide an 'laptop/slate mode' ACPI device to guests.
When present this device is used by Microsoft Windows to bind a HID
driver which controls whether the Windows desktop appearance is optimized
for laptop/deskto
On Thu, Mar 30, 2017 at 02:40:45PM +0100, Paul Durrant wrote:
> Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch"
> added code to provide an 'laptop/slate mode' ACPI device to guests.
>
> When present this device is used by Microsoft Windows to bind a HID
> driver which contro
On 03/30/2017 03:56 PM, Razvan Cojocaru wrote:
> On 03/30/2017 03:05 PM, Jan Beulich wrote:
>> What I do note though is that you don't copy back the value
>> __cmpxchg() returns, yet that's what is needed. *map may
>> have changed again already.
>
> Changing the code to:
>
> 1162 ret = __cmpx
>>> On 29.03.17 at 19:03, wrote:
> --- a/xen/arch/x86/hvm/dm.c
> +++ b/xen/arch/x86/hvm/dm.c
> @@ -118,57 +118,108 @@ static int set_isa_irq_level(struct domain *d, uint8_t
> isa_irq,
> return 0;
> }
>
> -static int modified_memory(struct domain *d,
> - struct xe
For kdump to work correctly it needs the physical address of
vmcoreinfo_note. When running as dom0 this means the virtual address
has to be translated to the related machine address.
paddr_vmcoreinfo_note() is meant to do the translation via __pa() only,
but being attributed "weak" it can be repla
>>> On 30.03.17 at 16:08, wrote:
> On 03/30/2017 03:56 PM, Razvan Cojocaru wrote:
>> On 03/30/2017 03:05 PM, Jan Beulich wrote:
>>> What I do note though is that you don't copy back the value
>>> __cmpxchg() returns, yet that's what is needed. *map may
>>> have changed again already.
>>
>> Changi
>>> On 30.03.17 at 08:19, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -42,6 +42,13 @@ DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *,
> poll_bankmask);
> DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, no_cmci_banks);
> DEFINE_PER_CPU_READ_MOSTLY(struct
>>> On 30.03.17 at 08:19, wrote:
> If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then set LMCE and
> LOCK bits in guest MSR_IA32_FEATURE_CONTROL. Intel SDM requires those
> bits are set before SW can enable LMCE.
>
> Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
_
Hi. Christian Lindig of Citrix has been looking into our ARM64 ocaml
build problem. See attached mail from him.
(NB: xen-devel added to CC list.)
Christian writes:
> My short-term strategy would be to exclude the ocaml xenstored on
> architectures that don’t support the native code OCaml
> comp
>>> On 30.03.17 at 08:19, wrote:
> If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest
> to read/write MSR_IA32_MCG_EXT_CTL.
>
> Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen
>>> On 30.03.17 at 08:19, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mcaction.c
> +++ b/xen/arch/x86/cpu/mcheck/mcaction.c
> @@ -44,6 +44,7 @@ mc_memerr_dhandler(struct mca_binfo *binfo,
> unsigned long mfn, gfn;
> uint32_t status;
> int vmce_vcpuid;
> +uint16_t mc_vcpuid;
Any reas
On 03/30/2017 10:18 AM, Juergen Gross wrote:
> For kdump to work correctly it needs the physical address of
> vmcoreinfo_note. When running as dom0 this means the virtual address
> has to be translated to the related machine address.
>
> paddr_vmcoreinfo_note() is meant to do the translation via __
>>> On 30.03.17 at 08:20, wrote:
> If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present
> in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP.
> By default, LMCE is not exposed to guest so as to keep the backwards migration
> compatibility.
>
> Signed-off-
>>> On 30.03.17 at 08:20, wrote:
> @@ -1565,6 +1566,28 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
> }
> break;
>
> +case XEN_MC_INJECT_TYPE_LMCE:
> +if ( !lmce_support )
> +{
> +ret = x86_mcerr("No LMCE supp
On 03/30/2017 05:21 PM, Jan Beulich wrote:
On 30.03.17 at 16:08, wrote:
>> On 03/30/2017 03:56 PM, Razvan Cojocaru wrote:
>>> On 03/30/2017 03:05 PM, Jan Beulich wrote:
What I do note though is that you don't copy back the value
__cmpxchg() returns, yet that's what is needed. *map m
>>> On 30.03.17 at 16:18, wrote:
> @@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct
> *vma,
> return -EINVAL;
> }
> EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
> +
> +#ifdef CONFIG_KEXEC_CORE
> +phys_addr_t paddr_vmcoreinfo_note(void)
> +{
> + if (xen_pv_
flight 106990 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail
REGR. vs. 106959
Re
flight 107000 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107000/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
Make minimal adjustments in order to enable the compilation of the
xen source-code with gcc-6's -fsanitize-coverage=trace-pc option.
Due to a bug in Xen's build-system the flag for the compiler has
to be handed in via the command line, i.e. for compiling one would
use:
make CC=
This is a
Hi Julien,
5pm UTC+1 will be fine for me.
I just finished my EL0 PoC and want to share benchmark results.
My benchmark setup is primitive, but results are reproducible. I have
wrote small driver that calls SMC 10.000.000 times in a loop. So,
benchmark looks like this:
root@xenaarch64:~# time c
>>> On 30.03.17 at 17:05, wrote:
> On 03/30/2017 05:21 PM, Jan Beulich wrote:
> On 30.03.17 at 16:08, wrote:
>>> On 03/30/2017 03:56 PM, Razvan Cojocaru wrote:
On 03/30/2017 03:05 PM, Jan Beulich wrote:
> What I do note though is that you don't copy back the value
> __cmpxchg() r
On Thu, Mar 30, 2017 at 03:11:48PM +0200, Juergen Gross wrote:
[...]
> +
> +/*
> + * A node has been accessed.
> + *
> + * Modifying accesses (write, delete) always update the generation (global
> and
> + * node->generation).
> + *
> + * Accesses in a transaction will be added to the list of acces
Cool. I think Xen should boot with this.
You've successfully finished what I asked for. Now you can divert your
energy to polish your application. :-)
On Thu, Mar 30, 2017 at 05:39:56PM +0200, Felix Schmoll wrote:
> Make minimal adjustments in order to enable the compilation of the
> xen source-c
flight 106992 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106992/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 106985 pass in
106992
test-armhf-armhf-libvirt
> On 30. Mar 2017, at 15:40, Ian Jackson wrote:
>
> Christian, can you advise what the correct test should be to check
> whether the native code compiler is available ? I can then try to
> make a patch to our autoconfery, and maybe you would be able to review
> it. Or if you prefer to make tha
On Thu, Mar 30, 2017 at 1:21 AM, Haozhong Zhang
wrote:
> On 03/29/17 21:20 -0700, Dan Williams wrote:
>> On Sun, Mar 19, 2017 at 5:09 PM, Haozhong Zhang
>> wrote:
>> > This is v2 RFC patch series to add vNVDIMM support to HVM domains.
>> > v1 can be found at
>> > https://lists.xenproject.org/arc
There are quite a few of these, and as the option is a development one
only, duplicate symbol names should not be an issue there. In other
environments allow the user to control this, unless Live patching is
enabled.
Signed-off-by: Jan Beulich
---
v2: Make this a separate config option, selected
On Thu, Mar 30, 2017 at 10:12:03AM -0600, Jan Beulich wrote:
> There are quite a few of these, and as the option is a development one
> only, duplicate symbol names should not be an issue there. In other
> environments allow the user to control this, unless Live patching is
> enabled.
>
> Signed-o
Hi,
On Fri, Mar 17, 2017 at 07:29:15PM +0800, Lan Tianyu wrote:
> From: Chao Gao
>
> Since adding a dynamic sysbus device is forbidden, so choose TYPE_DEVICE
> as parent class.
>
> Signed-off-by: Chao Gao
> Signed-off-by: Lan Tianyu
> ---
> hw/xen/Makefile.objs | 1 +
> hw/xen/xen_viommu.c
This series fixes https://xenproject.atlassian.net/browse/XEN-5
Andrew Cooper (4):
tools/libxc: Tolerate specific zero-content records in migration v2 streams
tools/libxc: Avoid generating inappropriate zero-content records
tools/python: Adjust migration v2 library to warn about zero-content
The sending side shouldn't send any data records which end up having zero
content, but the receiving side will need to tolerate such records for
compatibility purposes.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Julien Grall
---
docs/specs/libxc-migration-stream.pandoc |
The code as written attempted to elide zero-content records, as such records
serve no purpose but come with a performance hit. Unfortunately, in the case
where the hypervisor reported max size is non-zero, but the actual size is
zero, the record is not elided.
This previously tripped up the sanit
These records shouldn't be in a stream, but accidentally are. Warn about
them, but don't abort the verification.
While here, add a missing length check to the X86_PV_P2M_FRAMES record
checker.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
---
CC: Ian Jackson
CC: Julien Grall
---
tools/p
1 - 100 of 206 matches
Mail list logo
