flight 77988 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77988/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 60684
Regression
flight 77990 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 65543
test-amd64-amd64-
Add a simple ACPI based PCI host controller. This is done by
providing a simple implementation for pci_acpi_scan_root().
The pci_mmcfg_list handling is done by the ACPI code, we
keep a reference to the pci_mmcfg_region which is already
mapped.
Provide implementations of raw_pci_read and raw_pci_w
Add functions needed for ACPI support.
pci_acpi_scan_root(), raw_pci_read and raw_pci_write are marked as
weak so that it can be implemented by the generic ACPI PCI driver.
pcibios_enable_device and pcibios_disable_device handle acpi irq enable
and disable. And, pcibios_add_bus and pcibios_remove
On some platforms (in this case ARM64), the PCI iospace needs to
be mapped with pci_remap_iospace and the resources have to be
adjusted for the iospace physical address.
This has to be done before acpi_pci_root_validate_resources()
checks and removes resource windows. Handle this by adding
a funct
This patchset provides a generic ACPI based PCI host controller
implementation and uses it on arm64.
The first patch moves the common code to handle MCFG ACPI table from
arch/x86 to drivers/acpi/pci_mcfg.c. The last patch in the patchset
provides the generic implementation of an ACPI based PCI hos
Move pci_mmcfg_list handling to a drivers/acpi/pci_mcfg.c. This is
to share the API and code with ARM64 later. The corresponding
declarations are moved from asm/pci_x86.h to linux/pci-acpi.h
As a part of this we introduce three functions that can be
implemented by the arch code: pci_mmconfig_map_r
pci_create_root_bus is called with NULL as parent in ACPI. This
ends up calling pci_bus_assign_domain_nr with a NULL parent, which
crashes when dereferencing parent.
Fix this by providing a way to set the ACPI domain number and ACPI
companion in PCI code. We define pci_acpi_set_companion() to set
flight 78012 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78012/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62044
build-a
if (IS_VLV(pdev)) {
SET_BIT_INFO(hstate, 2, RCS_MMIO_SYNC_FLUSH, IRQ_INFO_GT);
SET_BIT_INFO(hstate, 14, VCS_MMIO_SYNC_FLUSH, IRQ_INFO_GT);
SET_BIT_INFO(hstate, 24, BCS_MMIO_SYNC_FLUSH);
}
Looks you didn’t set IRQ_INFO_GT for BCS event. Is it a typo?
Generally you can look at /sys/kernel/debug/
>>> On 1/13/2016 at 02:31 AM, in message
<22165.18064.452737.543...@mariner.uk.xensource.com>, Ian Jackson
wrote:
> Chunyan Liu writes ("[PATCH V12 3/5] libxl: add pvusb API"):
> > Add pvusb APIs, including:
> > - attach/detach (create/destroy) virtual usb controller.
> > - attach/detach u
This run is configured for baseline tests only.
flight 38632 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38632/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf
flight 77983 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77983/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 62112
test-amd64-i386-
On 01/12/16 09:48, Jan Beulich wrote:
> >>> On 31.12.15 at 04:03, wrote:
> > @@ -2003,6 +2011,10 @@ static struct hvm_function_table __initdata
> > vmx_function_table = {
> > .altp2m_vcpu_update_vmfunc_ve = vmx_vcpu_update_vmfunc_ve,
> > .altp2m_vcpu_emulate_ve = vmx_vcpu_emulate_ve,
>
> > +info->build_id = strdup("");
>
> I guess you're following existing strdup examples in this function.
/me nods.
>
> Since now there is a GC in scope, you can use libxl__strdup. Presumably
> you can also change other instances to use libxl__strdup.
Would you be OK if I did it in anot
flight 77967 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77967/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15
guest-localmigrate/x10 fail REGR. vs. 77902
Hi Wei,
We find when adding a VF by the command 'xl pci-assignable-add $BDF', a warning
message like this:
'libxl: warning: libxl_pci.c:843:libxl__device_pci_assignable_add: :03:10.1
not bound to a driver, will not be rebound'
always appears, our QA team treat this as a bug.
By checking t
> > Or are you suggesting that perhaps the kernel should at boot time
> > print the build-id (like it does the changset)?
>
> Perhaps, albeit to me that's a bit orthogonal to being able to find out
> the build ID for a given binary.
I can make some magic objdump + awk to extract the buildid from
On 14.01.2016 at 12:58am, wrote:
> >>> On 23.12.15 at 09:25, wrote:
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -28,6 +28,11 @@
> > #include "vtd.h"
> > #include "extern.h"
> >
> > +static int __read_mostly iommu_qi_timeout_ms = 1;
> > +i
On 14.01.2016 at 12:56am, wrote:
> >>> On 23.12.15 at 09:25, wrote:
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -28,6 +28,11 @@
> > #include "vtd.h"
> > #include "extern.h"
> >
> > +static int __read_mostly iommu_qi_timeout_ms = 1;
>
> I
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 13, 2016 7:03 PM
>
> >> Jan,
> >> Patch 2/3 and Patch 3/3 are based on v3 (Actually they are v3's patch 1/2
> > and patch 2/2).
> >> We have discussed how to hide a device with pci_hide_device() when
> >> Device-TLB
> > flu
On Wed, 13 Jan 2016, Vitaly Kuznetsov wrote:
> >> diff --git a/Documentation/memory-hotplug.txt
> >> b/Documentation/memory-hotplug.txt
> >> index ce2cfcf..ceaf40c 100644
> >> --- a/Documentation/memory-hotplug.txt
> >> +++ b/Documentation/memory-hotplug.txt
> >> @@ -254,12 +254,23 @@ If the memo
This run is configured for baseline tests only.
flight 38631 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38631/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-
flight 77965 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77965/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 59254
test-armhf-armhf-xl-m
This run is configured for baseline tests only.
flight 38629 qemu-upstream-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 10 gu
On 01/13/2016 02:45 AM, Will Deacon wrote:
I don't think the address dependency is enough on its own. By that
reasoning, the following variant (WRC+addr+addr) would work too:
P0:
Wx = 1
P1:
Rx == 1
Wy = 1
P2:
Ry == 1
Rx = 0
So are you saying that this is also forbidden?
Imagine that P0
flight 38630 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38630/
Perfect :-)
All tests in this flight passed
baseline version:
flight 38595
jobs:
build-amd64 pass
build-armhf
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-rumpuserxen-i386
testid guest-start
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditi
On 01/13/2016 12:48 PM, Peter Zijlstra wrote:
On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
I ask HW team about it but I have a question - has it any relationship with
replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)?
Of course. If you cannot explain the semantics o
On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
> I ask HW team about it but I have a question - has it any relationship with
> replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)?
Of course. If you cannot explain the semantics of the primitives you
introduce, how can we ju
On Wed, Jan 13, 2016 at 06:32:30PM +0100, Vitaly Kuznetsov wrote:
> Add support for the newly added kernel memory auto onlining policy to Xen
> ballon driver.
>
> Suggested-by: Daniel Kiper
> Signed-off-by: Vitaly Kuznetsov
In general Reviewed-by: Daniel Kiper
but one nitpick below...
Thank yo
On Wed, Jan 13, 2016 at 06:32:29PM +0100, Vitaly Kuznetsov wrote:
> Currently, all newly added memory blocks remain in 'offline' state unless
> someone onlines them, some linux distributions carry special udev rules
> like:
>
> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline",
> ATTR{sta
Hello David Vrabel,
The patch a4cdb556cae0: "xen/gntdev: add ioctl for grant copy" from
Dec 2, 2014, leads to the following static checker warning:
drivers/xen/gntdev.c:775 gntdev_get_page()
warn: mask and shift to zero
drivers/xen/gntdev.c
761 static int gntdev_get_page(stru
flight 77978 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77978/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62044
build-a
flight 77945 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77945/
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 5 xen-install fail REGR.
vs. 77892
test-amd64
On 01/13/2016 02:45 AM, Will Deacon wrote:
On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote:
I don't think the address dependency is enough on its own. By that
reasoning, the following variant (WRC+addr+addr) would work too:
P0:
Wx = 1
P1:
Rx == 1
Wy = 1
P2:
Ry == 1
Rx = 0
Currently, all newly added memory blocks remain in 'offline' state unless
someone onlines them, some linux distributions carry special udev rules
like:
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"
to make this happen automatically. This is not a great solution
Add support for the newly added kernel memory auto onlining policy to Xen
ballon driver.
Suggested-by: Daniel Kiper
Signed-off-by: Vitaly Kuznetsov
---
Changes since v4:
- 'dom0' -> 'control domain', 'domU' -> 'target domain' in Kconfig
[David Vrabel]
- always call add_memory_resource() with m
Changes since v4:
Patch 1:
- Use memory_block_change_state() through walk_memory_range() instead of
online_pages() to correctly handle possible failures [David Rientjes]
- Minor memory-hotplug.txt changes (keep the old title, explicitly word
that we have a global policy here) [David Rientjes, D
El 13/01/16 a les 17.29, Jan Beulich ha escrit:
On 13.01.16 at 13:32, wrote:
>> The BSP will be marked as initialised after hvm_load_cpu_ctxt has loaded the
>> initial state, which is called from the toolstack during domain creation.
>
> But the comment that you remove says explicitly that t
On 13/01/16 17:03, Boris Ostrovsky wrote:
> On 01/13/2016 11:30 AM, Andrew Cooper wrote:
>> On 13/01/16 16:26, Jan Beulich wrote:
>> On 13.01.16 at 17:17, wrote:
On 13/01/16 16:13, Jan Beulich wrote:
On 13.01.16 at 16:49, wrote:
>> Hello,
>>
>> While working on a HVM
On 01/13/2016 11:30 AM, Andrew Cooper wrote:
On 13/01/16 16:26, Jan Beulich wrote:
On 13.01.16 at 17:17, wrote:
On 13/01/16 16:13, Jan Beulich wrote:
On 13.01.16 at 16:49, wrote:
Hello,
While working on a HVMlite Dom0 implementation I've found a couple of
loose ends with the design that I
>>> On 23.12.15 at 09:25, wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -28,6 +28,11 @@
> #include "vtd.h"
> #include "extern.h"
>
> +static int __read_mostly iommu_qi_timeout_ms = 1;
> +integer_param("iommu_qi_timeout_ms", iommu_qi_timeo
>>> On 23.12.15 at 09:25, wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -28,6 +28,11 @@
> #include "vtd.h"
> #include "extern.h"
>
> +static int __read_mostly iommu_qi_timeout_ms = 1;
I'll take the liberty to convert this to "unsigned in
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 January 2016 16:39
> To: Paul Durrant; Roger Pau Monne
> Cc: Andrew Cooper; xen-de...@lists.xenproject.org
> Subject: Re: [PATCH 5/5] x86/HVM: don't setup an intercept handler for IO
> port 0xcf8 unconditionally
On 13/01/16 16:38, Jan Beulich wrote:
On 13.01.16 at 13:32, wrote:
>> Only intercept accesses to IO port 0xcf8 if there's at least one IOREQ
>> server, otherwise it makes no sense since the only code that uses the value
>> stored by hvm_access_cf8 is the IOREQ server.
> Afaict an ioreq server
Hello.
I tried to fix next error message:
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 13.01.16 at 13:32, wrote:
> Only intercept accesses to IO port 0xcf8 if there's at least one IOREQ
> server, otherwise it makes no sense since the only code that uses the value
> stored by hvm_access_cf8 is the IOREQ server.
Afaict an ioreq server could also attach subsequently - Paul?
Ja
Hi all,
I just put together the booking page for the next Hackathon. See
http://wiki.xenproject.org/wiki/Hackathon/April2016 for more information.
* If you are a maintainer or otherwise a core member of the community, just add
yourself to the Confirmed Attendees section stating your name and org
>>> On 13.01.16 at 13:32, wrote:
> The HVMlite series removed the initialization of the emulated PIT for PV
> guests, but the handler was still reachable, which means a PV guests can
> crash Xen if it pokes at IO ports 0x42, 0x43 or 0x61. Completely remove the
> PV PIT handler and move the PIT ini
On 13/01/16 16:26, Jan Beulich wrote:
On 13.01.16 at 17:17, wrote:
>> On 13/01/16 16:13, Jan Beulich wrote:
>> On 13.01.16 at 16:49, wrote:
Hello,
While working on a HVMlite Dom0 implementation I've found a couple of
loose ends with the design that I would like to com
>>> On 13.01.16 at 13:32, wrote:
> The BSP will be marked as initialised after hvm_load_cpu_ctxt has loaded the
> initial state, which is called from the toolstack during domain creation.
But the comment that you remove says explicitly that this isn't a
requirement.
Jan
> Signed-off-by: Roger P
>>> On 13.01.16 at 17:17, wrote:
> On 13/01/16 16:13, Jan Beulich wrote:
> On 13.01.16 at 16:49, wrote:
>>> Hello,
>>>
>>> While working on a HVMlite Dom0 implementation I've found a couple of
>>> loose ends with the design that I would like to comment because it's not
>>> clear to me what's
flight 77934 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77934/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 5 xen-install fail REGR. vs. 77871
Regressions which are reg
On 13/01/16 16:13, Jan Beulich wrote:
On 13.01.16 at 16:49, wrote:
>> Hello,
>>
>> While working on a HVMlite Dom0 implementation I've found a couple of
>> loose ends with the design that I would like to comment because it's not
>> clear to me what's the best direction to take.
>>
>> 1. HVM C
On 13/01/16 15:49, Roger Pau Monné wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
>
> Sadly the way CPUID
>>> On 13.01.16 at 17:00, wrote:
> On 13/01/16 15:36, Jan Beulich wrote:
> On 13.01.16 at 16:25, wrote:
>>> On 12/01/16 15:19, Jan Beulich wrote:
>>> On 12.01.16 at 12:55, wrote:
> On 12/01/16 10:08, Jan Beulich wrote:
>> This went unnoticed until a backport of this to an older X
On 13/01/16 17:01, Roger Pau Monné wrote:
> El 13/01/16 a les 16.56, Juergen Gross ha escrit:
>> On 13/01/16 16:49, Roger Pau Monné wrote:
>>> b) Setting up the initial MTRR state from libxl/libxc for HVMlite DomU
>>> and from the Xen domain builder for HVMlite Dom0. This again implies
>>> some fu
>>> On 13.01.16 at 16:49, wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
>
> Sadly the way CPUID is h
>>> On 13.01.16 at 16:54, wrote:
> On 13/01/16 15:49, Roger Pau Monné wrote:
>> While working on a HVMlite Dom0 implementation I've found a couple of
>> loose ends with the design that I would like to comment because it's not
>> clear to me what's the best direction to take.
>>
>> 1. HVM CPUID an
El 13/01/16 a les 16.54, David Vrabel ha escrit:
> On 13/01/16 15:49, Roger Pau Monné wrote:
>> 2. HVM MTRR and Dom0.
>>
>> MTRR ranges are initialised from hvmloader, which means that although we
>> expose the MTRR functionality to HVMlite guests (and AFAICT the
>> functionality is fully complete/
El 13/01/16 a les 16.56, Juergen Gross ha escrit:
> On 13/01/16 16:49, Roger Pau Monné wrote:
>> b) Setting up the initial MTRR state from libxl/libxc for HVMlite DomU
>> and from the Xen domain builder for HVMlite Dom0. This again implies
>> some functional duplication of MTRR related code, since
On 13/01/16 15:36, Jan Beulich wrote:
On 13.01.16 at 16:25, wrote:
>> On 12/01/16 15:19, Jan Beulich wrote:
>> On 12.01.16 at 12:55, wrote:
On 12/01/16 10:08, Jan Beulich wrote:
> This went unnoticed until a backport of this to an older Xen got used,
> causing migration of g
On 13/01/16 16:49, Roger Pau Monné wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
>
> Sadly the way CP
On 13/01/16 15:49, Roger Pau Monné wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
I think Andy's pendi
On 1/13/16 9:55 AM, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
> ---
> xen/Makefile |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/xen/Makefile b/xen/Makefile
> index d30d251..3699b20 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -109,7 +109,7
On 1/13/16 4:46 AM, Jan Beulich wrote:
> With xen/Makefile including include/config/auto.conf.cmd, environment
> variables checked in the latter must be available at the time of
> inclusion of that file, and hence must be populated in xen/Makefile
> rather than by passing to or inside xen/tools/kco
Hello,
While working on a HVMlite Dom0 implementation I've found a couple of
loose ends with the design that I would like to comment because it's not
clear to me what's the best direction to take.
1. HVM CPUID and Dom0.
Sadly the way CPUID is handled inside of Xen varies between PV and HVM.
On P
Signed-off-by: Boris Ostrovsky
---
xen/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index d30d251..3699b20 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -109,7 +109,7 @@ _clean: delete-unfresh-files
.PHONY: _distclean
_distcl
flight 77933 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77933/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 65543
test-amd64-amd64-
Cc: Stefano Stabellini
Cc: xen-de...@lists.xensource.com
Signed-off-by: Markus Armbruster
Message-Id: <1450370121-5768-14-git-send-email-arm...@redhat.com>
---
xen-hvm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen-hvm.c b/xen-hvm.c
index 3d78a0c..2a93390 100644
--- a/xen-hvm.c
On Wed, Jan 13, 2016 at 03:15:20PM +, Andrew Cooper wrote:
> On 13/01/16 14:53, Konrad Rzeszutek Wilk wrote:
> > Hey,
> >
> > We have some libxc calls for onlining/offlining the CPU and they
> > are quite good for testing how well Xen behaves without say
> > doing an S3 suspend or such.
> >
> >
>>> On 13.01.16 at 16:25, wrote:
> On 12/01/16 15:19, Jan Beulich wrote:
> On 12.01.16 at 12:55, wrote:
>>> On 12/01/16 10:08, Jan Beulich wrote:
This went unnoticed until a backport of this to an older Xen got used,
causing migration of guests enabling this VM assist to fail, becau
On 12/01/16 15:19, Jan Beulich wrote:
On 12.01.16 at 12:55, wrote:
>> On 12/01/16 10:08, Jan Beulich wrote:
>>> This went unnoticed until a backport of this to an older Xen got used,
>>> causing migration of guests enabling this VM assist to fail, because
>>> page table pinning there preceeds
On 01/13/2016 07:05 AM, Konrad Rzeszutek Wilk wrote:
On Mon, Jan 04, 2016 at 12:33:29PM -0500, Konrad Rzeszutek Wilk wrote:
Hey Jens,
ping ?
Pulled, sorry for the delay, I had some vacation post New Years that I
still haven't caught fully up on.
--
Jens Axboe
___
On 11/01/16 15:55, Aravind Gopalakrishnan wrote:
> On 9/22/2015 8:06 AM, Jan Beulich wrote:
>> ... in anticipation of this possibly going to get used by guests for
>> basic thinks like memset() or clearing or pages.
>>
>> Since the emulation doesn't use clzero itself, checking the guest's
>> CPUID
flight 77932 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77932/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3)broken REGR. vs. 60684
test-amd64
On 13/01/16 14:53, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> We have some libxc calls for onlining/offlining the CPU and they
> are quite good for testing how well Xen behaves without say
> doing an S3 suspend or such.
>
> It occurred to me that it would be nice to have them hook up in
> libxl/xl but
On Xen MSIs can be remapped into pirqs, which are a type of event
channels. It's mostly for the benefit of PCI passthrough devices, to
avoid the overhead of interacting with the emulated lapic.
However remapping interrupts and MSIs is also supported for emulated
devices, such as the e1000 and virt
Hey,
We have some libxc calls for onlining/offlining the CPU and they
are quite good for testing how well Xen behaves without say
doing an S3 suspend or such.
It occurred to me that it would be nice to have them hook up in
libxl/xl but I am not exactly sure what the right command line would be?
If the frontend sets out_cons to a value higher than out_prod, it will
cause xenfb_handle_events to loop about 2^32 times. Avoid that by using
better checks at the beginning of the function.
Signed-off-by: Stefano Stabellini
Reported-by: Ling Liu
---
Changes in v3:
- fix typo
---
diff --git
Introduce an option where the user can modifiy the maximum number of
supported physical CPUs.
Signed-off-by: Doug Goldstein
---
xen/arch/Kconfig | 8
xen/arch/arm/Kconfig | 2 ++
xen/arch/x86/Kconfig | 2 ++
3 files changed, 12 insertions(+)
create mode 100644 xen/arch/Kconfig
dif
On Wed, 13 Jan 2016, Markus Armbruster wrote:
> Markus Armbruster writes:
>
> > Stefano Stabellini writes:
> >
> >> On Thu, 17 Dec 2015, Markus Armbruster wrote:
> >>> Cc: Stefano Stabellini
> >>> Cc: xen-de...@lists.xensource.com
> >>> Signed-off-by: Markus Armbruster
> >>> ---
> >>> xen-hvm
On Mon, Jan 04, 2016 at 12:33:29PM -0500, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
ping ?
Thanks.
>
> Please pull in your "for-4.5/drivers" branch the following branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> stable/for-jens-4.5
>
> which is based on "bcache: Change
Markus Armbruster writes:
> Stefano Stabellini writes:
>
>> On Thu, 17 Dec 2015, Markus Armbruster wrote:
>>> Cc: Stefano Stabellini
>>> Cc: xen-de...@lists.xensource.com
>>> Signed-off-by: Markus Armbruster
>>> ---
>>> xen-hvm.c | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff
On 13/01/16 13:08, Jan Beulich wrote:
On 13.01.16 at 14:05, wrote:
>> On 13/01/16 13:02, Jan Beulich wrote:
>> On 13.01.16 at 13:52, wrote:
El 13/01/16 a les 13.46, Jan Beulich ha escrit:
On 13.01.16 at 13:32, wrote:
>> tools/libxc/xc_dom_elfloader.c | 2 +-
>>
>>> On 13.01.16 at 14:05, wrote:
> On 13/01/16 13:02, Jan Beulich wrote:
> On 13.01.16 at 13:52, wrote:
>>> El 13/01/16 a les 13.46, Jan Beulich ha escrit:
>>> On 13.01.16 at 13:32, wrote:
> tools/libxc/xc_dom_elfloader.c | 2 +-
> xen/common/libelf/libelf-dominfo.c | 1 +
>>
On 13/01/16 13:02, Jan Beulich wrote:
On 13.01.16 at 13:52, wrote:
>> El 13/01/16 a les 13.46, Jan Beulich ha escrit:
>> On 13.01.16 at 13:32, wrote:
>>> Re the title: I think the fix here really is to the checking against the
>>> right value, not the initialization?
>> Yes, the initiali
>>> On 13.01.16 at 13:52, wrote:
> El 13/01/16 a les 13.46, Jan Beulich ha escrit:
> On 13.01.16 at 13:32, wrote:
>>
>> Re the title: I think the fix here really is to the checking against the
>> right value, not the initialization?
>
> Yes, the initialization doesn't matter much, the prope
flight 77919 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77919/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 9 debian-install fail like 77846
Tests which did not succeed,
This run is configured for baseline tests only.
flight 38627 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38627/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 capture-logs
On Wed, 13 Jan 2016, David Vrabel wrote:
> On 12/01/16 12:07, Stefano Stabellini wrote:
> > On Mon, 11 Jan 2016, David Vrabel wrote:
> >> On 11/01/16 17:17, Andrew Cooper wrote:
> >>> So from one point of view, sufficient justification for this change is
> >>> "because the Linux way isn't the only
El 13/01/16 a les 13.46, Jan Beulich ha escrit:
On 13.01.16 at 13:32, wrote:
>
> Re the title: I think the fix here really is to the checking against the
> right value, not the initialization?
Yes, the initialization doesn't matter much, the proper fix is the
checking. I would change it to:
>>> On 13.01.16 at 13:32, wrote:
Re the title: I think the fix here really is to the checking against the
right value, not the initialization?
> tools/libxc/xc_dom_elfloader.c | 2 +-
> xen/common/libelf/libelf-dominfo.c | 1 +
> xen/include/xen/libelf.h | 1 +
> 3 files changed,
Hello,
This series contains some bug fixes for HVMlite DomU and some preparatory
patches for HVMlite Dom0 support.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Current implementation of elf_load_bsdsyms is broken when loading inside of
a HVM guest, because it assumes elf_memcpy_safe is able to write into guest
memory space, which it is not.
Take the oportunity to do some cleanup and properly document how
elf_{parse/load}_bsdsyms works. The new implementa
Only intercept accesses to IO port 0xcf8 if there's at least one IOREQ
server, otherwise it makes no sense since the only code that uses the value
stored by hvm_access_cf8 is the IOREQ server.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 8 +
And introduce UNSET_ADDR32.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxc/xc_dom_elfloader.c | 2 +-
xen/common/libelf/libelf-dominfo.c | 1 +
xen/include/xen/libelf.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff
The HVMlite series removed the initialization of the emulated PIT for PV
guests, but the handler was still reachable, which means a PV guests can
crash Xen if it pokes at IO ports 0x42, 0x43 or 0x61. Completely remove the
PV PIT handler and move the PIT initialization to HVM guests only.
Signed-of
The BSP will be marked as initialised after hvm_load_cpu_ctxt has loaded the
initial state, which is called from the toolstack during domain creation.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 4
1 file changed, 4 deletions(-)
diff
1 - 100 of 122 matches
Mail list logo
