flight 60777 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60777/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-vhd 6 xen-boot fail in 60713 pass in 60777
test-amd64-amd64-xl-qemuu-ovmf-am
> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: Friday, August 21, 2015 11:31 AM
>
> 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-
> prote
flight 60776 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60776/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat
fail REGR. v
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 r
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
Reviewed-by: Paul Durrant
---
xen/arch/x86/hvm/hvm.c | 16 +++---
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
On 2015/8/20 21:46, Roger Pau Monné wrote:
> El 20/08/15 a les 14.29, Shannon Zhao ha escrit:
>>
>>
>> On 2015/8/20 19:28, Roger Pau Monné wrote:
>>> El 20/08/15 a les 13.22, Shannon Zhao ha escrit:
Hi Roger,
On 2015/8/20 16:20, Roger Pau Monné wrote:
> El 20/08/15 a les 5.07,
On 8/20/2015 12:16 AM, Paul Durrant wrote:
-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
On 2015/8/20 22:06, Jan Beulich wrote:
On 20.08.15 at 14:56, wrote:
>
>>
>> On 2015/8/20 17:30, Jan Beulich wrote:
>> On 20.08.15 at 05:41, wrote:
On 2015/8/19 22:05, Jan Beulich wrote:
On 19.08.15 at 14:13, wrote:
>> 1. Create minimal DT to pass required informatio
On 20/08/2015 10:42, David Vrabel wrote:
When using 64KB page, a Linux block request (struct *request) may
contain up to 64KB of data. This is because the block segment size
must at least be the size of a Linux page.
You should ensure you configure the request queue with the limits that
are c
Ensure that every bit has a specific value.
Reported-by: Julien Grall
Signed-off-by: Chris Brand
---
v2 adds comments on pxn and avail.
xen/include/asm-arm/page.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 01628f3e96cb
Shuffle lines around so that the assignments in mfn_to_xen_entry()
occur in the same order as the bits are declared in lpae_pt_t.
This makes it easier to see which ones are never given a value.
No change in behaviour.
Also fix a minor comment typo.
Signed-off-by: Chris Brand
Reviewed-by: Julien
This is more-or-less what Julien requested. He noted that pt.config
was never set to zero. When I looked further, I found other bits that
were also never given a value. Looking at the callsites, they almost
all seem to assume a value of zero, so that's what I went with.
Patch 1 re-orders the assig
flight 60775 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat
fail REGR. vs. 60683
Aravind and Andrew pointed me to this series.
The first patch is low risk, the second patch has been reviewed by two
experts in that area.
Provided Jan is happy with Aravind's answer:
Release-acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@li
flight 60773 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 14 guest-saverestore fail REGR. vs. 59254
test-amd64-i386-xl
On 08/18/2015 05:55 PM, Dario Faggioli wrote:
Hey everyone,
So, as a followup of what we were discussing in this thread:
[Xen-devel] PV-vNUMA issue: topology is misinterpreted by the guest
http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03241.html
I started looking in more d
On 18/08/15 07:29, Julien Grall wrote:
> 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 no need
> to complain about the coding style.
>
> The qdisk backend in QEMU is not supporting indirect grant, this is
> means
On Thu, 20 Aug 2015, David Vrabel wrote:
> On 20/08/15 09:31, Roger Pau Monné wrote:
> > El 20/08/15 a les 1.44, Stefano Stabellini ha escrit:
> >> 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 w
On 20/08/2015 02:43, David Vrabel wrote:
On 20/08/15 09:31, Roger Pau Monné wrote:
El 20/08/15 a les 1.44, Stefano Stabellini ha escrit:
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 pa
>>> On 20.07.15 at 16:29, wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -665,6 +665,58 @@ static EFI_GRAPHICS_OUTPUT_PROTOCOL __init
> *efi_get_gop(void)
> return gop;
> }
>
> +static UINTN __init efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> +
>>> On 20.07.15 at 16:29, wrote:
> Build xen.gz with EFI code. We need this to support multiboot2
> protocol on EFI platforms.
>
> If we wish to load not ELF file using multiboot (v1) or multiboot2 then
DYM "a non-ELF file"?
> it must contain "linear" (or "flat") representation of code and data
>>> On 20.07.15 at 16:29, wrote:
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -4,9 +4,14 @@
> #include
> #include
>
> -#ifndef efi_enabled
> -const bool_t efi_enabled = 0;
> -#endif
> +struct efi __read_mostly efi = {
> + .flags = 0, /* Initialized later. */
> +
On 20/08/15 16:03, Julien Grall wrote:
>
>
> On 20/08/2015 03:11, David Vrabel wrote:
>> On 20/08/15 01:40, Julien Grall wrote:
>>> 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 t
On 20/08/2015 03:11, David Vrabel wrote:
On 20/08/15 01:40, Julien Grall wrote:
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 X
On 10/08/15 11:14, Andrew Cooper wrote:
On 10/08/15 10:49, Tim Deegan wrote:
Hi,
At 17:45 +0100 on 06 Aug (1438883118), Ben Catterall wrote:
The process to switch into and out of deprivileged mode can be likened to
setjmp/longjmp.
To enter deprivileged mode, we take a copy of the stack from
On 20/08/15 10:34, Tim Deegan wrote:
At 17:36 +0100 on 19 Aug (1440005801), Ben Catterall wrote:
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. Hopefull
flight 60768 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60768/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 30511
Tests which are failing
>>> On 20.08.15 at 15:46, wrote:
> El 20/08/15 a les 14.29, Shannon Zhao ha escrit:
>>
>>
>> On 2015/8/20 19:28, Roger Pau Monné wrote:
>>> El 20/08/15 a les 13.22, Shannon Zhao ha escrit:
Hi Roger,
On 2015/8/20 16:20, Roger Pau Monné wrote:
> El 20/08/15 a les 5.07, Shannon Z
>>> On 20.08.15 at 14:56, wrote:
>
> On 2015/8/20 17:30, Jan Beulich wrote:
> On 20.08.15 at 05:41, wrote:
>>> 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
> -
El 20/08/15 a les 14.29, Shannon Zhao ha escrit:
>
>
> On 2015/8/20 19:28, Roger Pau Monné wrote:
>> El 20/08/15 a les 13.22, Shannon Zhao ha escrit:
>>> Hi Roger,
>>>
>>> On 2015/8/20 16:20, Roger Pau Monné wrote:
El 20/08/15 a les 5.07, Shannon Zhao ha escrit:
> On 2015/8/19 23:02, Rog
On 2015/8/20 17:30, Jan Beulich wrote:
On 20.08.15 at 05:41, wrote:
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
On 2015/8/20 19:28, Roger Pau Monné wrote:
El 20/08/15 a les 13.22, Shannon Zhao ha escrit:
Hi Roger,
On 2015/8/20 16:20, Roger Pau Monné wrote:
El 20/08/15 a les 5.07, Shannon Zhao ha escrit:
On 2015/8/19 23:02, Roger Pau Monné wrote:
El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
XENM
>>> On 20.08.15 at 13:28, wrote:
> If you want you can check in the hypercall handler that idxs[i] ==
> gpfns[i], and return -EOPNOTSUPP if they don't match, but I still don't
> see why this should be restricted to 1:1 mappings.
+1
Jan
___
Xen-devel
While commit 4cca6ea04d31c claims to not have any functional effect on
Xen, this isn't the case: Before that change, kernels built without
CONFIG_XEN_PVHVM (a dependency which meanwhile became just CONFIG_XEN)
were able to run in x2APIC mode just fine. Restore that behavior.
This, however, still d
El 20/08/15 a les 13.22, Shannon Zhao ha escrit:
> Hi Roger,
>
> On 2015/8/20 16:20, Roger Pau Monné wrote:
>> El 20/08/15 a les 5.07, Shannon Zhao ha escrit:
>>> On 2015/8/19 23:02, Roger Pau Monné wrote:
El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
> XENMAPSPACE "XENMAPSPACE_dev_mmi
On 19/08/15 14: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:
>
> d
Hi Roger,
On 2015/8/20 16:20, Roger Pau Monné wrote:
El 20/08/15 a les 5.07, Shannon Zhao ha escrit:
On 2015/8/19 23:02, Roger Pau Monné wrote:
El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
XENMAPSPACE "XENMAPSPACE_dev_mmio". The usage of this hypercall
parameters:
- domid: DOMID_SELF.
- s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.2-rc7-tag
xen: build fix for 4.2-rc7
- - Fix i386 build with an (uncommon) configuration
Thanks.
David
arch/x86/xen/Kconfig | 4 ++-
On 20/08/15 10:34, Tim Deegan wrote:
At 17:36 +0100 on 19 Aug (1440005801), Ben Catterall wrote:
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. Hope
On 18/08/15 17:55, 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
Thanks for the report. The below patch fixes this.
8<--
x86/xen: mak
On 20/08/15 01:40, Julien Grall wrote:
> 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 min
On 07/08/15 17:46, Julien Grall wrote:
> The hypercall interface (as well as the toolstack) is always using 4KB
> page granularity. When the toolstack is asking for mapping a series of
> guest PFN in a batch, it expects to have the page map contiguously in
> its virtual memory.
>
> When Linux is u
On 07/08/15 17:46, Julien Grall wrote:
> The PV network protocol is using 4KB page granularity. The goal of this
> patch is to allow a Linux using 64KB page granularity using network
> device on a non-modified Xen.
>
> It's only necessary to adapt the ring size and break skb data in small
> chunk
On 07/08/15 17:46, Julien Grall wrote:
> For ARM64 guests, Linux is able to support either 64K or 4K page
> granularity. Although, the hypercall interface is always based on 4K
> page granularity.
>
> With 64K page granularity, a single page will be spread over multiple
> Xen frame.
>
> To avoid
On 07/08/15 17:46, Julien Grall wrote:
> The console ring is always based on the page granularity of Xen.
[...]
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
> if (r < 0 || v == 0)
> goto err;
>
On 07/08/15 17:46, Julien Grall wrote:
> Currently, a grant is always based on the Xen page granularity (i.e
> 4KB). When Linux is using a different page granularity, a single page
> will be split between multiple grants.
>
> The new helpers will be in charge to split the Linux page into grants an
On 07/08/15 17:46, Julien Grall wrote:
> The Xen hypercall interface is always using 4K page granularity on ARM
> and x86 architecture.
>
> With the incoming support of 64K page granularity for ARM64 guest, it
> won't be possible to re-use the Linux page definition in Xen drivers.
>
> Introduce X
On Mon, 2015-08-17 at 19:57 +0100, Wei Liu wrote:
> ... but allow user to override that check by specifying maxvcpus= in
> xl
> configuration file.
>
> Note that the code is constructed such that the fallout is dealt with
> after parsing. We can live with that because though it wastes a bit
> of
On Mon, 2015-08-17 at 19:57 +0100, Wei Liu wrote:
> Only 4KB allocation was using new_memflags. We should use
> new_memflags
> in for 2MB and 1GB allocation as well because that variable contains
> node information.
>
> Without this patch, when creating a HVM guest with vNUMA, because the
> node
On 20/08/15 09:31, Roger Pau Monné wrote:
> El 20/08/15 a les 1.44, Stefano Stabellini ha escrit:
>> 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
>>>
>>> On 20.08.15 at 01:44, wrote:
> 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 muc
At 17:36 +0100 on 19 Aug (1440005801), Ben Catterall wrote:
>
>
> 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
>>> On 20.08.15 at 05:41, wrote:
> 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 g
>>> On 19.08.15 at 20:37, wrote:
> 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
flight 37839 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37839/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 9 debian-di-install fail never
pass
baseline version:
fli
On Mon, 2015-08-17 at 19:56 +0100, Wei Liu wrote:
> We should parse the output from splitting function, not the original
> string, otherwise the parsed result is wrong.
>
> For example:
>
> vnuma = [ [...,"vdistance=10,20",...],
> [...,"vdistance=20,10",...] ]
>
> Before this change, v
El 20/08/15 a les 1.44, Stefano Stabellini ha escrit:
> 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 com
El 20/08/15 a les 5.07, Shannon Zhao ha escrit:
> On 2015/8/19 23:02, Roger Pau Monné wrote:
>> El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
>>> XENMAPSPACE "XENMAPSPACE_dev_mmio". The usage of this hypercall
>>> parameters:
>>> - domid: DOMID_SELF.
>>> - space: XENMAPSPACE_dev_mmio.
>>> - gpfn
El 20/08/15 a les 2.40, Julien Grall ha escrit:
> Hi,
>
> Ping? I'm missing some reviews on block and netfront code.
Sorry, I didn't realize some of the patches were changed and the Ack
dropped. I think I've reviewed everything related to block.
Roger.
_
El 07/08/15 a les 18.46, Julien Grall ha escrit:
> The PV block protocol is using 4KB page granularity. The goal of this
> patch is to allow a Linux using 64KB page granularity behaving as a
> block backend on a non-modified Xen.
>
> It's only necessary to adapt the ring size and the number of req
Hello,
I have some comments regarding the commit message, IMHO it would be good
that a native English speaker reviews it too.
El 07/08/15 a les 18.46, Julien Grall ha escrit:
> The PV block protocol is using 4KB page granularity. The goal of this
> patch is to allow a Linux using 64KB page granul
El 07/08/15 a les 18.46, Julien Grall ha escrit:
> Prepare the code to support 64KB page granularity. The first
> implementation will use a full Linux page per indirect and persistent
> grant. When non-persistent grant is used, each page of a bio request
> may be split in multiple grant.
>
> Furth
64 matches
Mail list logo
