flight 105075 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 5 xen-install fail REGR. vs. 104989
Regressions which are r
flight 105038 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105038/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10fail REGR. vs. 59254
test-amd64-i386-xl
flight 105018 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105018/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
104681
test-amd64-a
This run is configured for baseline tests only.
flight 68500 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68500/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-che
This run is configured for baseline tests only.
flight 68501 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68501/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7fcb735412998d536cb348049c4ea60897fa6886
baseline v
On 5/6/16 10:48 AM, Ross Lagerwall wrote:
> Here is a set of changes to make building xSplice patches easier.
> Tested to boot on x86.
> Compile-tested on arm.
>
> This is probably too late to make it into 4.7, but hey, if someone wants
> to put it in I've CC'd Wei.
Ross,
What happened with this
On Thu, Jan 19, 2017 at 02:01:06PM +0800, Yi Sun wrote:
> This patch implements the CPU init and free flow including L3 CAT
> initialization and feature list free.
>
> Signed-off-by: Yi Sun
> ---
> v5:
> - modify commit message beacuse of code changes.
> - add 'struct cpuid_leaf_regs' to
flight 105047 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105047/
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
flight 105046 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105046/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7fcb735412998d536cb348049c4ea60897fa6886
baseline version:
ovmf 465663e9f128428323e6c
On 01/30/2017 04:51 PM, osstest service owner wrote:
flight 105012 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105012/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl 17 guest-loca
flight 105036 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105036/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 15 guest-localmigrate/x10 fail REGR.
vs. 105021
T
flight 105016 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105016/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104844
test-amd64-amd64-xl-qemuu-
.snip..
> CDP is a special feature which uses two entries of the array
> for one COS ID. So, the number of CDP COS registers is the half of L3
> CAT. E.g. L3 CAT has 16 COS registers, then CDP has 8 COS registers if
> it is enabled. CDP uses the COS registers array as below.
>
>
On Thu, Jan 19, 2017 at 02:01:04PM +0800, Yi Sun wrote:
> The current cache allocation codes in psr.c do not consider
> future features addition and are not friendly to extend.
>
> To make psr.c be more flexible to add new features and fulfill
> the program principle, open for extension but closed
flight 105012 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105012/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl 17 guest-localmigrate/x10fail REGR. vs. 59254
test-armhf-armhf-xl
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-multivcpu
testid xen-boot
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: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xe
On Mon, 30 Jan 2017, Tamas K Lengyel wrote:
> On Mon, Jan 30, 2017 at 9:01 AM, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 27/01/17 23:53, Stefano Stabellini wrote:
> >>
> >> On Fri, 27 Jan 2017, Julien Grall wrote:
> >>>
> >>> On 27/01/2017 20:41, Stefano Stabellini wrote:
>
> On Fri
On Fri, 9 Dec 2016, Tamas K Lengyel wrote:
> This patch relocates mem_access components that are currently mixed with p2m
> code into separate files. This better aligns the code with similar subsystems,
> such as mem_sharing and mem_paging, which are already in separate files. There
> are no code-c
On Fri, 9 Dec 2016, Tamas K Lengyel wrote:
> The only caller of this function is get_page_from_gva which already takes
> a vcpu pointer as input. Pass this along to make the function in-line with
> its intended use-case.
>
> Signed-off-by: Tamas K Lengyel
Reviewed-by: Stefano Stabellini
> ---
Hi all,
a couple of weeks ago I sent a detailed email asking for feedback on a
problem with Linux on Xen on ACPI systems:
http://marc.info/?l=linux-arm-kernel&m=148469169210500&w=2
In short, on BUS_NOTIFY_ADD_DEVICE events, Linux (as Dom0) requests
stage-2 MMIO regions mappings via hypercall to
> > +# Testing
> > +
> > +L2 CAT uses same xl interfaces as L3 CAT/CDP. So, we can execute these
> > +commands to verify L2 CAT and L3 CAT/CDP on different HWs support them.
> > +
> > +For example:
> > +root@:~$ xl psr-hwinfo --cat
> > +Cache Allocation Technology (CAT): L2
> > +Socket
flight 105019 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105019/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 013927f81afb08e06314b66c8c8cd8549d5711c1
baseline version:
xtf 7e1bc8009286dcf505a1be
On 01/30/2017 02:06 PM, Eric Dumazet wrote:
> On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
>
>> We do netif_carrier_off() first thing in xennet_disconnect_backend() and
>> the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
>> which is guarded by netif_carrier_ok()
On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
> We do netif_carrier_off() first thing in xennet_disconnect_backend() and
> the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
> which is guarded by netif_carrier_ok() check.
Oh well, testing netif_carrier_ok() in pac
George / Tamas,
I'm away from my dev machine so I cannot test. Thank you both for
working so quickly to resolve this behavior!
Best regards,
--Matt
On 01/30/2017 11:07 AM, Tamas K Lengyel wrote:
> Hi George,
> yeap, this solves old mem_access settings being triggered when I
> recreate altp2m vie
The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
This is nasty to emulate exactly with our architecture, so we just scan
the pending table and inject _every_ LPI found there that got enabled.
Signed-off-by: An
The MOVI command moves the interrupt affinity from one redistributor
(read: VCPU) to another.
For now migration of "live" LPIs is not yet implemented, but we store
the changed affinity in the host LPI structure and in our virtual ITTE.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-its.c
For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 28
xen/arch/arm/vgic-v3.c | 12
xen/in
Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers and map those pages into Xen's address space to have easy
access.
Signed-off-by: Andre Przywara
To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if the host has initialized at least
one ITS.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3.c | 88
The INV command instructs the ITS to update the configuration data for
a given LPI by re-reading its entry from the property table.
We don't need to care so much about the priority value, but enabling
or disabling an LPI has some effect: We remove or push virtual LPIs
to their VCPUs, also check the
The INT command sets a given LPI identified by a DeviceID/EventID pair
as pending and thus triggers it to be injected.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/a
This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 35 +--
1 file changed, 33
Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
number to get this IRQ injected.
Iterate our two-level LPI table to find this information quickly when
the host takes an LPI. Call the existing injection function to let the
GIC emulation deal with this interrupt.
Signed-off-by:
The DISCARD command drops the connection between a DeviceID/EventID
and an LPI/collection pair.
We mark the respective structure entries as not allocated and make
sure that any queued IRQs are removed.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 33
Now that the host part of the ITS code is in place, we can enable the
ITS and also LPIs on each redistributor to get the show rolling.
At this point there would be no LPIs mapped, as guests don't know about
the ITS yet.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-its.c | 34 +++
Create a new file to hold the emulation code for the ITS widget.
For now we emulate the memory mapped ITS registers and provide a stub
to introduce the ITS command handling framework (but without actually
emulating any commands at this time).
Signed-off-by: Andre Przywara
---
xen/arch/arm/Makefi
To get MSIs from devices forwarded to a CPU, we need to name the device
and its MSIs by mapping them to an ITS.
Since this involves queueing commands to the ITS command queue, we can't
really afford to do this during the guest's runtime, as this would open
up a denial-of-service attack vector.
So w
Dom0 expects all ITSes in the system to be propagated to be able to
use MSIs.
Create Dom0 DT nodes for each hardware ITS, keeping the register frame
address the same, as the doorbell address that the Dom0 drivers program
into the BARs has to match the hardware.
Signed-off-by: Andre Przywara
---
If a guest disables an LPI, we do not forward this to the associated
host LPI to avoid queueing commands to the host ITS command queue.
So it may happen that an LPI fires nevertheless on the host. In this
case we can bail out early, but have to save the pending state on the
virtual side.
Signed-of
The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering IRQ on the host can be quickly forwarded to a guest.
Signed-off-by: Andre Przywara
---
xen/arc
The ITS stores the target (v)CPU and the (virtual) LPI number in tables.
Introduce functions to walk those tables and translate an device ID -
event ID pair into a pair of virtual LPI and vCPU.
Since the final interrupt translation tables can be smaller than a page,
we map them on demand (which is
The MAPD command maps a device by associating a memory region for
storing ITTEs with a certain device ID.
We just store the given guest physical address in the device table.
We don't map the device tables permanently, as their alignment
requirement is only 256 Bytes, thus making mapping of several
The MAPC command associates a given collection ID with a given
redistributor, thus mapping collections to VCPUs.
We just store the vcpu_id in the collection table for that.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 30 ++
1 file changed, 30 insert
The number of LPIs on a host can be potentially huge (millions),
although in practise will be mostly reasonable. So prematurely allocating
an array of struct irq_desc's for each LPI is not an option.
However Xen itself does not care about LPIs, as every LPI will be injected
into a guest (Dom0 for n
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.
Allocate the respective memory and enter each device into an rbtree to
late
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 the command queue (SYNC).
Start using these commands fo
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 tables, which software
has to provide for the ITS to use
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 required memory, initialize it and hand it over to each
r
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.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-
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.
Signed-off-by: Andre Przywara
---
xen/arch/arm/Kconf
For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. However we actually only need those when an
interrupt is on a vCPU (or is about to be injected).
Maintain a list of those structs that we can
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.
Signed-off-by: Andre Przywara
---
xen/arch/arm/efi/efi-boot.h | 1 -
xen/include/asm-arm/cache.h | 4
2 files changed, 4
Hi,
after the two RFC versions now the first "serious" attempt for emulating
an ARM GICv3 ITS interrupt controller, for Dom0 only at the moment.
The ITS is an interrupt controller widget providing a sophisticated way
of dealing with MSIs in a scalable manner.
For hardware which relies on the ITS t
We can switch ACPI from using fixmap to dynamic mapping as soon as
the system enters SYS_STATE_boot. This will allow us, for example,
to map MADT on systems with large number of processors where the
table might not fit into NUM_FIXMAP_ACPI_PAGES (currently set to 4).
Signed-off-by: Boris Ostrovsky
On 01/30/2017 01:07 PM, Eric Dumazet wrote:
> On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote:
>> rx_refill_timer should be deleted as soon as we disconnect from the
>> backend since otherwise it is possible for the timer to go off before
>> we get to xennet_destroy_queues(). If this happe
On Thu, Jan 19, 2017 at 02:01:03PM +0800, Yi Sun wrote:
> This patch creates L2 CAT feature document in doc/features/.
> It describes details of L2 CAT.
Perhaps also mention what is the title in the Intel SDM
to look into as well?
Perhaps:
"See Intel Resource Director Technology Monitoring Featur
On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote:
> rx_refill_timer should be deleted as soon as we disconnect from the
> backend since otherwise it is possible for the timer to go off before
> we get to xennet_destroy_queues(). If this happens we may dereference
> queue->rx.sring which is
On 30/01/17 16:54, Andrew Cooper wrote:
> The ept_get_*() helpers are not used consistently, and are more verbose than
> the code they wrap. Drop the wrappers and use the internal union names
> consistently.
>
> While making these adjustments, drop the redundant ept_* prefix from mt, wl
> and ad,
On 30/01/17 17:26, Andrew Cooper wrote:
> No functional change yet, but required for subsequent changes.
>
> Signed-off-by: Andrew Cooper
Acked-by: George Dunlap
> ---
> CC: Jan Beulich
> CC: Tim Deegan
> CC: George Dunlap
> ---
> xen/arch/x86/domain.c | 3 ++-
> xen/arch/x86/mm/
rx_refill_timer should be deleted as soon as we disconnect from the
backend since otherwise it is possible for the timer to go off before
we get to xennet_destroy_queues(). If this happens we may dereference
queue->rx.sring which is set to NULL in xennet_disconnect_backend().
Signed-off-by: Boris
The vTLB and last_write* booleans are used exclusively by the shadow pagetable
code. Move them from paging_vcpu to shadow_vcpu, which causes them to be
entirely omitted on a build without shadow paging support.
While changing the qualified names of these variables, drop an unnessary NULL
check be
No functional change yet, but required for subsequent changes.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
---
xen/arch/x86/domain.c | 3 ++-
xen/arch/x86/mm/hap/hap.c | 3 ++-
xen/arch/x86/mm/paging.c| 6 +++---
xen/arch/x86/mm/sh
From: "Edgar E. Iglesias"
Move the early setting of PSCI_RESULT_REG to a later stage
avoiding the early override of the FID that's stored in
the same register.
No functional change.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/traps.c | 7 +--
1 file changed, 5 insertions(+), 2 delet
From: "Edgar E. Iglesias"
Allow platform_hvc to handle guest SMC calls (as well as
HVC calls) in a platform specific way.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/traps.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index e8cd111..
From: "Edgar E. Iglesias"
Forward platform specific firmware calls from the hardware
domain to firmware.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/platforms/xilinx-zynqmp.c | 63 ++
1 file changed, 63 insertions(+)
diff --git a/xen/arch/arm/platforms/xi
From: "Edgar E. Iglesias"
Stop blacklisting ZynqMP's power management node.
This is now possible since we allow the hardware domain to
issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/platforms/xilinx-zynqmp.c | 8
1 file changed, 8 deletions(-)
diff
From: "Edgar E. Iglesias"
Introduce call_smcc64, a helper function to issue 64-bit SMC
calls that follow the SMC Calling Convention. This includes
returning up to 4 64-bit values.
Signed-off-by: Edgar E. Iglesias
---
xen/include/asm-arm/processor.h | 40
From: "Edgar E. Iglesias"
The ZynqMP software stack has an extensive Firmware API.
Software at EL1 is increasingly dependant on this API. In fact,
a large set of use-cases for Linux already require access
to firmware. In a couple of months, we expect that most setups
will need it, so this is beco
From: "Edgar E. Iglesias"
Introduce platform_hvc as a way to handle hypercalls that
Xen does not know about in a platform specific way. This
is particularly useful for implementing the SiP (SoC
implementation specific) service calls.
Signed-off-by: Edgar E. Iglesias
---
xen/arch/arm/platform.c
On Mon, Jan 30, 2017 at 9:01 AM, Julien Grall wrote:
> Hi Stefano,
>
> On 27/01/17 23:53, Stefano Stabellini wrote:
>>
>> On Fri, 27 Jan 2017, Julien Grall wrote:
>>>
>>> On 27/01/2017 20:41, Stefano Stabellini wrote:
On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
>>>
>>> For the second ins
On 01/30/2017 09:06 AM, Boris Ostrovsky wrote:
On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:
2. It tickles a latent bug during resume where the timer triggers
before we re-connect. The trouble is that we now try to dereference
queue->rx.sring which is NULL since we disconnect in
netfro
Hi George,
yeap, this solves old mem_access settings being triggered when I
recreate altp2m views. Thanks!
On Mon, Jan 30, 2017 at 8:17 AM, George Dunlap wrote:
> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
> nested p2m tables whenever the host p2m table changed. Unfortunat
On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:
>
>> 2. It tickles a latent bug during resume where the timer triggers
>> before we re-connect. The trouble is that we now try to dereference
>> queue->rx.sring which is NULL since we disconnect in
>> netfront_resume(). (Curiously, I only observ
The ept_get_*() helpers are not used consistently, and are more verbose than
the code they wrap. Drop the wrappers and use the internal union names
consistently.
While making these adjustments, drop the redundant ept_* prefix from mt, wl
and ad, and rename the asr field to mfn for consistency wit
This results in rather more readable code. No functional change.
All fields currently specified are included, but commented out as no support
for their use is present.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vmx.c| 41
On 01/29/2017 03:09 PM, Boris Ostrovsky wrote:
There are couple of problems with this patch.
1. The 'if' clause now evaluates to true on pretty much every call to
xennet_alloc_rx_buffers().
Thanks for catching this. In my testing I did not notice this - mostly
because of the nature of the wor
flight 105021 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105021/
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
On Mon, Jan 30, 2017 at 03:33:19PM +, Julien Grall wrote:
>
> == Testing ==
>
> * Continuous fuzzing of Xen code using Google oss-fuzz
> - Wei Liu
>
Stuck as we need someone to write the code to integrate things into
oss-fuzz.
Wei.
___
Xen-
Hi Stefano,
On 27/01/17 23:53, Stefano Stabellini wrote:
On Fri, 27 Jan 2017, Julien Grall wrote:
On 27/01/2017 20:41, Stefano Stabellini wrote:
On Fri, 27 Jan 2017, Tamas K Lengyel wrote:
For the second instance, we have no other choice.
Most alloc_heap_pages (alloc_xenheap_pages and alloc
On 30/01/17 16:46, Peter Maydell wrote:
> On 30 January 2017 at 15:14, Juergen Gross wrote:
>> The error exits of xen_pv_find_xendev() free the new xen-device via
>> g_free() which is wrong.
>>
>> As the xen-device has been initialized as qdev it must be removed
>> via qdev_unplug().
>>
>> This bu
On 30 January 2017 at 15:14, Juergen Gross wrote:
> The error exits of xen_pv_find_xendev() free the new xen-device via
> g_free() which is wrong.
>
> As the xen-device has been initialized as qdev it must be removed
> via qdev_unplug().
>
> This bug has been introduced with commit 3a6c9172ac5951e
On Mon, Jan 30, 2017 at 03:32:49PM +, Julien Grall wrote:
[...]
> > > >
> > > > I think it would be good to main two lists. One of "the stuff people
> > > > are working on overall", and "the subset of it intended/expected for the
> > > > forthcoming release".
> > > >
> > > > Stuff will invar
Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
nested p2m tables whenever the host p2m table changed. Unfortunately
in the process, it added a filter to the generic p2m_flush_table()
function so that the p2m would only be flushed if it was being used as
a nested p2m. This meant
This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a fixed
Hi,
On 26/01/17 17:06, Wei Liu wrote:
On Thu, Jan 26, 2017 at 12:27:15PM +, Julien Grall wrote:
Hi,
On 09/12/2016 19:09, Andrew Cooper wrote:
On 09/12/16 19:01, Stefano Stabellini wrote:
On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
O
Jan,
Sure. I will look in to it.
Venu
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 30, 2017 04:39 AM
> To: Andrew Cooper; Elena Ufimtseva; Venu Busireddy
> Cc: Xen-devel
> Subject: Re: [PATCH] VT-d/RMRR: Avoid memory corruption in add_user_
The error exits of xen_pv_find_xendev() free the new xen-device via
g_free() which is wrong.
As the xen-device has been initialized as qdev it must be removed
via qdev_unplug().
This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6
("xen: create qdev for each backend device").
Report
Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device. Use the default as fallback only.
Signed-off-by: Juergen Gross
---
V3: add case of late framebuffer registration (Oleksandr Andrushchenko)
V2:
libxl_domain_build_info_dispose is not resetting the type field to
LIBXL_DOMAIN_TYPE_INVALID.
Instead, it is memseting the struct to 0 thus when
libxl_domain_build_info_init_type is called
after a dispose on the same struct, an assertion is triggered because type !=
LIBXL_DOMAIN_TYPE_INVALID.
Ca
If we have no disk attached at startup, diskws is left unallocated
but `d_config.num_disks` may change if we attach a disk later.
When a domain is rebooted `evdisable_disk_ejects` is called
this will later result in a segfault if num_disks has changed.
Expand diskws when num_disks increases.
Sign
On Mon, Jan 30, 2017 at 07:24:57AM -0700, Jan Beulich wrote:
> >>> On 30.01.17 at 15:17, wrote:
> > On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote:
> >> >>> On 30.01.17 at 13:46, wrote:
> >> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
> >> >> On Thu, Jan 26, 2017 at 03
>>> On 30.01.17 at 15:17, wrote:
> On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote:
>> >>> On 30.01.17 at 13:46, wrote:
>> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
>> >> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
>> >> > >>> On 25.01.17 at 16:44, w
On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote:
> >>> On 30.01.17 at 13:46, wrote:
> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
> >> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
> >> > >>> On 25.01.17 at 16:44, wrote:
> >> > > ... so that they can be u
flight 105009 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105009/
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
>>> On 30.01.17 at 13:46, wrote:
> On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
>> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
>> > >>> On 25.01.17 at 16:44, wrote:
>> > > ... so that they can be used by userspace x86 instruction emulator test
>> > > program and fuzze
On Fri, Jan 27, 2017 at 12:13:58PM +0100, Juergen Gross wrote:
> On 24/01/17 17:42, Roger Pau Monné wrote:
> > Hello,
> >
> > The following commit:
> >
> > commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894
> > Author: Juergen Gross
> > Date: Tue Nov 22 07:10:58 2016 +0100
> >
> > xen: create qd
flight 104981 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104981/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
104681
test-amd64-a
flight 104984 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104984/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10fail REGR. vs. 59254
test-amd64-i386-xl
On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote:
> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote:
> > >>> On 25.01.17 at 16:44, wrote:
> > > ... so that they can be used by userspace x86 instruction emulator test
> > > program and fuzzer as well.
> >
> > Ah, here we go. This
1 - 100 of 119 matches
Mail list logo
