On Wed, Mar 28, 2018 at 01:29:46PM +0300, Oleksandr Andrushchenko wrote:
> Hi, Daniel!
>
> I just noticed I have missed one change in the patch:
> the below must be static.
>
> On 03/28/2018 10:42 AM, Daniel Vetter wrote:
> > +enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
> > +
flight 121322 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121322/
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 10 debian-hvm-install
fail REGR. vs. 121272
:
https://github.com/0day-ci/linux/commits/Oleksandr-Andrushchenko/drm-xen-front-Add-support-for-Xen-PV-display-frontend/20180329-090744
base: git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF
Fixes: d7f404c8b4b6 ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Fengguang Wu
---
xen_drm_front_kms.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 54504
On 03/29/2018 10:17 AM, Daniel Vetter wrote:
On Wed, Mar 28, 2018 at 01:29:46PM +0300, Oleksandr Andrushchenko wrote:
Hi, Daniel!
I just noticed I have missed one change in the patch:
the below must be static.
On 03/28/2018 10:42 AM, Daniel Vetter wrote:
+enum drm_mode_status display_mode_val
We don't break up port requests in case they cross emulation entity
boundaries, and a write to an I/O port is necessarily the last
operation of an instruction instance, so there's no need to re-invoke
the full emulation path upon receiving the result from an external
emulator.
In case we want to p
>>> On 27.03.18 at 11:26, wrote:
> @@ -2149,8 +2154,26 @@ void tsc_set_info(struct domain *d,
> * When a guest is created, gtsc_khz is passed in as zero, making
> * d->arch.tsc_khz == cpu_khz. Thus no need to check incarnation.
> */
> +disable_vtsc = d->arch.t
On Wed, Mar 28, 2018 at 05:09:39PM +0100, Wei Liu wrote:
> On Wed, Mar 28, 2018 at 05:07:33PM +0100, Wei Liu wrote:
> > On Wed, Mar 28, 2018 at 08:34:14AM +0100, Roger Pau Monne wrote:
> > > Allow the path to be set from a configure command line option.
> > >
> > > Signed-off-by: Roger Pau Monné
On Thu, Mar 29, Jan Beulich wrote:
> >>> On 27.03.18 at 11:26, wrote:
> > +khz_diff = cpu_khz > gtsc_khz ?
> > + cpu_khz - gtsc_khz : gtsc_khz - cpu_khz;
> abs() (or some variant of it, like __builtin_absl(), seeing that we
> don't appear to have any abstraction
On Tue, Mar 27, 2018 at 11:26:55AM +0200, Olaf Hering wrote:
> Add an option to control when vTSC emulation will be activated for a
> domU with tsc_mode=default. Without such option each TSC access from
> domU will be emulated, which causes a significant perfomance drop for
> workloads that make us
On Thu, Mar 29, 2018 at 12:30:25AM +, Julien Grall wrote:
> (sorry for the formatting)
>
> On Wed, 28 Mar 2018, 21:48 George Dunlap, wrote:
>
> > On 03/28/2018 02:33 PM, Roger Pau Monné wrote:
> > > Hello,
> > >
> > > According to the contribution guidelines document [0] the coverity
> > > d
On Thu, Mar 29, Roger Pau Monné wrote:
> IMO if hardware TSC scaling is supported vtsc_tolerance_khz should be
> ignored, and the TSC should be scaled by the hardware always in order
> to provide accurate values.
Good point, I will double check that part and do nothing if hardware
scaling happens
>>> On 29.03.18 at 10:17, wrote:
> On Thu, Mar 29, Jan Beulich wrote:
>
>> >>> On 27.03.18 at 11:26, wrote:
>> > +khz_diff = cpu_khz > gtsc_khz ?
>> > + cpu_khz - gtsc_khz : gtsc_khz - cpu_khz;
>> abs() (or some variant of it, like __builtin_absl(), seeing that
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 March 2018 07:27
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: RE: possible I/O emulation state machine issue
>
> >>> On 28.03.18 at 18:22, wrote:
> >> From: Jan Be
>>> On 29.03.18 at 10:42, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 29 March 2018 07:27
>>
>> Suppressing the stdvga port intercepts has, btw, not helped the
>> situation.
>>
>
> That surprises me. The whole string emulation should go out to QEMU without
> being broken up
>>> On 29.03.18 at 10:32, wrote:
> On Thu, Mar 29, Roger Pau Monné wrote:
>
>> IMO if hardware TSC scaling is supported vtsc_tolerance_khz should be
>> ignored, and the TSC should be scaled by the hardware always in order
>> to provide accurate values.
>
> Good point, I will double check that pa
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 March 2018 08:52
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
>
> Subject: [PATCH RFC] x86/HVM: suppress I/O completion for port output
>
> We don't break up port requests in case they cross emulation en
On Thu, Mar 29, Roger Pau Monné wrote:
> AFAICT in the chunk above you will disable vtsc without checking if
> the hardware supports TSC scaling, which leads to inaccurate TSC values
> on hardware that could provide accurate results without the software
> emulation overhead.
Is that really the ca
If acpi_id is == nr_acpi_bits, then we access one element beyond the end
of the acpi_psd[] array or we set one bit beyond the end of the bit map
when we do __set_bit(acpi_id, acpi_id_present);
Fixes: 59a568029181 ("xen/acpi-processor: C and P-state driver that uploads
said data to hypervisor.")
S
On Thu, Mar 29, 2018 at 10:58:34AM +0200, Olaf Hering wrote:
> On Thu, Mar 29, Roger Pau Monné wrote:
>
> > AFAICT in the chunk above you will disable vtsc without checking if
> > the hardware supports TSC scaling, which leads to inaccurate TSC values
> > on hardware that could provide accurate re
>>> On 29.03.18 at 10:54, wrote:
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -282,7 +282,7 @@ static int hvmemul_do_io(
>> rc = hvm_send_ioreq(s, &p, 0);
>> if ( rc != X86EMUL_RETRY || currd->is_shutting_down )
>> vio->io
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 March 2018 10:10
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH RFC] x86/HVM: suppress I/O completion for port output
>
> >>> On 29.03.18 at 10:54, wrote:
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
X
From: Oleksandr Andrushchenko
Hello!
Boris/Daniel, I put your R-b tags, so please do let me know if this is not
acceptable, so I remove the tags.
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif
On Thu, Mar 29, Jan Beulich wrote:
> When you use abs() or alike in places like this, it is more immediately
> obvious to the reader what you're doing.
Does every supported compiler actually understand this?
int khz_diff = __builtin_abs(cpu_khz - gtsc_khz);
Or do we need an inline abs() in case i
On 03/29/2018 12:22 PM, Oleksandr Andrushchenko wrote:
Changes since v4:
For your convenience I am attaching diff between v4..v5
diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst
index 8188e03c9d23..009d942386c5 100644
--- a/Documentation/gpu/xen-front.rst
+++ b/Docu
On Tue, Feb 13, 2018 at 02:16:22AM -0700, Jan Beulich wrote:
> >>> On 08.02.18 at 14:46, wrote:
> > Sorry for late reply but I was busy with other stuff.
> >
> > On Fri, Jan 19, 2018 at 08:27:46AM -0700, Jan Beulich wrote:
> >> >>> On 10.01.18 at 14:05, wrote:
> >> > Current limit, PFN_DOWN(xen_p
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 March 2018 13:51
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel@lists.xenproject.org;
> Tim (Xen.org)
> Subject: Re: [PATCH
>>> On 29.03.18 at 11:13, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 29 March 2018 10:10
>>
>> >>> On 29.03.18 at 10:54, wrote:
>> >> --- a/xen/arch/x86/hvm/emulate.c
>> >> +++ b/xen/arch/x86/hvm/emulate.c
>> >> @@ -282,7 +282,7 @@ static int hvmemul_do_io(
>> >>
In my automated SLE_11 builds I often see failures like that:
[ 74s] wrappers.c:5:25: error: x86-emulate.h: No such file or directory
[ 74s] make[6]: *** [wrappers.o] Error 1
Just retriggering the package build fixes the error. SLE11 has make-3.81.
Is that version of make perhaps too old to r
flight 121325 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121325/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 120095
test-amd64-amd64-
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 March 2018 12:41
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel@lists.xenproject.org;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
On 03/29/2018 07:52 AM, Juergen Gross wrote:
> Hi all,
>
> The cut-off date for Xen 4.11 is March 30th, 2018. If you want your
> features to be included for the release, please make sure they are
> committed by March 30th, 2018.
March 30th is a public holiday here in the UK. Is it the same in
Ge
>>> On 29.03.18 at 11:23, wrote:
> On Thu, Mar 29, Jan Beulich wrote:
>
>> When you use abs() or alike in places like this, it is more immediately
>> obvious to the reader what you're doing.
>
> Does every supported compiler actually understand this?
> int khz_diff = __builtin_abs(cpu_khz - gtsc
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 March 2018 10:41
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH RFC] x86/HVM: suppress I/O completion for port output
>
> >>> On 29.03.18 at 11:13, wrote:
On 29/03/18 11:53, George Dunlap wrote:
> On 03/29/2018 07:52 AM, Juergen Gross wrote:
>> Hi all,
>>
>> The cut-off date for Xen 4.11 is March 30th, 2018. If you want your
>> features to be included for the release, please make sure they are
>> committed by March 30th, 2018.
>
> March 30th is a pu
On Thu, Mar 29, 2018 at 11:56:59AM +0200, Juergen Gross wrote:
> On 29/03/18 11:53, George Dunlap wrote:
> > On 03/29/2018 07:52 AM, Juergen Gross wrote:
> >> Hi all,
> >>
> >> The cut-off date for Xen 4.11 is March 30th, 2018. If you want your
> >> features to be included for the release, please m
>>> On 29.03.18 at 11:56, wrote:
> On 29/03/18 11:53, George Dunlap wrote:
>> On 03/29/2018 07:52 AM, Juergen Gross wrote:
>>> Hi all,
>>>
>>> The cut-off date for Xen 4.11 is March 30th, 2018. If you want your
>>> features to be included for the release, please make sure they are
>>> committed by
>>> On 29.03.18 at 11:46, wrote:
> In my automated SLE_11 builds I often see failures like that:
>
> [ 74s] wrappers.c:5:25: error: x86-emulate.h: No such file or directory
> [ 74s] make[6]: *** [wrappers.o] Error 1
>
> Just retriggering the package build fixes the error. SLE11 has make-3.81
On Thu, Mar 29, Jan Beulich wrote:
> Actually I was wrong - we have an abstraction already, just that
> it's upper case: ABS(). But it requires its input to have signed type.
Would this be acceptable?
khz_diff = ABS((long)cpu_khz - (long)gtsc_khz);
Olaf
signature.asc
Description: PGP signature
On 03/29/2018 10:56 AM, Juergen Gross wrote:
> On 29/03/18 11:53, George Dunlap wrote:
>> On 03/29/2018 07:52 AM, Juergen Gross wrote:
>>> Hi all,
>>>
>>> The cut-off date for Xen 4.11 is March 30th, 2018. If you want your
>>> features to be included for the release, please make sure they are
>>> c
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 March 2018 12:55
> To: Paul Durrant
> Cc: JulienGrall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel@lists.xenproject.org;
> Konrad Rzeszutek Wilk ; Tim (Xen.org)
>>> On 29.03.18 at 12:22, wrote:
> On 03/29/2018 10:56 AM, Juergen Gross wrote:
>> On 29/03/18 11:53, George Dunlap wrote:
>>> On 03/29/2018 07:52 AM, Juergen Gross wrote:
Hi all,
The cut-off date for Xen 4.11 is March 30th, 2018. If you want your
features to be included for th
>>> On 29.03.18 at 12:05, wrote:
> On Thu, Mar 29, Jan Beulich wrote:
>
>> Actually I was wrong - we have an abstraction already, just that
>> it's upper case: ABS(). But it requires its input to have signed type.
>
> Would this be acceptable?
> khz_diff = ABS((long)cpu_khz - (long)gtsc_khz);
I
On Thu, Mar 29, 2018 at 04:35:27AM -0600, Jan Beulich wrote:
> >>> On 29.03.18 at 12:22, wrote:
> > On 03/29/2018 10:56 AM, Juergen Gross wrote:
> >> On 29/03/18 11:53, George Dunlap wrote:
> >>> On 03/29/2018 07:52 AM, Juergen Gross wrote:
> Hi all,
>
> The cut-off date for Xen 4.1
On Wed, Mar 28, 2018 at 08:34:14AM +0100, Roger Pau Monne wrote:
> Allow the path to be set from a configure command line option.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://l
On 03/29/2018 11:35 AM, Jan Beulich wrote:
On 29.03.18 at 12:22, wrote:
>> On 03/29/2018 10:56 AM, Juergen Gross wrote:
>>> On 29/03/18 11:53, George Dunlap wrote:
On 03/29/2018 07:52 AM, Juergen Gross wrote:
> Hi all,
>
> The cut-off date for Xen 4.11 is March 30th, 2018. If
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 March 2018 13:55
> To: Paul Durrant
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org; Tim (Xen.org)
>
> Subject: Re: [PATCH v18 10/11] comm
On 29/03/18 12:50, Wei Liu wrote:
> On Thu, Mar 29, 2018 at 04:35:27AM -0600, Jan Beulich wrote:
> On 29.03.18 at 12:22, wrote:
>>> On 03/29/2018 10:56 AM, Juergen Gross wrote:
On 29/03/18 11:53, George Dunlap wrote:
> On 03/29/2018 07:52 AM, Juergen Gross wrote:
>> Hi all,
>>
On Thu, Mar 29, Jan Beulich wrote:
> wrappers.o: $(x86_emulate.h)
Thanks. This did probably help, the build got further. Will send a patch.
But another unrelated regression appeared.
Olaf
signature.asc
Description: PGP signature
___
Xen-devel mailing
It seems the latest seabios that was pulled into staging recently fails
to compile, at least in SLE_11:
[ 86s] Compile checking out/src/hw/blockcmd.o
[ 86s] src/hw/blockcmd.c: In function 'scsi_rep_luns_scan':
[ 86s] src/hw/blockcmd.c:229: error: unknown field 'cdbcmd' specified in
initia
In my automated SLE_11 builds I often see failures like that:
[ 74s] wrappers.c:5:25: error: x86-emulate.h: No such file or directory
[ 74s] make[6]: *** [wrappers.o] Error 1
Signed-off-by: Olaf Hering
---
tools/fuzz/x86_instruction_emulator/Makefile | 2 ++
1 file changed, 2 insertions(+)
>>> On 29.03.18 at 14:01, wrote:
> --- a/tools/fuzz/x86_instruction_emulator/Makefile
> +++ b/tools/fuzz/x86_instruction_emulator/Makefile
> @@ -18,6 +18,8 @@ asm:
>
> asm/%: asm ;
>
> +wrappers.o: $(x86_emulate.h)
> +
> x86-emulate.c x86-emulate.h wrappers.c: %:
> [ -L $* ] || ln -sf
Add an option to control when vTSC emulation will be activated for a
domU with tsc_mode=default. Without such option each TSC access from
domU will be emulated, which causes a significant perfomance drop for
workloads that make use of rdtsc.
One option to avoid the TSC option is to run domUs with
>>> On 29.03.18 at 12:50, wrote:
> On Thu, Mar 29, 2018 at 04:35:27AM -0600, Jan Beulich wrote:
>> >>> On 29.03.18 at 12:22, wrote:
>> > On 03/29/2018 10:56 AM, Juergen Gross wrote:
>> >> On 29/03/18 11:53, George Dunlap wrote:
>> >>> On 03/29/2018 07:52 AM, Juergen Gross wrote:
>> Hi all,
>
>>> On 29.03.18 at 11:53, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 26 March 2018 12:41
>>
>> >>> On 22.03.18 at 12:55, wrote:
>> > --- a/xen/include/xlat.lst
>> > +++ b/xen/include/xlat.lst
>> > @@ -86,6 +86,7 @@
>> > ! memory_map memory.h
>> > ! mem
>>> On 29.03.18 at 13:02, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 26 March 2018 13:55
>>
>> >>> On 26.03.18 at 14:16, wrote:
>> On 22.03.18 at 12:55, wrote:
>> >> --- a/xen/common/grant_table.c
>> >> +++ b/xen/common/grant_table.c
>> >> @@ -3863,6 +3863,35 @@ int me
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 March 2018 13:29
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; StefanoStabellini ; xen-
> de...@lists.xenproject.org; Konrad Rzeszutek Wilk
> ; Tim (Xen.or
>>> On 27.03.18 at 11:07, wrote:
> Instead of flushing the TLB from global pages when switching address
> spaces with XPTI being active just disable global pages via %cr4
> completely when a domain subject to XPTI is active. This avoids the
> need for extra TLB flushes as loading %cr3 will remove
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 29 March 2018 13:43
> To: 'Jan Beulich'
> Cc: StefanoStabellini ; Wei Liu
> ; Andrew Cooper ; Tim
> (Xen.org) ; George Dunlap ;
> Julien Grall ; xen-devel@lists.xenpro
flight 121327 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121327/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 121315
build-arm64-pvops
From: Oleksandr Andrushchenko
Introduce Xen zero-copy helper DRM driver, add user-space API of the driver:
1. DRM_IOCTL_XEN_ZCOPY_DUMB_FROM_REFS
This will create a DRM dumb buffer from grant references provided
by the frontend. The intended usage is:
- Frontend
- creates a dumb/display buff
From: Oleksandr Andrushchenko
Hello!
When using Xen PV DRM frontend driver then on backend side one will need
to do copying of display buffers' contents (filled by the
frontend's user-space) into buffers allocated at the backend side.
Taking into account the size of display buffers and frames pe
Hi,
On 28/03/18 18:46, Stefano Stabellini wrote:
> On Wed, 28 Mar 2018, Andre Przywara wrote:
>> On 28/03/18 01:01, Stefano Stabellini wrote:
>>> On Wed, 21 Mar 2018, Andre Przywara wrote:
The event channel IRQ has level triggered semantics, however the current
VGIC treats everything as
>>> On 27.03.18 at 11:07, wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -63,6 +63,10 @@ boolean_param("nosmp", opt_nosmp);
> static unsigned int __initdata max_cpus;
> integer_param("maxcpus", max_cpus);
>
> +/* opt_invpcid: If false, don't use INVPCID instruction even
Hi Oleksandr,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20180329]
[cannot apply to v4.16-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
>>> On 27.03.18 at 11:07, wrote:
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -51,7 +51,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
> if ( (v = idle_vcpu[smp_processor_id()]) == current )
> sync_local_execstate();
> /* We
>>> On 29.03.18 at 15:17, wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Paul Durrant
>> Sent: 29 March 2018 13:43
>> To: 'Jan Beulich'
>> Cc: StefanoStabellini ; Wei Liu
>> ; Andrew Cooper ; Tim
>> (Xen.org) ; George Dunla
On 29/03/18 15:44, Jan Beulich wrote:
On 27.03.18 at 11:07, wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -63,6 +63,10 @@ boolean_param("nosmp", opt_nosmp);
>> static unsigned int __initdata max_cpus;
>> integer_param("maxcpus", max_cpus);
>>
>> +/* opt_invpcid:
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 29 March 2018 15:25
> To: Paul Durrant
> Cc: StefanoStabellini ; Wei Liu
> ; Andrew Cooper ; Tim
> (Xen.org) ; George Dunlap ;
> Julien Grall ; xen-devel@lists.xenproje
On Thu, Mar 29, 2018 at 06:25:06AM -0600, Jan Beulich wrote:
> >>> On 29.03.18 at 12:50, wrote:
> > On Thu, Mar 29, 2018 at 04:35:27AM -0600, Jan Beulich wrote:
> >> >>> On 29.03.18 at 12:22, wrote:
> >> > On 03/29/2018 10:56 AM, Juergen Gross wrote:
> >> >> On 29/03/18 11:53, George Dunlap wrote
On Thu, Mar 29, 2018 at 01:42:43PM +0200, Olaf Hering wrote:
> It seems the latest seabios that was pulled into staging recently fails
> to compile, at least in SLE_11:
>
> [ 86s] Compile checking out/src/hw/blockcmd.o
> [ 86s] src/hw/blockcmd.c: In function 'scsi_rep_luns_scan':
> [ 86s]
On Thu, Mar 29, Wei Liu wrote:
> Do you use a non-default seabios configuration? Osstest seems to be
> happy with the update.
Not sure how I would create a non-default seabios or toolchain build.
osstest does not use SLE11, so it can not possibly spot such compile
errors. It would certainly be c
Hi,
On 28/03/18 19:47, Stefano Stabellini wrote:
> On Wed, 21 Mar 2018, Andre Przywara wrote:
>> When a VCPU moves to another CPU, we need to adjust the target affinity
>> of any hardware mapped vIRQs, to observe our "physical-follows-virtual"
>> policy.
>> Implement arch_move_irqs() to adjust the
On Thu, Mar 29, 2018 at 04:53:41PM +0200, Olaf Hering wrote:
> On Thu, Mar 29, Wei Liu wrote:
>
> > Do you use a non-default seabios configuration? Osstest seems to be
> > happy with the update.
>
> Not sure how I would create a non-default seabios or toolchain build.
>
> osstest does not use SL
On 29/03/18 16:19, Jan Beulich wrote:
On 27.03.18 at 11:07, wrote:
>> --- a/xen/arch/x86/domain_page.c
>> +++ b/xen/arch/x86/domain_page.c
>> @@ -51,7 +51,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
>> if ( (v = idle_vcpu[smp_processor_id()]) == current )
>>
Stefano pointed out the following situation:
--
1) vcpuA/cpuA is running, it has already handled the event, cleared
evtchn_upcall_pending and EOIed the event_irq but hasn't trapped into
Xen yet. It is still in guest mode.
2) Xen on cpuB calls vcpu_mark_events_pending(vcpuA), th
On Thu, Mar 29, Wei Liu wrote:
> I think this is a problem with seabios upstream. We should ask them to
> fix it and do another release.
https://mail.coreboot.org/pipermail/seabios/2017-November/011932.html
gcc-4.6+ is now required.
Olaf
signature.asc
Description: PGP signature
__
>>> On 29.03.18 at 17:15, wrote:
> On 29/03/18 16:19, Jan Beulich wrote:
> On 27.03.18 at 11:07, wrote:
>>> @@ -102,7 +103,21 @@ void write_cr3_cr4(unsigned long cr3, unsigned long
>>> cr4)
>>> t = pre_flush();
>>>
>>> if ( read_cr4() & X86_CR4_PGE )
>>> +/*
>>> +
Hi all
Seabios has bumped their requirement to 4.6 (released 7 years ago). We
either need to bump our too or have a separate entry for seabios.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Removed extraneous
This series introduces support for direct mapping of guest resources.
The resources are:
- IOREQ server pages
- Grant tables
v19:
- Respond to Jan's latest comments and fix grant table verion setting lost in
re-base
v18:
- Re-base
- Use the now-reference-counted emulating domain to host ior
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages which are assigned to the
emulating d
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_tr
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the new op is not intrinsicly specific to the x86
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
v18:
- Trivial re-base.
---
xen/arch/x86/hvm/ioreq.c
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies th
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
On Thu, Mar 29, 2018 at 05:36:32PM +0200, Olaf Hering wrote:
> On Thu, Mar 29, Wei Liu wrote:
>
> > I think this is a problem with seabios upstream. We should ask them to
> > fix it and do another release.
>
> https://mail.coreboot.org/pipermail/seabios/2017-November/011932.html
>
> gcc-4.6+ is
>>> On 29.03.18 at 17:45, wrote:
> Seabios has bumped their requirement to 4.6 (released 7 years ago). We
> either need to bump our too or have a separate entry for seabios.
Ideally we would then come to common grounds with what the ARM
folks demand. I don't think we should have minimal requireme
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
but it is still small enough to remain on-stack.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc:
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
From: Dongli Zhang
Date: Wed, 28 Mar 2018 07:42:16 +0800
> The "BUG_ON(!frag_iter)" in function xenvif_rx_next_chunk() is triggered if
> the received sk_buff is malformed, that is, when the sk_buff has pattern
> (skb->data_len && !skb_shinfo(skb)->nr_frags). Below is a sample call
> stack:
We sh
Hi all,
as the original freeze date (March 30th, 2018) is a holiday in many
countries and some of the maintainers have been very busy with
security work during most of the development phase of Xen 4.11 I've
decided to shift the freeze date of Xen 4.11 by one week.
So the new freeze date will be A
Stefano Stabellini writes ("[PATCH] xl/libxl: add pvcalls support"):
> Add pvcalls support to libxl and xl. Create the appropriate pvcalls
> entries in xenstore.
...
> + ~/device/pvcalls/$DEVID/* []
> +
> +Paravirtualized POSIX function calls frontend. Described by
> +[docs/misc/pvcalls.markdow
On Thu, 29 Mar 2018, Roger Pau Monné wrote:
> On Thu, Mar 29, 2018 at 12:30:25AM +, Julien Grall wrote:
> > (sorry for the formatting)
> >
> > On Wed, 28 Mar 2018, 21:48 George Dunlap, wrote:
> >
> > > On 03/28/2018 02:33 PM, Roger Pau Monné wrote:
> > > > Hello,
> > > >
> > > > According to
On Thu, Mar 29, 2018 at 4:45 PM, Wei Liu wrote:
> Hi all
>
> Seabios has bumped their requirement to 4.6 (released 7 years ago). We
> either need to bump our too or have a separate entry for seabios.
RHEL / CentOS 6 are still supported, and they come with GCC 4.4.
Other potential options:
1. Ha
flight 121328 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
119227
Tests w
1 - 100 of 122 matches
Mail list logo
