[Xen-devel] [xen-unstable-smoke test] 121369: tolerable all pass - PUSHED

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

[Xen-devel] Need some advices on how to workaround a hardware bug

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

[Xen-devel] [xen-unstable-smoke test] 121354: regressions - FAIL

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

[Xen-devel] [linux-4.1 test] 121332: regressions - trouble: broken/fail/pass

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

[Xen-devel] [xen-unstable-smoke test] 121348: regressions - FAIL

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

Re: [Xen-devel] [PATCH v2] xl/libxl: add pvcalls support

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' ---

[Xen-devel] [PATCH v2] xl/libxl: add pvcalls support

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 +

Re: [Xen-devel] [PATCH] xl/libxl: add pvcalls support

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

[Xen-devel] [xen-4.7-testing test] 121330: regressions - FAIL

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

[Xen-devel] [xen-unstable-smoke test] 121346: tolerable all pass - PUSHED

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

Re: [Xen-devel] seabios regression in staging

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

Re: [Xen-devel] seabios regression in staging

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

Re: [Xen-devel] Upping gcc requirement for x86

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

Re: [Xen-devel] [PATCH] ARM: new VGIC: evtchn: fix potential race in vcpu_mark_events_pending()

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. >

Re: [Xen-devel] Upping gcc requirement for x86

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,

Re: [Xen-devel] Upping gcc requirement for x86

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 > >> >

[Xen-devel] [xen-unstable-smoke test] 121344: tolerable all pass - PUSHED

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

Re: [Xen-devel] Upping gcc requirement for x86

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).

Re: [Xen-devel] Upping gcc requirement for x86

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. >

[Xen-devel] [xen-4.6-testing test] 121328: regressions - FAIL

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

Re: [Xen-devel] Upping gcc requirement for x86

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

Re: [Xen-devel] Make coverity results public

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, >

Re: [Xen-devel] [PATCH] xl/libxl: add pvcalls support

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 >

[Xen-devel] Freeze date for 4.11 shifted by one week

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

Re: [Xen-devel] [PATCH 1/1] xen-netback: process malformed sk_buff correctly to avoid BUG_ON()

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

[Xen-devel] [PATCH v19 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

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

Re: [Xen-devel] Upping gcc requirement for x86

>>> 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

Re: [Xen-devel] seabios regression in staging

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

[Xen-devel] [PATCH v19 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

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

[Xen-devel] [PATCH v19 08/11] tools/libxenforeignmemory: add support for resource mapping

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]

[Xen-devel] [PATCH v19 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

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

[Xen-devel] [PATCH v19 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requested

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

[Xen-devel] [PATCH v19 02/11] x86/hvm/ioreq: simplify code and use consistent naming

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

[Xen-devel] [PATCH v19 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

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

[Xen-devel] [PATCH v19 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

...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

[Xen-devel] [PATCH v19 06/11] x86/hvm/ioreq: add a new mappable resource type...

... 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

[Xen-devel] [PATCH v19 00/11] x86: guest resource mapping

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

[Xen-devel] Upping gcc requirement for x86

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

Re: [Xen-devel] [PATCH v4 7/7] xen/x86: use PCID feature

>>> 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() &

Re: [Xen-devel] seabios regression in staging

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

[Xen-devel] [PATCH] ARM: new VGIC: evtchn: fix potential race in vcpu_mark_events_pending()

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),

Re: [Xen-devel] [PATCH v4 7/7] xen/x86: use PCID feature

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()]) ==

Re: [Xen-devel] seabios regression in staging

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

Re: [Xen-devel] [PATCH v3 32/39] ARM: new VGIC: Implement arch_move_irqs()

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

Re: [Xen-devel] seabios regression in staging

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

Re: [Xen-devel] seabios regression in staging

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]

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

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

Re: [Xen-devel] [PATCH v4 4/7] xen/x86: use invpcid for flushing the TLB

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); >>

Re: [Xen-devel] [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

>>> 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

Re: [Xen-devel] [PATCH v4 7/7] xen/x86: use PCID feature

>>> 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 ) >

Re: [Xen-devel] [PATCH v5 1/1] drm/xen-front: Add support for Xen PV display frontend

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

Re: [Xen-devel] [PATCH v4 4/7] xen/x86: use invpcid for flushing the TLB

>>> 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

Re: [Xen-devel] [PATCH v3 06/39] ARM: evtchn: Handle level triggered IRQs correctly

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

[Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

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

[Xen-devel] [PATCH 1/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

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: -

[Xen-devel] [linux-next test] 121327: regressions - FAIL

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

Re: [Xen-devel] [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

> -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

Re: [Xen-devel] [PATCH v4 5/7] xen/x86: disable global pages for domains with XPTI active

>>> 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

Re: [Xen-devel] [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

> -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

Re: [Xen-devel] [PATCH v18 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

>>> 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 >>

Re: [Xen-devel] [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

>>> 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 @@ >> > !

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

>>> 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

[Xen-devel] [PATCH v6] new config option vtsc_tolerance_khz to avoid TSC emulation

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

Re: [Xen-devel] [PATCH v1] fuzz: wrappers.c depends on x86_emulate.h

>>> 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: %: > [

[Xen-devel] [PATCH v1] fuzz: wrappers.c depends on x86_emulate.h

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,

[Xen-devel] seabios regression in staging

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

Re: [Xen-devel] fuzz/wrappers.c fails to build due to missing x86-emulate.h

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

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

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

Re: [Xen-devel] [PATCH v18 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table

> -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

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

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

Re: [Xen-devel] [PATCH v2 for-4.11] tools: set DEBUG_DIR from configure

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

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

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, > >

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

>>> 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 -

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

>>> 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

Re: [Xen-devel] [PATCH v18 06/11] x86/hvm/ioreq: add a new mappable resource type...

> -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

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

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 >>>

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

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

Re: [Xen-devel] fuzz/wrappers.c fails to build due to missing x86-emulate.h

>>> 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.

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

>>> 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

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

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

Re: [Xen-devel] [PATCH RFC] x86/HVM: suppress I/O completion for port output

> -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

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

>>> 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 =

Re: [Xen-devel] [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

> -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

Re: [Xen-devel] Cut-off date for Xen 4.11 is March 30th, 2018

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

[Xen-devel] [qemu-mainline test] 121325: regressions - FAIL

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

[Xen-devel] fuzz/wrappers.c fails to build due to missing x86-emulate.h

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

Re: [Xen-devel] [PATCH RFC] x86/HVM: suppress I/O completion for port output

>>> 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

Re: [Xen-devel] [PATCH v18 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

> -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

Re: [Xen-devel] [PATCH v3 2/2] x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))

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,

Re: [Xen-devel] [PATCH v5 0/1] drm/xen-front: Add support for Xen PV display frontend

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 +++

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

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

[Xen-devel] [PATCH v5 0/1] drm/xen-front: Add support for Xen PV display frontend

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

[Xen-devel] [PATCH v5 1/1] drm/xen-front: Add support for Xen PV display frontend

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

Re: [Xen-devel] [PATCH RFC] x86/HVM: suppress I/O completion for port output

> -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

Re: [Xen-devel] [PATCH RFC] x86/HVM: suppress I/O completion for port output

>>> 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 ) >>

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

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

[Xen-devel] [PATCH v2] xen/acpi: off by one in read_acpi_id()

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.")

Re: [Xen-devel] possible I/O emulation state machine issue

>>> 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

Re: [Xen-devel] possible I/O emulation state machine issue

> -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 >

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

>>> 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   2   >