On Mon, 2017-09-11 at 12:37 +0800, Haozhong Zhang wrote:
> ... to avoid the inference with the PMEM driver and management
> utilities in Dom0.
>
> Signed-off-by: Haozhong Zhang
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Gang Wei
> Cc: Shane Wang
> ---
> xen/arch/x86/acpi/power.c | 7
On 11/03/17 13:58 +0800, Chao Peng wrote:
>
> > +#ifdef CONFIG_NVDIMM_PMEM
> > +static void __init init_frametable_pmem_chunk(unsigned long s,
> > unsigned long e)
> > +{
> > +static unsigned long pmem_init_frametable_mfn;
> > +
> > +ASSERT(!((s | e) & (PAGE_SIZE - 1)));
> > +
> > +if
> +
> +/**
> + * Add a PMEM region to a list. All PMEM regions in the list are
> + * sorted in the ascending order of the start address. A PMEM region,
> + * whose range is overlapped with anyone in the list, cannot be added
> + * to the list.
> + *
> + * Parameters:
> + * list: the list to
> +static void __init acpi_nfit_register_pmem(struct acpi_nfit_desc
> *desc)
> +{
> +struct nfit_spa_desc *spa_desc;
> +struct nfit_memdev_desc *memdev_desc;
> +struct acpi_nfit_system_address *spa;
> +unsigned long smfn, emfn;
> +
> +list_for_each_entry(memdev_desc, &desc->mem
> +#ifdef CONFIG_NVDIMM_PMEM
> +static void __init init_frametable_pmem_chunk(unsigned long s,
> unsigned long e)
> +{
> +static unsigned long pmem_init_frametable_mfn;
> +
> +ASSERT(!((s | e) & (PAGE_SIZE - 1)));
> +
> +if ( !pmem_init_frametable_mfn )
> +{
> +pmem_init_fr
flight 115505 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 115490
test-amd64-a
flight 115487 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115487/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 15 guest-saverestore.2 fail REGR.
vs. 114682
test-am
flight 115489 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115489/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
114539
Tests which did
flight 115502 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 115490
test-amd64-a
flight 115483 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115483/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114814
Regressions which are
This patch doesn't work here, my test environment actually broke, I am
so sorry for the mess!
Please just ignore it.
On 11/2/17 1:40 PM, Daniel P. Berrange wrote:
> On Thu, Nov 02, 2017 at 05:26:50PM +, Peter Maydell wrote:
>> On 2 November 2017 at 17:18, Liang Yan wrote:
>>> New tigervnc cha
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@linaro.org]
> Sent: Thursday, November 2, 2017 9:50 PM
> To: Stefano Stabellini
> Cc: Hao, Xudong ; Jan Beulich ;
> Quan Xu ; Lars Kurth ; Wei Liu
> ; Zhang, PengtaoX ; Kang,
> Luwei ; Julien Grall ; Anthony
> PERARD ; Xen-dev
flight 115500 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115500/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 115490
test-amd64-a
Hi Boris,
On 11/03/2017 04:28 AM, Boris Ostrovsky wrote:
> On 11/01/2017 09:19 PM, Dongli Zhang wrote:
>> Hi Boris,
>>
>> I have received from l...@intel.com that the prior version of patch hit issue
>> during compilation with aarch64-linux-gnu-gcc. I think this patch reviewed by
>> you would hit
For any other error sync_cmos_clock() will reschedule itself
every second or so, for no good reason.
Suggested-by: Paolo Bonzini
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
i
This run is configured for baseline tests only.
flight 72405 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72405/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow219 guest-start/deb
flight 115497 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115497/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 115490
test-amd64-a
On 11/02/2017 05:30 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>> Sent: 01 November 2017 18:19
>> To: Juergen Gross ; Paul Durrant
>> ; x...@kernel.org; xen-
>> de...@lists.xenproject.org; linux-ker...@vger.kernel.org
>> Cc: Th
On 11/02/2017 01:34 PM, George Dunlap wrote:
> On 10/27/2017 04:09 PM, NathanStuder wrote:
>>
>>
>> On 10/09/2017 10:14 AM, Lars Kurth wrote:
>>>
On 27 Sep 2017, at 13:57, Robert VanVossen
wrote:
On 9/26/2017 3:12 AM, Dario Faggioli wrote:
> [Cc-list modified b
On 11/01/2017 09:19 PM, Dongli Zhang wrote:
> Hi Boris,
>
> I have received from l...@intel.com that the prior version of patch hit issue
> during compilation with aarch64-linux-gnu-gcc. I think this patch reviewed by
> you would hit the same compiling issue on arm64 (there is no issue with
> x86_
On Thu, Nov 02, 2017 at 05:49:12PM +, Julien Grall wrote:
Hi Julien,
> On 02/11/17 16:53, Volodymyr Babchuk wrote:
> >On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote:
> >>On 24/10/17 20:02, Volodymyr Babchuk wrote:
> If it is not safe, this means you have a whitelist solu
On 27/10/17 18:42, Igor Druzhinin wrote:
> On 16/02/17 11:15, Jan Beulich wrote:
>> When __context_switch() is being bypassed during original context
>> switch handling, the vCPU "owning" the VMCS partially loses control of
>> it: It will appear non-running to remote CPUs, and hence their attempt
>
flight 115484 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 114507
build-amd64-xsm
flight 115478 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115478/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-armhf-pvops 4 host-inst
flight 115490 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115490/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 115479 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115479/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 17 guest-localmigrate/x10 fail REGR. vs. 115289
test-armhf-armhf-xl-
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Notice that in this particular case I placed the "fall through" comment
on its own line, which is what GCC is expecting to find.
Signed-off-by: Gustavo A. R. Silva
---
drivers/xen/pvcall
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 146562
Addresses-Coverity-ID: 146563
Signed-off-by: Gustavo A. R. Silva
---
drivers/xen/xenbus/xenbus_probe_frontend.c | 2 ++
1 file changed, 2 insertions(+)
diff
On 02/11/17 07:23, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Friday, October 27, 2017 1:59 AM
>>
>> On 26/10/17 18:03, Euan Harris wrote:
>>> decode_vmx_inst() does not read instruction operands correctly on VM
>> exit:
>>> * It incorrectly uses vmx_inst
Hi all,
Xen 4.10 RC3 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.10.0-rc3
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.10.0-rc3/xen-4.10.0-rc3.tar.gz
And the signature is at:
https://downloads.xenproject.or
On 11/2/17 1:40 PM, Daniel P. Berrange wrote:
> On Thu, Nov 02, 2017 at 05:26:50PM +, Peter Maydell wrote:
>> On 2 November 2017 at 17:18, Liang Yan wrote:
>>> New tigervnc changes the way to send long pressed key,
>>> from "down up down up ..." to "down down ... up", it only
>>> affects xen
Toolstack may write values to the "require" subdirectory in the backend
main xenstore directory (e.g. backend/vif/X/Y/). Read these values and
use them when announcing those to the frontend. When backend scans
frontend features the values set in the require directory take
precedence, hence making n
Toolstack may write values to the "require" subdirectory in the
backend main directory (e.g. backend/vbd/X/Y/). Read these values
and use them when announcing those to the frontend. When backend
scans frontend features the values set in the require directory
take precedence, hence making no signifi
Hey folks,
Presented herewith is an attempt to implement PV backends feature control
as discussed in the list
(https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.html)
Given that this a simple proposal hence I thought to include all changes
involved in the same patchset such that eve
Any option name preceded by "require-" means a backend feature
to be set. This is stored in key value structure which libxl will parse
and tell blkback to override the specified features.
An example would be a config containing:
...
vcpus = 8
disk = [ "phy:/path/to/disk,hda,w,require-multi-queue-
Any option name preceded by "require-" means a backend feature to be {un,}set.
This is stored in key value structure which libxl will parse and inform netback
to override the specified features.
An example would be a config containing:
...
vcpus = 8
vif = ["bridge=br0,require-multi-queue-max-queu
The function libxl__device_generic_add will have an additional
argument whereby it adds a second set of entries visible to the
backend only. These entries will then be used for devices
thus overriding backend maximum feature set with this user-defined ones.
libxl_device_disk.backend_features are a
The proposed directory provides a mechanism for tools to control the
maximum feature set of the device being provisioned by backend.
The parameters/features include offloading features, number of
queues etc.
Signed-off-by: Joao Martins
---
xen/include/public/io/netif.h | 16
1 f
Adds "backend_features" to the libxl_device_nic structure to
represent a set of features to be set on the device by the admin.
These backend_features is a key value store representing
an array of = , which would then be
translated into (backend-only permissions) xenstore entries in
the form of:
/
The proposed directory provides a mechanism for tools to control the
maximum feature set of the device being provisioned by backends.
Examples include max ring page order, persistent grants, number of
queues etc.
Signed-off-by: Joao Martins
---
xen/include/public/io/blkif.h | 14 ++
On Thu, 2 Nov 2017, Andre Przywara wrote:
> (CC:ing some KVM/ARM folks involved in the VGIC)
>
> starting with the addition of the ITS support we were seeing more and
> more issues with the current implementation of our ARM Generic Interrupt
> Controller (GIC) emulation, th
Thanks for the reply.
On 11/2/17 1:26 PM, Peter Maydell wrote:
> On 2 November 2017 at 17:18, Liang Yan wrote:
>> New tigervnc changes the way to send long pressed key,
>> from "down up down up ..." to "down down ... up", it only
>> affects xen pv console mode. I send a patch to latest
>> kernel
Hi Volodymyr,
On 02/11/17 16:53, Volodymyr Babchuk wrote:
On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote:
On 24/10/17 20:02, Volodymyr Babchuk wrote:
If it is not safe, this means you have a whitelist solution and therefore
tie Xen to a specific OP-TEE version. So if you need to
On Thu, Nov 02, 2017 at 05:26:50PM +, Peter Maydell wrote:
> On 2 November 2017 at 17:18, Liang Yan wrote:
> > New tigervnc changes the way to send long pressed key,
> > from "down up down up ..." to "down down ... up", it only
> > affects xen pv console mode. I send a patch to latest
> > kern
On 10/27/2017 04:09 PM, NathanStuder wrote:
>
>
> On 10/09/2017 10:14 AM, Lars Kurth wrote:
>>
>>> On 27 Sep 2017, at 13:57, Robert VanVossen
>>> wrote:
>>>
>>>
>>>
>>> On 9/26/2017 3:12 AM, Dario Faggioli wrote:
[Cc-list modified by removing someone and adding someone else]
On M
On 2 November 2017 at 17:18, Liang Yan wrote:
> New tigervnc changes the way to send long pressed key,
> from "down up down up ..." to "down down ... up", it only
> affects xen pv console mode. I send a patch to latest
> kernel side, but it may have a fix in qemu backend for
> back compatible beca
On Thu, Nov 02, 2017 at 08:59:20AM +0800, Zhong Yang wrote:
> On Wed, Nov 01, 2017 at 03:29:16PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 27, 2017 at 10:18:04PM +0800, Yang Zhong wrote:
> > > Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
> > > VAES/AVX512VNNI/AVX512BITA
On 02/11/17 04:35, Tian, Kevin wrote:
>> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
>> Sent: Monday, October 23, 2017 5:33 PM
>>
>> Running "./xtf_runner vvmx" in L1 Xen under L0 Xen produces the
>> following result on H/W with VMCS shadowing:
>>
>> Test: vmxon
>> Failure in test
New tigervnc changes the way to send long pressed key,
from "down up down up ..." to "down down ... up", it only
affects xen pv console mode. I send a patch to latest
kernel side, but it may have a fix in qemu backend for
back compatible becase guest VMs may use very old kernel.
This patch inserts
On Thu, Nov 02, 2017 at 05:11:17PM +, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 07:02:49PM +0200, Pasi Kärkkäinen wrote:
> > On Thu, Aug 24, 2017 at 09:23:16AM +0100, Roger Pau Monné wrote:
> > > On Wed, Aug 23, 2017 at 07:13:00PM +0200, Andreas Kinzler wrote:
> > > > > > > From a brief
On Thu, Nov 02, 2017 at 07:02:49PM +0200, Pasi Kärkkäinen wrote:
> On Thu, Aug 24, 2017 at 09:23:16AM +0100, Roger Pau Monné wrote:
> > On Wed, Aug 23, 2017 at 07:13:00PM +0200, Andreas Kinzler wrote:
> > > > > > From a brief look it looks like this would be doable, but the way
> > > > > these flag
On Thu, Aug 24, 2017 at 09:23:16AM +0100, Roger Pau Monné wrote:
> On Wed, Aug 23, 2017 at 07:13:00PM +0200, Andreas Kinzler wrote:
> > > > > From a brief look it looks like this would be doable, but the way
> > > > these flags are being communicated is rather ugly (the values used
> > > > here
> >
Hi,
On Fri, Sep 22, 2017 at 03:25:00PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 22, 2017 at 09:35:40AM +0200, Sander Eikelenboom wrote:
> > On 22/09/17 04:09, Christopher Clark wrote:
> > > On Thu, Sep 21, 2017 at 1:27 PM, Sander Eikelenboom
> > > wrote:
> > >>
> > >> On Thu, September 2
On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote:
Hi Julien,
> On 24/10/17 20:02, Volodymyr Babchuk wrote:
> >>If it is not safe, this means you have a whitelist solution and
> >>therefore
> >>tie Xen to a specific OP-TEE version. So if you need to use a new
> >>func
On Thu, Oct 12, 2017 at 08:19:07PM +0100, Andrew Cooper wrote:
> The sole use of xc_dom_translated() and xc_dom_p2m() outside of the domain
> builder is for libxl_dom() to translate the console and xenstore pfns back
> into useful values. PV guest pfns are only interesting to the domain builder,
>
Hi,
On 01/11/17 21:54, Stefano Stabellini wrote:
> On Wed, 1 Nov 2017, Andre Przywara wrote:
>> Hi Stefano,
>>
>>
>> On 01/11/17 01:58, Stefano Stabellini wrote:
>>> On Wed, 11 Oct 2017, Andre Przywara wrote:
>>
>> many thanks for going through all of this!
>
> No problems, and thanks for your wo
On Thu, Nov 02, 2017 at 10:46:20AM +, George Dunlap wrote:
> On 11/01/2017 05:10 PM, Konrad Rzeszutek Wilk wrote:
> > On Tue, Oct 24, 2017 at 04:22:38PM +0100, George Dunlap wrote:
> >> On Fri, Sep 15, 2017 at 3:51 PM, Konrad Rzeszutek Wilk
> >> wrote:
> +### Soft-reset for PV guests
> >>
Hi Konrad,
On 01/11/17 18:54, Konrad Rzeszutek Wilk wrote:
On Wed, Nov 01, 2017 at 02:03:15PM +, Julien Grall wrote:
The file common/tmem_xen.c is now converted to use typesafe. This is
requiring to override the macro page_to_mfn to make it work with mfn_t.
Note that all variables converte
Hi Wei,
On 01/11/17 10:20, Wei Liu wrote:
Cc Julien and change tag. I think this is safe to be applied to 4.10.
I agree.
Release-acked-by: Julien Grall
Cheers,
On Tue, Oct 31, 2017 at 01:58:07PM -0700, Elena Ufimtseva wrote:
On Tue, Oct 31, 2017 at 03:25:39PM +, Wei Liu wrote:
On T
flight 115475 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115475/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair18 guests-nbd-mirror/debian fail REGR. vs. 114682
test-amd64-amd64-xl
On 02/11/17 08:37, Rakesh Awanti wrote:
>>> Hello,
>>>
>>> I'm trying USB passthrough on x86 and ARM platforms. I've taken the USB
>>> frontend and backend code from
>
>>So from where?
>
>
> https://lists.xen.org/archives/html/xen-devel/2015-02/msg03245.html
The backend driver was discarded a
Hi Andrew,
On 31/10/17 17:18, Andrew Cooper wrote:
While investigating an issue (in a new codepath I'd introduced, as it turns
out), leaving interrupts disabled manifested as a subsequent op in the
multicall failing a check_lock() test.
The codepath would have hit the ASSERT_NOT_IN_ATOMIC on th
Hi,
On 30/10/17 02:21, Hao, Xudong wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, October 27, 2017 5:19 PM
To: Hao, Xudong
Cc: Julien Grall ; Lars Kurth ;
xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.10.0 RC1 test result
On 27.10.17 at
Hi Andrew,
On 31/10/17 10:49, Andrew Cooper wrote:
If check_lock() triggers, a crash will occur. Instead of simply identifying
"the irq context was different", indicate the expected and current irq
context.
Signed-off-by: Andrew Cooper
Release-acked-by: Julien Grall
Cheers,
---
CC: Geor
On 30/10/17 14:39, Ian Jackson wrote:
Wei Liu writes ("Re: [PATCH] tools/hotplug: create XEN_LOG_DIR at runtime"):
On Fri, Oct 27, 2017 at 07:52:37PM +0300, Andrii Anisov wrote:
From: Andrii Anisov
/var/log could be a tmpfs mount point, so create xen subfolder at runtime.
Signed-off-by: An
Hi George,
On Wed, Oct 25, 2017 at 10:31 AM, Wei Liu wrote:
>
> On Mon, Oct 23, 2017 at 02:50:31PM -0400, Meng Xu wrote:
> > On Tue, Oct 17, 2017 at 4:10 AM, Dario Faggioli wrote:
> > > On Wed, 2017-10-11 at 14:02 -0400, Meng Xu wrote:
> > >> Change repl_budget event output for xentrace formats
Hi,
On 27/10/17 21:16, Stefano Stabellini wrote:
On Fri, 27 Oct 2017, Julien Grall wrote:
On 27/10/17 08:27, Hao, Xudong wrote:
This bug exist much long time, there are many discussion last year but not a
solution then. I call out it now because there is a fix in qemu upstream:
commit a8036336
Actually CC them...
On 02/11/17 13:44, Julien Grall wrote:
Hi,
I noticed I forgot to CC Wei and Ian for committing this patch series.
On 27/10/17 14:31, Julien Grall wrote:
Hi Juergen,
On 25/10/17 08:08, Juergen Gross wrote:
On 24/10/17 18:06, Julien Grall wrote:
Hi,
I think this is 4.10
Hi,
I noticed I forgot to CC Wei and Ian for committing this patch series.
On 27/10/17 14:31, Julien Grall wrote:
Hi Juergen,
On 25/10/17 08:08, Juergen Gross wrote:
On 24/10/17 18:06, Julien Grall wrote:
Hi,
I think this is 4.10 material (particularly patch #5). Juergen, would it
be possib
Hi,
On 23/10/17 22:33, Stefano Stabellini wrote:
On Fri, 20 Oct 2017, Julien Grall wrote:
Julien, do you think we need to keep a special linux tree around for Xen
on ARM testing in OSSTest or we can start using vanilla kernel releases?
I would love to get rid of it, if you
Hi Ian,
On 02/11/17 13:27, Ian Jackson wrote:
Julien Grall writes ("Re: Commit moratorium to staging"):
Thank you for the explanation. I agree with the force push to unblock
master (and other tree I mentioned).
I will force push all the affected trees, but in a reactive way
because I base eac
On 02/11/17 14:25, Waiman Long wrote:
> On 11/01/2017 06:01 PM, Boris Ostrovsky wrote:
>> On 11/01/2017 04:58 PM, Waiman Long wrote:
>>> +/* TODO: To be removed in a future kernel version */
>>> static __init int xen_parse_nopvspin(char *arg)
>>> {
>>> - xen_pvspin = false;
>>> + pr_warn("xen
Julien Grall writes ("Re: Commit moratorium to staging"):
> Thank you for the explanation. I agree with the force push to unblock
> master (and other tree I mentioned).
I will force push all the affected trees, but in a reactive way
because I base each force push on a test report - so it won't be
On 11/01/2017 06:01 PM, Boris Ostrovsky wrote:
> On 11/01/2017 04:58 PM, Waiman Long wrote:
>> +/* TODO: To be removed in a future kernel version */
>> static __init int xen_parse_nopvspin(char *arg)
>> {
>> -xen_pvspin = false;
>> +pr_warn("xen_nopvspin is deprecated, replace it with
>>
Hi Volodymyr,
On 24/10/17 20:02, Volodymyr Babchuk wrote:
If it is not safe, this means you have a whitelist solution and therefore
tie Xen to a specific OP-TEE version. So if you need to use a new function
you would need to upgrade Xen making the code of using new version
potentially high.
Yes
Hi, all!
Foreword
This RFC is aimed to introduce support of para-virtualized sound frontend
driver for Xen [1] and gather opinions from the relevant communities
(ALSA, Xen). It implements the protocol from [2] with the
following limitations:
- mute/unmute is not supported
- get/set
flight 115480 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 114507
build-amd64-xsm
flight 115473 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115473/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114814
Tests which did not s
Hi Bhupinder,
On 02/11/17 10:13, Bhupinder Thakur wrote:
The console was not working on HP Moonshot (HPE Proliant Aarch64) because
the UART registers were accessed as 8-bit aligned addresses. However,
registers are 32-bit aligned for HP Moonshot.
Since ACPI/SPCR table does n
Hi Bhupinder,
Please write a cover letter even if it is small when your send a series
with multiple patches.
On 02/11/17 10:13, Bhupinder Thakur wrote:
Currently, Xen supports only DT based initialization of 16550 UART.
This patch adds support for initializing 16550 UART using ACPI SPCR table
Roger Pau Monné writes ("Re: [Xen-devel] Commit moratorium to staging"):
> Is there anyway to get that from windows in an automatic way? If not I
> could test that with a Debian guest. In fact it might even be a good
> thing for Linux based guest to be added to the regular migration tests
> in orde
On 11/01/2017 02:07 PM, Ian Jackson wrote:
> So, investigations (mostly by Roger, and also a bit of archaeology in
> the osstest db by me) have determined:
>
> * This bug is 100% reproducible on affected hosts. The repro is
> to boot the Windows guest, save/restore it, then migrate it,
> then
On 11/01/2017 05:10 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 24, 2017 at 04:22:38PM +0100, George Dunlap wrote:
>> On Fri, Sep 15, 2017 at 3:51 PM, Konrad Rzeszutek Wilk
>> wrote:
+### Soft-reset for PV guests
>>>
>>> s/PV/HVM/
>>
>> Is it? I thought this was for RHEL 5 PV guests to be
flight 115476 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115476/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 115415
test-armhf-armhf-libvirt 14 saveresto
The console was not working on HP Moonshot (HPE Proliant Aarch64) because
the UART registers were accessed as 8-bit aligned addresses. However,
registers are 32-bit aligned for HP Moonshot.
Since ACPI/SPCR table does not specify the register shift to be applied to
the
register
Currently, Xen supports only DT based initialization of 16550 UART.
This patch adds support for initializing 16550 UART using ACPI SPCR table.
Signed-off-by: Bhupinder Thakur
---
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabell
> -Original Message-
> From: Roger Pau Monne
> Sent: 02 November 2017 09:42
> To: Paul Durrant
> Cc: Ian Jackson ; Lars Kurth
> ; Wei Liu ; Julien Grall
> ; committ...@xenproject.org; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] Commit moratorium to staging
>
> On Thu
On 11/02/2017 11:44 AM, Takashi Sakamoto wrote:
On Oct 30 2017 15:33, Oleksandr Andrushchenko wrote:
This is an attempt to summarize previous discussions on Xen para-virtual
sound driver.
A first attempt has been made to upstream the driver [1] which
brought number
of fundamental questions, o
do I have to run addr2line on my vmlinux image?
2017-11-02 10:31 GMT+01:00 Juergen Gross :
> On 02/11/17 08:56, Francesco De Francesco wrote:
> > Hi everyone,
> >
> > I need to address an issue that prevents me from running Xen on new
> > hardware. It's an HPE DL360 Gen10 with double Xeon Silver
On Oct 30 2017 15:33, Oleksandr Andrushchenko wrote:
This is an attempt to summarize previous discussions on Xen para-virtual
sound driver.
A first attempt has been made to upstream the driver [1] which brought
number
of fundamental questions, one of the biggest ones was that the frontend
driv
On Thu, Nov 02, 2017 at 09:20:10AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 02 November 2017 09:15
> > To: Roger Pau Monne
> > Cc: Ian Jackson ; Lars Kurth
> > ; Wei Liu ; Julien Grall
> > ; Paul Durrant ;
> > committ...@xenproject.org; xen-deve
On 02/11/17 08:56, Francesco De Francesco wrote:
> Hi everyone,
>
> I need to address an issue that prevents me from running Xen on new
> hardware. It's an HPE DL360 Gen10 with double Xeon Silver 4108 CPU and
> 256GB ECC DDR4 RDIMM. It happens with both CentOS6 and CentOS7.
>
> When I try to boot
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 01 November 2017 18:19
> To: Juergen Gross ; Paul Durrant
> ; x...@kernel.org; xen-
> de...@lists.xenproject.org; linux-ker...@vger.kernel.org
> Cc: Thomas Gleixner ; Ingo Molnar
> ; H. Peter Anvin
> S
> -Original Message-
> From: Roger Pau Monne
> Sent: 02 November 2017 09:15
> To: Roger Pau Monne
> Cc: Ian Jackson ; Lars Kurth
> ; Wei Liu ; Julien Grall
> ; Paul Durrant ;
> committ...@xenproject.org; xen-devel
> Subject: Re: [Xen-devel] Commit moratorium to staging
>
> On Wed, Nov 01
Update arch/x86/include/asm/xen/cpuid.h from the Xen tree to get newest
definitions.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/xen/cpuid.h | 42 ++--
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/xen/cpuid.h b
As there is currently no user for sub-page grants or transient grants
remove that functionality. This at once makes it possible to switch
from grant v2 to grant v1 without restrictions, as there is no loss of
functionality other than the limited frame number width related to
the switch.
Signed-off
Grant v2 will be needed in cases where a frame number in the grant
table can exceed 32 bits. For PV guests this is a host feature, while
for HVM guests this is a guest feature.
So select grant v2 in case frame numbers can be larger than 32 bits
and grant v1 else.
For testing purposes add a way to
In order to support Linux to run as a pv guest on machines with huge
memory (>16TB) or as a hvm guest with more than 16TB of memory the
kernel has to support grant table interface v2, as v1 is limited to
32 bit frame numbers.
This series re-adds that support (it has been removed in 2015) and
restr
The grant v2 support was removed from the kernel with
commit 438b33c7145ca8a5131a30c36d8f59bce119a19a ("xen/grant-table:
remove support for V2 tables") as the higher memory footprint of v2
grants resulted in less grants being possible for a kernel compared
to the v1 grant interface.
As machines wi
Instead of having multiple variables with constants like
grant_table_version or grefs_per_grant_frame add those to struct
gnttab_ops and access them just via the gnttab_interface pointer.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
---
drivers/xen/grant-table.c | 73 ++
1 - 100 of 113 matches
Mail list logo
