flight 121369 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121369/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi,
I met an EPT violation and then the guest was destroyed by Xen
after assigning a device to the guest. After some investigation, I found
it is caused by the device isn't a standard PCI device -- its MSI-x PBA
locates in the same 4k-byte page with other CSR. When the driver in
guest writes the
flight 121354 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121354/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-build fail in 121348 REGR. vs. 121346
Tests which
flight 121332 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121332/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair broken
test-amd64-i386-libvirt-pair 5
flight 121348 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121348/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 121346
Tests which
On 03/29/2018 04:07 PM, Stefano Stabellini wrote:
Add pvcalls support to libxl and xl. Create the appropriate pvcalls
entries in xenstore.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- rename pvcalls to pvcallsif internally in libxl to avoid `pvcallss'
---
Add pvcalls support to libxl and xl. Create the appropriate pvcalls
entries in xenstore.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- rename pvcalls to pvcallsif internally in libxl to avoid `pvcallss'
---
docs/misc/xenstore-paths.markdown| 9 +
On Thu, 29 Mar 2018, Ian Jackson wrote:
> 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
flight 121330 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121330/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 121247
flight 121346 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121346/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Thu, Mar 29, Doug Goldstein wrote:
> If you'd be willing to create a SLE11 Docker container, we can add that
> to the tree and start doing builds against it.
I do not know how to do that. Any pointers?
Olaf
signature.asc
Description: PGP signature
On 3/29/18 9:53 AM, 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 SLE11, so it can not
On 3/29/18 12:05 PM, George Dunlap wrote:
> On Thu, Mar 29, 2018 at 4:45 PM, Wei Liu wrote:
>
> Long term I think we want to get away from building seabios ourselves
> altogether; but it's a bit late in the release cycle to work out that
> kind of change.
>
> On the whole
On Thu, 29 Mar 2018, Andre Przywara wrote:
> 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.
>
On Thu, Mar 29, 2018 at 6:20 PM, Wei Liu wrote:
> On Thu, Mar 29, 2018 at 06:14:08PM +0100, George Dunlap wrote:
>> On Thu, Mar 29, 2018 at 6:10 PM, Wei Liu wrote:
>> > On Thu, Mar 29, 2018 at 06:05:57PM +0100, George Dunlap wrote:
>> >> On Thu, Mar 29,
On Thu, Mar 29, 2018 at 06:14:08PM +0100, George Dunlap wrote:
> On Thu, Mar 29, 2018 at 6:10 PM, Wei Liu wrote:
> > On Thu, Mar 29, 2018 at 06:05:57PM +0100, George Dunlap wrote:
> >> On Thu, Mar 29, 2018 at 4:45 PM, Wei Liu wrote:
> >> > Hi all
> >> >
flight 121344 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121344/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Thu, Mar 29, 2018 at 6:10 PM, Wei Liu wrote:
> On Thu, Mar 29, 2018 at 06:05:57PM +0100, George Dunlap wrote:
>> 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).
On Thu, Mar 29, 2018 at 06:05:57PM +0100, George Dunlap wrote:
> 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.
>
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
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
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,
>
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
>
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
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
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
>>> 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
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
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
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]
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
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
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
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
...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
... 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
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
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
>>> 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() &
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
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),
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()]) ==
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
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
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
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, 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
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);
>>
>>> 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
>>> 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 )
>
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/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
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
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
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:
-
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
> -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
>>> 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
> -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
>>> 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
>>
>>> 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 @@
>> > !
>>> 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
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 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: %:
> [
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,
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
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
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
> -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
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
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
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 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 -
>>> 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
> -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
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
>>>
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
>>> 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.
>>> 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
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
> -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
>>> 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 =
> -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
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
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
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
>>> 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
> -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
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,
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
+++
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
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: 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
> -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
>>> 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, , 0);
>> if ( rc != X86EMUL_RETRY || currd->is_shutting_down )
>>
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
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.")
>>> 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
> -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 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,
1 - 100 of 115 matches
Mail list logo