> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, February 06, 2017 10:58 PM
>
> There is an issue with the original __vmread() in nested vmx mode:
> emulation of a guest's VMREAD with invalid arguments leads to BUG().
>
> Fix this by using vmread_safe() and reporting any ki
On February 07, 2017 7:33 AM, Chao Gao wrote:
>Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue")
>has added a assertion that intack.vector is the highest priority vector. But
>according to the osstest, the assertion failed sometimes. More discussion
>can be found in the thread
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, February 06, 2017 10:58 PM
>
> There is an issue with the original __vmwrite() in nested vmx mode:
> emulation of a guest's VMWRITE with invalid arguments leads to BUG().
>
> Fix this by using vmwrite_safe() and reporting any
Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
added a assertion that intack.vector is the highest priority vector. But
according to the osstest, the assertion failed sometimes. More discussion can
be found in the thread
(https://lists.xenproject.org/archives/html/xen-d
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, February 06, 2017 10:58 PM
>
> The original function doesn't distinguish between Valid and Invalid
> VMfails. Improved function returns error code depending on the outcome:
>
> VMsucceed: 0
> VMfailValid: VM In
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, February 06, 2017 10:58 PM
>
> Any fail during the original __vmwrite() leads to BUG() which can be
> easily exploited from a guest in the nested vmx mode.
>
> The new function returns error code depending on the outcome:
>
flight 105588 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 59254
test-amd64-amd64-xl
flight 105591 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105591/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64-xsm
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Monday, February 06, 2017 7:33 PM
>
> On Fri, 2017-01-27 at 10:36 -0500, Konrad Rzeszutek Wilk wrote:
> > . snip ..
> > >
> > > >
> > > > Signed-off-by: David Woodhouse
> > > Reviewed-by: Jan Beulich
> > >
> > > But before committing I
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 26, 2017 11:48 PM
>
> >>> On 26.01.17 at 15:50, wrote:
> > From: David Woodhouse
> >
> > For some MMIO regions, such as those high above RAM, mfn_valid() will
> > return false.
> >
> > Since the fix for XSA-154 in commit c6
On 17-01-31 15:57:26, Konrad Rzeszutek Wilk wrote:
> > static int assemble_val_array(uint64_t *val,
> > @@ -550,7 +641,25 @@ static int assemble_val_array(uint64_t *val,
> >const struct psr_socket_info *info,
> >unsigned int old_cos)
flight 105590 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105590/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64-xsm
Hi,
Thanks for reviewing! I agree with your comments except below one. Could you
please check my response?
On 17-01-31 15:29:34, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 19, 2017 at 02:01:09PM +0800, Yi Sun wrote:
> > +int psr_get_val(struct domain *d, unsigned int socket,
> > +
On Mon, Feb 6, 2017 at 7:43 PM, Jan Beulich wrote:
On 05.02.17 at 06:51, wrote:
>> Please find the full log in the attachment.
>
> Sadly that one is only a partial log again. I'd really need to see the
> boot messages too, in particular to (hopefully) be able to judge
> whether your system u
On 02/06/2017 07:25 PM, Wei Liu wrote:
On Mon, Feb 06, 2017 at 05:27:43PM +0800, Zhang Chen wrote:
[...]
set_disk_colo_restore(d_config);
} else {
unset_disk_colo_restore(d_config);
}
return do_domain_create(ctx, d_config, domid, restore_fd, send_back
flight 105583 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105583/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64-xsm
flight 105576 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105576/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105450
test-amd64-i386-xl-qemut-wi
flight 105573 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105573/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 17 guest-localmigrate/x10fail REGR. vs. 59254
test-amd64-amd64-xl
On 01/24/2017 07:20 AM, Boris Ostrovsky wrote:
>
>> Yes, the only remaining risk is some vendor using _SB.XEN0, and AFAICT
>> there's
>> no way to reserve anything in there (mostly because it's assumed that ACPI
>> tables will be created by a single entity I guess).
>>
>> I think that the chance
On Wed, Feb 1, 2017 at 9:14 PM, Andy Lutomirski wrote:
> On Thu, Jan 26, 2017 at 8:59 AM, Thomas Garnier wrote:
>> This patch makes the GDT remapped pages read-only to prevent corruption.
>> This change is done only on 64 bit.
>>
>> The native_load_tr_desc function was adapted to correctly handle
On 02/06/2017 02:29 PM, kbuild test robot wrote:
> Hi Boris,
>
> [auto build test WARNING on xen-tip/linux-next]
> [also build test WARNING on v4.10-rc7]
> [cannot apply to next-20170206]
> [if your patch is applied to the wrong git tree, please drop us a note to
> he
flight 105584 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105584/
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
Hi Boris,
[auto build test WARNING on xen-tip/linux-next]
[also build test WARNING on v4.10-rc7]
[cannot apply to next-20170206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Boris-Ostrovsky
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first two commands we implement provide methods to map a collection
to a redistributor (aka host core) and to flush t
On Mon, Feb 06, 2017 at 11:39:08PM +0530, Bhupinder Thakur wrote:
> As per "VM System Specification for ARM Processors", there is a requirement
> for Xen to support guest console
> over pl011 UART, which is SBSA compliant. The changes in this patch implement
> the pl011 emulation in Xen
> and a
Hi Bhupinder,
Thank you for the patch.
On 06/02/17 18:09, Bhupinder Thakur wrote:
As per "VM System Specification for ARM Processors", there is a requirement
for Xen to support guest console
over pl011 UART, which is SBSA compliant. The changes in this patch implement
the pl011 emulation in
As per "VM System Specification for ARM Processors", there is a requirement
for Xen to support guest console
over pl011 UART, which is SBSA compliant. The changes in this patch implement
the pl011 emulation in Xen
and a new pl011 console support in xenconsoled.
Signed-off-by: Bhupinder Thakur
As per "VM System Specification for ARM Processors", there is a requirement
for Xen to support guest console
over pl011 UART, which is SBSA compliant. The changes in this patch implement
the pl011 emulation in Xen
and a new pl011 console support in xenconsoled.
The following changes are still p
flight 105568 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105568/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 105535
build-i386-pvops
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
Instead of directly manipulating the tables in memory, an ITS driver
sends commands via a ring buffer to the ITS h/w to create or alter the
LPI mappings.
Allocate memory for that buffer and tell the ITS about it to be able
to send ITS commands.
Hi,
On 30/01/17 18:31, Andre Przywara wrote:
+int gicv3_its_init(struct host_its *hw_its)
+{
+uint64_t reg;
+int i;
+
+hw_its->its_base = ioremap_nocache(hw_its->addr, hw_its->size);
+if ( !hw_its->its_base )
+return -ENOMEM;
+
+for ( i = 0; i < GITS_BASER_NR_REGS; i+
On 30/01/17 18:31, Andre Przywara wrote:
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index fcb86c8..440c079 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1563,6 +15
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
an EventID (the MSI payload or interrupt ID) to a pair of LPI number
and collection ID, which points to the target CPU.
This mapping is stored in the device and collection ta
flight 105578 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
page, initialize boot_params, enable early page tables.
Since this stub is executed before kernel entry point we cannot use
variables in .bss which is cleared by kernel. We explicitly place
variables that are initialized here int
The new Xen PVH entry point requires page tables to be setup by the
kernel since it is entered with paging disabled.
Pull the common code out of head_32.S so that mk_early_pgtbl_32() can be
invoked from both the new Xen entry point and the existing startup_32()
code.
Convert resulting common code
PVHv2 support for unprivileged guests.
Changes in v3:
* See patches 4 and 5
Boris Ostrovsky (9):
x86/boot/32: Convert the 32-bit pgtable setup code from assembly to C
xen/x86: Remove PVH support
xen/pvh: Import PVH-related Xen public interfaces
xen/pvh: Bootstrap PVH guest
xen/pvh: Make
Like PV guests, PVH does not have PCI devices and therefore cannot
use MMIO space to store grants. Instead it balloons out memory and
keeps grants there.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
---
drivers/xen/grant-table.c | 8
1 file changed, 4 insertions(+), 4 dele
Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Reviewed-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/platform-pci-unplug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/platform-pci-unplug.c
b/arch/x86/xen/platform-pci-unplug.c
index 90d1b83..33a
We are replacing existing PVH guests with new implementation.
We are keeping xen_pvh_domain() macro (for now set to zero) because
when we introduce new PVH implementation later in this series we will
reuse current PVH-specific code (xen_pvh_gnttab_setup()), and that
code is conditioned by 'if (xen
Since we are not using PIC and (at least currently) don't have IOAPIC
we want to make sure that acpi_irq_model doesn't stay set to
ACPI_IRQ_MODEL_PIC (which is the default value). If we allowed it to
stay then acpi_os_install_interrupt_handler() would try (and fail) to
request_irq() for PIC.
Inste
Using native_machine_emergency_restart (called during reboot) will
lead PVH guests to machine_real_restart() where we try to use
real_mode_header which is not initialized.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
---
arch/x86/xen/enlighten.c | 3 +++
1 file changed, 3 insertio
Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Reviewed-by: Konrad Rzeszutek Wilk
---
include/xen/interface/elfnote.h| 12 ++-
include/xen/interface/hvm/hvm_vcpu.h | 143 +
include/xen/interface/hvm/start_info.h | 98 ++
PVH guests don't (yet) receive ACPI hotplug interrupts and therefore
need to monitor xenstore for CPU hotplug event.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
---
drivers/xen/cpu_hotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/cpu_hotplu
* Latch current once at the start.
* Avoid the memory operand read for INVEPT_ALL_CONTEXT. Experimentally, this
is how hardware behaves, and avoids an unnecessary pagewalk.
* Reject Reg/Reg encodings of the instruction.
* Audit eptp against maxphysaddr.
* Introduce and use VMX_INSN_INVALID
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
The ARM GICv3 provides a new kind of interrupt called LPIs.
The pending bits and the configuration data (priority, enable bits) for
those LPIs are stored in tables in normal memory, which software has to
provide to the hardware.
Allocate the req
branch xen-unstable
xenbranch xen-unstable
job build-armhf
testid xen-build
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: qemuu git://git.qemu.org/qemu.git
Bug introduced: 0ab8ed18a6fe98bfc8270
George Dunlap writes ("Re: [Xen-devel] [PATCH] xl: remove stale comment"):
> On Thu, Feb 2, 2017 at 4:07 PM, Ian Jackson wrote:
> > Ie, why does xl have this code at all ? Why is its handling of
> > LIBXL_EVENT_TYPE_DISK_EJECT not to simply ignore it ? Why does it
> > even bother listening for t
Wei Liu writes ("Re: [OSSTEST PATCH] standalone-reset: use mkdir -p"):
> tftptmp=`getconfig TftpTmpDir`
> ensure_dir "$tftp$tftptmp"
OK. I'm afraid I think if TftpTmpDir's parent does not exist, osstest
should not create it automatically.
> And $tftp is set to /tmp/ in my standalone config.
As
>>> On 06.02.17 at 15:48, wrote:
> On Mon, 2017-02-06 at 07:26 -0700, Jan Beulich wrote:
>> >
>> > >
>> > > >
>> > > > On 06.02.17 at 14:55, wrote:
>> > Switch its return type to bool to match its use, and simplify the
>> > ARM
>> > implementation slightly.
>> >
>> > No functional change.
>>
On Mon, Feb 06, 2017 at 03:13:17PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [OSSTEST PATCH] standalone-reset: use mkdir -p"):
> > On Mon, Feb 06, 2017 at 11:49:23AM +, Ian Jackson wrote:
> > > Wei Liu writes ("[OSSTEST PATCH] standalone-reset: use mkdir -p"):
> > > ...
> > > > ensure_d
On Thu, Feb 2, 2017 at 4:07 PM, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH] xl: remove stale comment"):
>> On Thu, Feb 02, 2017 at 03:56:03PM +, Ian Jackson wrote:
>> > Wei Liu writes ("[PATCH] xl: remove stale comment"):
>> > > case LIBXL_EVENT_TYPE_DISK_EJECT:
>> > > -
On 06/02/17 14:57, Sergey Dyasli wrote:
> Currently, emulation of vmread and vmwrite for a guest leads to BUG()
> in cases when actual VMREAD or VMWRITE ends up in VMfail due to invalid
> arguments. The goal of this patch series is to prevent the BUG() from
> happening and report any kind of VMfai
Wei Liu writes ("Re: [OSSTEST PATCH] standalone-reset: use mkdir -p"):
> On Mon, Feb 06, 2017 at 11:49:23AM +, Ian Jackson wrote:
> > Wei Liu writes ("[OSSTEST PATCH] standalone-reset: use mkdir -p"):
> > ...
> > > ensure_dir () {
> > > if test -d "$1"; then return; fi
> > > - mkdir "$1"
> >
On 06/02/17 14:53, Wei Liu wrote:
> On Mon, Feb 06, 2017 at 09:50:32AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Mon, Feb 06, 2017 at 12:53:56PM +, Wei Liu wrote:
>>> On Mon, Feb 06, 2017 at 12:51:45PM +, Wei Liu wrote:
When running XTF with a XSM-enabled Xen (generated by one of my os
There is an issue with the original __vmread() in nested vmx mode:
emulation of a guest's VMREAD with invalid arguments leads to BUG().
Fix this by using vmread_safe() and reporting any kind of VMfail back
to the guest.
A new safe versions of get_vvmcs() macro and related functions are
introduced
The original function doesn't distinguish between Valid and Invalid
VMfails. Improved function returns error code depending on the outcome:
VMsucceed: 0
VMfailValid: VM Instruction Error Number
VMfailInvalid: VMX_INSN_FAIL_INVALID (~0)
Existing users of __vmread_safe() are upda
Currently, emulation of vmread and vmwrite for a guest leads to BUG()
in cases when actual VMREAD or VMWRITE ends up in VMfail due to invalid
arguments. The goal of this patch series is to prevent the BUG() from
happening and report any kind of VMfail back to the guest, just like
it would be done
There is an issue with the original __vmwrite() in nested vmx mode:
emulation of a guest's VMWRITE with invalid arguments leads to BUG().
Fix this by using vmwrite_safe() and reporting any kind of VMfail back
to the guest.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vmcs.c| 9
Any fail during the original __vmwrite() leads to BUG() which can be
easily exploited from a guest in the nested vmx mode.
The new function returns error code depending on the outcome:
VMsucceed: 0
VMfailValid: VM Instruction Error Number
VMfailInvalid: a new VMX_INSN_FAIL
On Mon, Feb 06, 2017 at 09:50:32AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 06, 2017 at 12:53:56PM +, Wei Liu wrote:
> > On Mon, Feb 06, 2017 at 12:51:45PM +, Wei Liu wrote:
> > > When running XTF with a XSM-enabled Xen (generated by one of my osstest
> > > flight for testing somet
On Mon, Feb 06, 2017 at 12:53:56PM +, Wei Liu wrote:
> On Mon, Feb 06, 2017 at 12:51:45PM +, Wei Liu wrote:
> > When running XTF with a XSM-enabled Xen (generated by one of my osstest
> > flight for testing something else).
> >
> > Executing 'xl create -F
> > tests/livepatch-priv-check/tes
On Mon, 2017-02-06 at 07:26 -0700, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 06.02.17 at 14:55, wrote:
> > Switch its return type to bool to match its use, and simplify the
> > ARM
> > implementation slightly.
> >
> > No functional change.
> >
> > Signed-off-by: Andrew Cooper
> Reviewe
>>> On 06.02.17 at 14:55, wrote:
> Switch its return type to bool to match its use, and simplify the ARM
> implementation slightly.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
And perhaps that's what should be used in epte_get_entry_emt()
instead of !m
On 06/02/17 13:55, Andrew Cooper wrote:
> Switch its return type to bool to match its use, and simplify the ARM
> implementation slightly.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: George Dunlap
> ---
> CC: Jan Beulich
> CC: Tim Deegan
> CC: George Dunlap
> CC: S
Hi Andrew,
On 06/02/17 13:55, Andrew Cooper wrote:
Switch its return type to bool to match its use, and simplify the ARM
implementation slightly.
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
Regards,
--
Julien Grall
__
Switch its return type to bool to match its use, and simplify the ARM
implementation slightly.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/mm.c | 6 ++
xen/arch
flight 105565 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105565/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
Parse the DT GIC subnodes to find every ITS MSI controller the hardware
offers. Store that information in a list to both propagate all of them
later to Dom0, but also to be able to iterate over all ITSes.
This introduces an ITS Kconfig option.
On Mon, Feb 06, 2017 at 12:51:45PM +, Wei Liu wrote:
> When running XTF with a XSM-enabled Xen (generated by one of my osstest
> flight for testing something else).
>
> Executing 'xl create -F
> tests/livepatch-priv-check/test-hvm32-livepatch-priv-check.cfg'
> --- Xen Test Framework ---
> Envi
flight 105569 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105569/
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
When running XTF with a XSM-enabled Xen (generated by one of my osstest
flight for testing something else).
Executing 'xl create -F
tests/livepatch-priv-check/test-hvm32-livepatch-priv-check.cfg'
--- Xen Test Framework ---
Environment: HVM 32bit (No paging)
Live Patch Privilege Check
Fail: test_up
>>> On 05.02.17 at 06:51, wrote:
> I finally get some spare time to collect the debug info.
As I continue to be puzzled, best I could come up with is an
extension to the debug patch. Please use the attached one
in place of the earlier one, ideally on top of
https://lists.xenproject.org/archives/h
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
new file mode 100644
index 000..ff0f571
--- /dev/null
+++ b/xen/arch/arm/gic-v3-its.c
@@ -0,0 +1,71 @@
+/*
+ * xen/arch/arm/gic-v3-its.c
+ *
+ * ARM GICv3 Interrupt Translati
Especially printing virtual addresses of mappings of the individual
pages seems rather useless here - this mostly obfuscates the important
numbers, and hinders comparing two printouts. Printing the page table
level indexes isn't very useful either, as the immediately following
lines will print the
flight 105557 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105557/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 59254
build-amd64-xsm
On Mon, Feb 06, 2017 at 11:49:23AM +, Ian Jackson wrote:
> Wei Liu writes ("[OSSTEST PATCH] standalone-reset: use mkdir -p"):
> ...
> > ensure_dir () {
> > if test -d "$1"; then return; fi
> > - mkdir "$1"
> > + mkdir -p "$1"
>
> This deliberately doesn't do this. Otherwise wrong (or
Perl in Debian stretch quite properly no longer has . in @INC by
default.
However, (almost everything in) osstest expects to be run standing
inside an osstest tree, and expects to find its various pieces in `.'
So add . back to @INC, at the front.
This patch was autogenerated using the following
Wei Liu writes ("[OSSTEST PATCH] standalone-reset: use mkdir -p"):
...
> ensure_dir () {
> if test -d "$1"; then return; fi
> - mkdir "$1"
> + mkdir -p "$1"
This deliberately doesn't do this. Otherwise wrong (or partially
missing) configuration can create strangely-named directorie
>>> On 05.02.17 at 06:51, wrote:
> Please find the full log in the attachment.
Sadly that one is only a partial log again. I'd really need to see the
boot messages too, in particular to (hopefully) be able to judge
whether your system uses shared or separate EPT and VT-d tables.
Jan
__
On Fri, 2017-01-27 at 10:36 -0500, Konrad Rzeszutek Wilk wrote:
> . snip ..
> >
> > >
> > > Signed-off-by: David Woodhouse
> > Reviewed-by: Jan Beulich
> >
> > But before committing I'd prefer to have a VMX maintainer ack
> > too.
> Who is gone until Feb yth (Spring festival in China).
Not su
On Mon, Feb 06, 2017 at 05:27:43PM +0800, Zhang Chen wrote:
[...]
>
> >
> > > set_disk_colo_restore(d_config);
> > > } else {
> > > unset_disk_colo_restore(d_config);
> > > }
> > > return do_domain_create(ctx, d_config, domid, restore_fd,
> > > send_back_fd,
Thank you all for the positive replies. I will try it out.
Thanks and regards,
George
On Fri, Jan 27, 2017 at 2:11 PM, Iurii Mykhalskyi <
iurii.mykhals...@globallogic.com> wrote:
> Hi George,
>
> I didn't test official Renesas yocto layer for Lager board.
>
> But general approach to bring-up xen
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
The ability to clean a cache line is not only useful for EFI, but will
be needed later for the ITS support.
Export the function to be usable from the whole Xen/ARM code.
There is already a function to clean & invalidate. See
clean_and_invalid
Konrad, Roger,
we've recently had a report of stuck I/O (with slightly over a hundred
frontend instances in a single guest), which turned out to be a simple
lack of configured grants on the system. This raises two questions:
1) Shouldn't blkfront cope with this situation, by throttling I/O (but n
On Mon, Feb 6, 2017 at 3:40 PM, Jan Beulich wrote:
On 05.02.17 at 08:18, wrote:
>> But we didn't see a map error in debug log either.
>
> I'll have to look into this more closely.
Let me know when you need more info / debug log.:-)
BTW, if this helps my hardware setup is based on i7-3770 +
Took care of the adjustment requirements in #5 and #10 and pushed to
staging.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Mon, Feb 6, 2017 at 5:33 PM, Pasi Kärkkäinen wrote:
> Hi,
>
> On Sun, Feb 05, 2017 at 04:05:32PM +0800, G.R. wrote:
>> Hi all,
>> dom0pvh=1 is not working well for me with XEN 4.8.0 + linux kernel 4.9.2.
>>
>> The system boots with no obvious issue.
>> But many user mode application are sufferi
>>> On 02.02.17 at 23:01, wrote:
> This way Xen can be loaded on EFI platforms using GRUB2 and
> other boot loaders which support multiboot2 protocol.
>
> Signed-off-by: Daniel Kiper
> ---
> v14 - suggestions/fixes:
> - mark .init.data section as writable; by the way we must change
> s
flight 68520 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68520/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-sid-netboot-pygrub 9 debian-di-install fail like 68499
test-armhf-armhf-ar
On Sat, Feb 04, 2017 at 08:42:33AM +, #PATHANGI JANARDHANAN JATINSHRAVAN#
wrote:
> Hi all, Recently, I’ve been trying to modify netback.c to print
> network data that is going into the VM. For example, I’m doing an SSL
> handshake with the VM as the server, and I send the following
> hexadecim
Hi,
On Sun, Feb 05, 2017 at 04:05:32PM +0800, G.R. wrote:
> Hi all,
> dom0pvh=1 is not working well for me with XEN 4.8.0 + linux kernel 4.9.2.
>
> The system boots with no obvious issue.
> But many user mode application are suffering from segfault, which
> makes the dom0 not useable: The segfaul
On 01/28/2017 01:05 AM, Wei Liu wrote:
On Thu, Jan 26, 2017 at 02:36:06PM +0800, Zhang Chen wrote:
In this patch we add a function to close
kernel COLO-Proxy on secondary side.
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_colo_restore.c | 9 +++--
tools/libxl/libxl_create.c
flight 105554 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105554/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 6 xen-boot fail pass in 105450
Regressions which are regarded a
This run is configured for baseline tests only.
flight 68519 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68519/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install f
As such clearing of flags may have an impact on the selected rendezvous
function, defer the establishing of a rendezvous function other than
the initial default one (std) until after all APs have been brought up.
But don't allow such feature flags to be cleared during CPU hotplug:
Platform and loc
>>> On 03.02.17 at 12:53, wrote:
> +static int fuzz_write_cr(
> +unsigned int reg,
> +unsigned long val,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +if ( reg >= ARRAY_SIZE(input.cr) )
> +return X86EMUL_UNHANDLEABLE;
> +
> +input.cr[reg] = val;
> +
> +return X86EMUL_OK
97 matches
Mail list logo
