flight 60753 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 60680
test-armhf-armhf-xl-mu
flight 60761 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60761/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60652
Tests which did not succeed, but a
On 19/08/2015 20:07, Shannon Zhao wrote:
and I
don't think the domid field needs an explanation TBH.
Within the register, check if the device is newly added, then call
hypercall XENMEM_add_to_physmap to map the mmio regions.
For PCI bus device, it could reuse the existing PCI bus_notifier l
flight 60759 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60759/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 70bd69912ad2fb6e99271b418f87b98ebb36e0d8
baseline version:
ovmf 5dd08a463d5ca40b2ee3a8a0639c846e682
Hi Jan,
On 2015/8/19 22:05, Jan Beulich wrote:
On 19.08.15 at 14:13, wrote:
>> 1. Create minimal DT to pass required information to Dom0
>> --
>> Since there are no legacy interfaces like x86 for Dom0 to get the
>> booting required info
Hi Roger,
On 2015/8/19 23:02, Roger Pau Monné wrote:
> El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
>> 4. Map MMIO regions
>> ---
>> Register a bus_notifier for platform and amba bus in Linux. Add a new
>
> Can we make this OS agnostic? Could you explain what you mean with the
Hi,
Ping? I'm missing some reviews on block and netfront code.
We'd like to see this series going in Linux 4.3. Some distributions
plans to use this version for aarch64 support. If we miss it, we won't
have any Xen guests support, even it's minimal, for Linux using 64KB
page granularity.
Re
Hi,
On 19/08/2015 06:25, Murilo Opsfelder Araujo wrote:
The commit 091208a676dfdabb2b8fe86ee155c6fc80081b69 "xen/tmem: Use
xen_page_to_gfn rather than pfn_to_gfn" left behind a call to
xen_tmem_get_page() receiving pfn instead of page.
This change also fixes the following build warning:
driver
On Wed, 19 Aug 2015, Roger Pau Monné wrote:
> My opinion is that we have already merged quite a lot of this mess in
> order to support guests with different page sizes. And in this case, the
> addition of code can be done to a userspace component, which is much
> less risky than adding it to blkfro
Hi Jan,
On 19/08/2015 07:05, Jan Beulich wrote:
... wouldn't it make more sense to leave the generation of these
Linux-specific tags to Linux (and allow them to continue to be Linux
specific), by the same or a second, parallel (Xen) stub? This would
then also move at least some of the awkward ta
On Wed, 2015-08-19 at 00:47 +, Kun Cheng wrote:
> Live migration between nodes is perhaps the easiest way. But it also
> has draw backs mainly because that migration is coarse-grained.
>
What I'm saying is that you can, as a first step, look at the migration
code and implement (let's call it
Commit b1c9f169047b ("xen: split counting of extra memory pages...")
introduced an error when dom0 was started with limited memory occurring
only on some hardware.
The problem arises in case dom0 is started with initial memory and
maximum memory being the same. The kernel must be configured withou
Commit b1c9f169047b ("xen: split counting of extra memory pages...")
introduced an error when dom0 was started with limited memory.
The problem arises in case dom0 is started with initial memory and
maximum memory being the same and exactly a multiple of 1 GB. The
kernel must be configured without
On 19/08/15 16:43, Tim Deegan wrote:
At 16:04 +0100 on 19 Aug (144260), Ben Catterall wrote:
I've hit a blocker on getting this working for AMD's SVM and would
appreciate any thoughts. Hopefully I've missed a much simpler way of
doing this or I've missed something!
So, AMD and Intel diffe
> -Original Message-
> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 August 2015 02:16
> To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini;
> Ian
> Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
> Cc: Kevin Tian; zhiyuan...@inte
> -Original Message-
> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 August 2015 02:16
> To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini;
> Ian
> Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
> Cc: Kevin Tian; zhiyuan...@inte
On Tue, Aug 18, 2015 at 09:55:56AM -0700, Randy Dunlap wrote:
> On 08/18/15 04:40, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20150817:
> >
>
> on i386:
>
> CONFIG_SMP is not enabled.
> # CONFIG_X86_UP_APIC is not set
I think this is related to fc5fee86bdd3d720e2d1d324e4fae0c358
On 19/08/2015 08:17, Roger Pau Monné wrote:
Hello,
El 19/08/15 a les 16.54, Julien Grall ha escrit:
On 19/08/2015 01:50, Roger Pau Monné wrote:
Why can this be fixed in the Qemu side and the fix backported to 4.6.1?
And what about any other backend not supporting indirect grant?
The only
At 16:04 +0100 on 19 Aug (144260), Ben Catterall wrote:
> I've hit a blocker on getting this working for AMD's SVM and would
> appreciate any thoughts. Hopefully I've missed a much simpler way of
> doing this or I've missed something!
>
> So, AMD and Intel differ in how they handle the TR on
flight 60746 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat
fail REGR. vs. 60654
Reg
On 19/08/2015 01:58, Jan Beulich wrote:
On 18.08.15 at 20:45, wrote:
Hi Roger,
On 18/08/2015 00:09, Roger Pau Monné wrote:
Hello,
El 18/08/15 a les 8.29, Julien Grall ha escrit:
Hi,
Firstly, this patch is not ready at all and mostly here for collecting
comment about the way to do it. It's
Hello,
El 19/08/15 a les 16.54, Julien Grall ha escrit:
> On 19/08/2015 01:50, Roger Pau Monné wrote:
>> Why can this be fixed in the Qemu side and the fix backported to 4.6.1?
>
> And what about any other backend not supporting indirect grant?
The only other backend I know of is tapdisk/blktap,
Hi all,
I've hit a blocker on getting this working for AMD's SVM and would
appreciate any thoughts. Hopefully I've missed a much simpler way of
doing this or I've missed something!
So, AMD and Intel differ in how they handle the TR on a VMEXIT and
VMRUM. On a VMEXIT, Intel Save the guest's T
El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
> 4. Map MMIO regions
> ---
> Register a bus_notifier for platform and amba bus in Linux. Add a new
Can we make this OS agnostic? Could you explain what you mean with the
above sentence without using Linux kernel internals?
> XENMAP
On 19/08/2015 01:50, Roger Pau Monné wrote:
El 18/08/15 a les 20.45, Julien Grall ha escrit:
Hi Roger,
On 18/08/2015 00:09, Roger Pau Monné wrote:
Hello,
El 18/08/15 a les 8.29, Julien Grall ha escrit:
Hi,
Firstly, this patch is not ready at all and mostly here for
collecting comment abou
>>> On 19.08.15 at 14:13, wrote:
> 1. Create minimal DT to pass required information to Dom0
> --
> Since there are no legacy interfaces like x86 for Dom0 to get the
> booting required information on ARM, here we use the minimal DT which is
>
This document is going to explain the design details of Xen booting with
ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
welcome.
Changes v3->v4:
* add explanation for minimal DT and the properties
* drop "linux," prefix of the properties
* add explanation for the event cha
Hi Jens & Christoph,
Rafal reported an issue about this patch, that's after this patch no more
merges happen and the performance dropped if "modprobe null_blk irqmode=2
completion_nsec=100",
but works fine if "modprobe null_blk".
I'm not sure whether it's as expect or not.
Do you have any
On 18/08/15 17:55, Andrew Cooper wrote:
On 17/08/15 08:07, Tim Deegan wrote:
At 14:53 +0100 on 17 Aug (1439823232), Ben Catterall wrote:
On 12/08/15 14:33, Andrew Cooper wrote:
On 12/08/15 14:29, Andrew Cooper wrote:
On 11/08/15 19:29, Boris Ostrovsky wrote:
Would switching TR only when
flight 60742 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60742/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt-vhd 9 debian-di-install fail baseline untested
test-amd64-i386-libvirt
On 19/08/15 01:19, Luis R. Rodriguez wrote:
> Here are the notes / slides / conclusions from the pv yielding BoF:
>
> https://docs.google.com/presentation/d/1M4GJoV6LZ5UssgL2iv5b2Da_yd9zF5t6797uRVQFInY/edit#slide=id.p
I have no idea what you mean by "PV yielding".
FWIW, my preferred longterm pla
This patch uses HVMOP_IO_RANGE_XXX values rather than the raw ioreq
type to select the ioreq server, therefore the identical relationship
between ioreq type and rangeset type is no longer necessary.
Signed-off-by: Yu Zhang
---
xen/arch/x86/hvm/hvm.c | 16 +++-
1 file changed, 7 inser
This patch refactors struct rangeset to base it on the red-black
tree structure, instead of on the current doubly linked list. By
now, ioreq leverages rangeset to keep track of the IO/memory
resources to be emulated. Yet when number of ranges inside one
ioreq server is very high, traversing a doubl
XenGT leverages ioreq server to track and forward the accesses to
GPU I/O resources, e.g. the PPGTT(per-process graphic translation
tables). Currently, ioreq server uses rangeset to track the BDF/
PIO/MMIO ranges to be emulated. To select an ioreq server, the
rangeset is searched to see if the I/O
Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected pages may be discrete ranges with 4K bytes each.
This patch uses a seperate rangeset for the guest
On 8/18/2015 9:25 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 17 August 2015 22:34
To: Paul Durrant; xen-devel@lists.xen.org; Ian Jackson; Stefano Stabellini; Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
>>> On 18.08.15 at 20:45, wrote:
> Hi Roger,
>
> On 18/08/2015 00:09, Roger Pau Monné wrote:
>> Hello,
>>
>> El 18/08/15 a les 8.29, Julien Grall ha escrit:
>>> Hi,
>>>
>>> Firstly, this patch is not ready at all and mostly here for collecting
> comment about the way to do it. It's not clean so
El 18/08/15 a les 20.45, Julien Grall ha escrit:
> Hi Roger,
>
> On 18/08/2015 00:09, Roger Pau Monné wrote:
>> Hello,
>>
>> El 18/08/15 a les 8.29, Julien Grall ha escrit:
>>> Hi,
>>>
>>> Firstly, this patch is not ready at all and mostly here for
>>> collecting comment about the way to do it. It
flight 37838 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37838/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 37821
test-am
flight 60727 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60727/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-qcow2 5 xen-install fail in 60696 pass in 60727
test-armhf-armhf-xl-multivcpu 1
40 matches
Mail list logo
