[Xen-devel] [qemu-mainline test] 133317: regressions - trouble: broken/fail/pass

flight 133317 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/133317/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken test-amd64-amd64-pair

Re: [Xen-devel] [PATCH v4 3/4] x86/mm: handle foreign mappings in p2m_entry_modify

> From: Roger Pau Monné [mailto:roger@citrix.com] > Sent: Tuesday, February 19, 2019 10:01 PM > > On Tue, Feb 19, 2019 at 06:14:00AM +, Tian, Kevin wrote: > > > From: Roger Pau Monne [mailto:roger@citrix.com] > > > Sent: Tuesday, February 19, 2019 1:27 AM > > > diff --git a/xen/arch/x8

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

flight 133343 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133343/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 1

Re: [Xen-devel] [RESEND PATCH 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'

Hi Ira Martin and I looked at your patch and agree that it doesn't change functionality for Orangefs. Reviewed-by: Mike Marshall On Wed, Feb 20, 2019 at 12:32 AM wrote: > > From: Ira Weiny > > To facilitate additional options to get_user_pages_fast() change the > singular write parameter to

[Xen-devel] [xen-unstable test] 133316: regressions - trouble: blocked/broken/fail/pass

flight 133316 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/133316/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw broken build-i386-pvops

[Xen-devel] [ovmf test] 133318: trouble: broken/pass

flight 133318 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/133318/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-amd64-xl-

Re: [Xen-devel] [RESEND PATCH 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'

Hi Ira, On Wed, Feb 20, 2019 at 11:01 AM wrote: > > From: Ira Weiny > > To facilitate additional options to get_user_pages_fast() change the > singular write parameter to be gup_flags. > > This patch does not change any functionality. New functionality will > follow in subsequent patches. > > S

[Xen-devel] [xen-unstable-smoke test] 133340: trouble: blocked/broken/pass

flight 133340 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133340/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf

Re: [Xen-devel] [PATCH v4 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API

On Fri, Feb 15, 2019 at 8:06 AM Souptick Joarder wrote: > > Previouly drivers have their own way of mapping range of > kernel pages/memory into user vma and this was done by > invoking vm_insert_page() within a loop. > > As this pattern is common across different drivers, it can > be generalized b

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

On 2/20/19 3:39 PM, Marek Marczykowski-Górecki wrote: On Wed, Feb 20, 2019 at 08:15:30PM +, Joao Martins wrote: 2. PV Driver support (patches 17 - 39) We start by redirecting hypercalls from the backend to routines which emulate the behaviour that PV backends expect i.e. grant tab

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

On 2/20/19 1:09 PM, Paolo Bonzini wrote: On 20/02/19 21:15, Joao Martins wrote: 2. PV Driver support (patches 17 - 39) We start by redirecting hypercalls from the backend to routines which emulate the behaviour that PV backends expect i.e. grant table and interdomain events. Next, we ad

[Xen-devel] [xen-4.9-testing test] 133314: regressions - trouble: blocked/broken/fail/pass

flight 133314 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/133314/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-i386-pvgrub broken test-amd64-amd64-xl-qemuu-win10-i386

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

On Wed, Feb 20, 2019 at 08:15:30PM +, Joao Martins wrote: > 2. PV Driver support (patches 17 - 39) > > We start by redirecting hypercalls from the backend to routines > which emulate the behaviour that PV backends expect i.e. grant > table and interdomain events. Next, we add support for l

[Xen-devel] [linux-linus test] 133313: regressions - trouble: blocked/broken/fail/pass

flight 133313 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/133313/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken test-amd64-i386-xl-qemuu-debianhvm-amd64-s

Re: [Xen-devel] xen/evtchn and forced threaded irq

Hi Boris, On 2/20/19 9:46 PM, Boris Ostrovsky wrote: On 2/20/19 3:46 PM, Julien Grall wrote: (+ Andrew and Jan for feedback on the event channel interrupt) Hi Boris, Thank you for the your feedback. On 2/20/19 8:04 PM, Boris Ostrovsky wrote: On 2/20/19 1:05 PM, Julien Grall wrote: Hi, On

Re: [Xen-devel] xen/evtchn and forced threaded irq

On 2/20/19 3:46 PM, Julien Grall wrote: > (+ Andrew and Jan for feedback on the event channel interrupt) > > Hi Boris, > > Thank you for the your feedback. > > On 2/20/19 8:04 PM, Boris Ostrovsky wrote: >> On 2/20/19 1:05 PM, Julien Grall wrote: >>> Hi, >>> >>> On 20/02/2019 17:07, Boris Ostrovsky

Re: [Xen-devel] XEN on R-CAR H3

ср, 20 февр. 2019 г., 22:14 Julien Grall : > Hi Amit, Hi, Julien, Amit. Sorry for formatting, writing from my mobile. If I am not mistaken, the diff between BSP's and mainline device trees is in reserved memory area. BSP device tree (1) contains reserved memory regions, but the mainline one (2

[Xen-devel] [xen-unstable-smoke test] 133337: trouble: broken/pass

flight 17 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/17/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl broken test-armhf-arm

Re: [Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

On 20/02/19 21:15, Joao Martins wrote: > 2. PV Driver support (patches 17 - 39) > > We start by redirecting hypercalls from the backend to routines > which emulate the behaviour that PV backends expect i.e. grant > table and interdomain events. Next, we add support for late > initialization o

Re: [Xen-devel] xen/evtchn and forced threaded irq

(+ Andrew and Jan for feedback on the event channel interrupt) Hi Boris, Thank you for the your feedback. On 2/20/19 8:04 PM, Boris Ostrovsky wrote: On 2/20/19 1:05 PM, Julien Grall wrote: Hi, On 20/02/2019 17:07, Boris Ostrovsky wrote: On 2/20/19 9:15 AM, Julien Grall wrote: Hi Boris, Th

[Xen-devel] [PATCH RFC 36/39] drivers/xen: xen_shim_domain() support

Enable /dev/xen/{gntdev,evtchn} and /proc/xen/ for xen_shim_domain(). These interfaces will be used by xenstored to initialize its event channel port and the kva used to communicate with the xenbus driver. Signed-off-by: Joao Martins --- drivers/xen/evtchn.c | 4 +++- drivers/xen/priv

[Xen-devel] [PATCH RFC 32/39] xen/balloon: xen_shim_domain() support

Xen ballooning uses hollow struct pages (with the underlying PFNs being populated/unpopulated via hypercalls) which are used by the grant logic to map grants from other domains. For purposes of a KVM based xen-shim, this model is not useful -- mapping is unnecessary since all guest memory is alrea

[Xen-devel] [PATCH RFC 17/39] x86/xen: export vcpu_info and shared_info

From: Ankur Arora Also remove __init annotations from xen_evtchn_2l/fifo_init(). This allows us to support 2-level event channel ABI on xen_shim_domain(). Signed-off-by: Ankur Arora --- arch/x86/xen/enlighten.c | 3 +++ drivers/xen/events/events_2l.c | 2 +- drivers/xen/events/event

[Xen-devel] [PATCH RFC 33/39] xen/grant-table: xen_shim_domain() support

With xen-shim, allocate_xenballooned_pages() only allocates a place-holder page (pfn 0) expecting a subsequent map_grant_ref to fix it up. However, this means that, until the grant operation (GNTTABOP_map_grant_ref) provides a valid page, we cannot set PagePrivate or save any state. This patch el

[Xen-devel] [PATCH RFC 38/39] xen-blkback: xen_shim_domain() support

With xen_shim_domain() enabled, the struct pages used for grant mappings are only valid in the interval between GNTTABOP_map_grant_ref and GNTTABOP_unmap_grant_ref. Ensure that we do not cache the struct page outside that duration. Also, update the struct page for the segment after GNTTABOP_map_g

[Xen-devel] [PATCH RFC 34/39] xen/gntdev: xen_shim_domain() support

From: Ankur Arora GNTTABOP_map_grant_ref treats host_addr as an OUT parameter for xen_shim_domaim(). Accordingly it's updated in struct gnttab_unmap_grant_ref before it gets used via GNTTABOP_unmap_grant_ref. Co-developed-by: Joao Martins Signed-off-by: Ankur Arora Signed-off-by: Joao Martins

[Xen-devel] [PATCH RFC 20/39] xen-blkback: module_exit support

Implement module_exit to allow users to do module unload of blkback. We prevent users from module unload whenever there are still interfaces allocated, in other words, do module_get on xen_blkif_alloc() and module_put on xen_blkif_free(). Signed-off-by: Joao Martins --- drivers/block/xen-blkbac

[Xen-devel] [PATCH RFC 35/39] xen/xenbus: xen_shim_domain() support

From: Ankur Arora Fixup the gnttab unmap_ops (and other data structures) to handle host_addr as an OUT parameter from the call to GNTTABOP_map_grant_ref. Also, allow xenstored to be hosted in XS_LOCAL mode for xen_shim_domain() -- this means that it does not need to acquire xenstore evtchn and p

[Xen-devel] [PATCH RFC 31/39] xen-shim: introduce shim domain driver

From: Ankur Arora xen-shim.ko sets up and tears down state needed to support Xen backends. The underlying primitives that are exposed are interdomain event-channels and grant-table map/unmap/copy. We setup the following: * Initialize shared_info and vcpu_info pages, essentially setting up

[Xen-devel] [PATCH RFC 18/39] x86/xen: make hypercall_page generic

From: Ankur Arora Export hypercall_page as a generic interface which can be implemented by other hypervisors. With this change, hypercall_page now points to the newly introduced xen_hypercall_page which is seeded by Xen, or to one that is filled in by a different hypervisor. Signed-off-by: Ankur

[Xen-devel] [PATCH RFC 19/39] xen/xenbus: xenbus uninit support

This allows reinitialization of xenbus which is useful for xen_shim_domain() support. Cleaning xenbus state means cancelling pending watch events, and deleting all watches, closing xenstore event channel and finally stopping xenbus/xenwatch kthreads alongside unregistering /proc/xen. Signed-off-by

[Xen-devel] [PATCH RFC 00/39] x86/KVM: Xen HVM guest support

Hey, Presented herewith a series that allows KVM to boot Xen x86 HVM guests (with their respective frontends and backends). On the hypervisor side, the approach is to keep the implementation similar to how HyperV was done on x86 KVM. On the backend driver side, the intent is to reuse Xen suppor

Re: [Xen-devel] XEN on R-CAR H3

Hi Amit, Thank you for the report. On 2/19/19 4:46 PM, Amit Tomer wrote: > (XEN) CPU7 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073), > (XEN) disable cpu (see big.LITTLE.txt under docs/). > (XEN) CPU7 never came online > (XEN) Failed to bring up CPU 7 (error -5) > (XEN) Brought up 4

Re: [Xen-devel] xen/evtchn and forced threaded irq

On 2/20/19 1:05 PM, Julien Grall wrote: > Hi, > > On 20/02/2019 17:07, Boris Ostrovsky wrote: >> On 2/20/19 9:15 AM, Julien Grall wrote: >>> Hi Boris, >>> >>> Thank you for your answer. >>> >>> On 20/02/2019 00:02, Boris Ostrovsky wrote: On Tue, Feb 19, 2019 at 05:31:10PM +, Julien Grall w

[Xen-devel] [linux-3.18 test] 133307: regressions - trouble: blocked/broken/fail/pass

flight 133307 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133307/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-raw broken test-amd64-i386-libvirt

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 20/02/2019 08:55, Jan Beulich wrote: > > Everything, absolutely everything is possible as a cause for a crash. > I don't see why device isolation would matter here at all. Page table > corruption (be it IOMMU or CPU one) can be caused by > malfunctioning kernel code, entirely unrelated to what

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 20/02/2019 09:01, Jan Beulich wrote: > But isn't it a valid question whether keeping interrupt remapping > enabled is helpful or potentially making things worse? The > description of the patch discusses the DMA translation aspects > only. Unless the crash kernel would always operate in polling >

[Xen-devel] [xen-4.10-testing test] 133311: trouble: blocked/broken/fail/pass

flight 133311 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/133311/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken test-amd64-amd64

Re: [Xen-devel] XEN on R-CAR H3

Hi, > We use earlier BSP version and we didn't face the similar issue. > > We have a plan to switch to recent BSP version (3.15). So, I will come > up with updates when we migrate. Thanks for this information, we have now built it for 3.9 but yet to test the images. Also, it would be great if you

Re: [Xen-devel] [PATCH] x86/shadow: don't use map_domain_page_global() on paths that may not fail

On 20/02/2019 15:15, Jan Beulich wrote: > The assumption (according to one comment) and hope (according to > another) that map_domain_page_global() can't fail are both wrong on > large enough systems. Do away with the guest_vtable field altogether, > and establish / tear down the desired mapping as

Re: [Xen-devel] [PATCH] iommu: leave IOMMU enabled by default during kexec crash transition

On 20/02/2019 08:48, Jan Beulich wrote: > > Some entity needs to decide whether to add the respective command > line option to the crash kernel's command line. It should be this same > entity to tell Xen whether to keep the IOMMU enabled while invoking > the crash kernel. I am merely guessing that

Re: [Xen-devel] XEN on R-CAR H3

On 19.02.19 18:46, Amit Tomer wrote: Hi Hi [1] https://elinux.org/R-Car/Boards/Yocto-Gen3 We tried BSP release v3.15.0 from above link but see following message: [ 45.518865] => setenv xen_addr_r 0x4800;setenv fdt_addr_r 0x4a00;setenv kernel_addr_r 0x7a00 [ 52.430467]

Re: [Xen-devel] [RESEND PATCH 0/7] Add FOLL_LONGTERM to GUP fast and use it

On Wed, Feb 20, 2019 at 07:19:30AM -0800, Christoph Hellwig wrote: > On Tue, Feb 19, 2019 at 09:30:33PM -0800, ira.we...@intel.com wrote: > > From: Ira Weiny > > > > Resending these as I had only 1 minor comment which I believe we have > > covered > > in this series. I was anticipating these go

Re: [Xen-devel] xen/evtchn and forced threaded irq

Hi, On 20/02/2019 17:07, Boris Ostrovsky wrote: On 2/20/19 9:15 AM, Julien Grall wrote: Hi Boris, Thank you for your answer. On 20/02/2019 00:02, Boris Ostrovsky wrote: On Tue, Feb 19, 2019 at 05:31:10PM +, Julien Grall wrote: Hi all, I have been looking at using Linux RT in Dom0. Once

Re: [Xen-devel] [PATCH V2 3/3] xen/arm: Add SCIFA UART support for early printk

On 19.02.19 12:09, Julien Grall wrote: Hi Oleksandr, Hi Julien Actually, the main difference for the "early printk" support is in two reg offsets: +#define SCIFA_SCASSR   0x14    /* Serial status register */ +#define SCIFA_SCAFTDR  0x20    /* Transmit FIFO data register */ +#define SCI

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

flight 133329 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133329/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 133312 Tests

Re: [Xen-devel] [PATCH V2 1/3] xen/arm: drivers: scif: Add support for SCIFA compatible UARTs

On 19.02.19 12:00, Julien Grall wrote: Hi Oleksandr, On 2/18/19 8:14 PM, Oleksandr wrote: On 18.02.19 16:00, Julien Grall wrote: Hi, Hi Hi Julien On 01/02/2019 12:37, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Extend existing driver to be able to handle SCIFA interf

Re: [Xen-devel] xen/evtchn and forced threaded irq

On 2/20/19 9:15 AM, Julien Grall wrote: > Hi Boris, > > Thank you for your answer. > > On 20/02/2019 00:02, Boris Ostrovsky wrote: >> On Tue, Feb 19, 2019 at 05:31:10PM +, Julien Grall wrote: >>> Hi all, >>> >>> I have been looking at using Linux RT in Dom0. Once the guest is >>> started, >>> t

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

On Wed, Feb 20, 2019 at 01:09:56PM +, Wei Liu wrote: [...] > I think under-allocate-then-map looks plausible. xmalloc will need > to allocate pages, put them into an array and call __vmap on that array > directly. The biggest issue with this approach is that we now need an array of 1UL

[Xen-devel] [PATCH 2/6] osstest: introduce a helper to create a weblink to a directory

Signed-off-by: Roger Pau Monné --- Osstest/TestSupport.pm | 13 + 1 file changed, 13 insertions(+) diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm index c6da5ee9..12427d11 100644 --- a/Osstest/TestSupport.pm +++ b/Osstest/TestSupport.pm @@ -125,6 +125,7 @@ BEGIN {

[Xen-devel] [PATCH 5/6] osstest: introduce a script to build a FreeBSD package repository

The building of the binary packages itself is done with the poudriere tool, that given a set of port names generates a binary package repository with the requested packages and all it's dependencies. Add a packages build job in the FreeBSD flight. Note that the binary packages generated are tied t

[Xen-devel] [PATCH 3/6] osstest: allow to perform multiple anoints in the same transaction

In the same way allow to perform several fetches in the same retrieve transaction. Further patches will anoint a FreeBSD image and a binary ports tree in the same transaction, and it's required to do it in the same transaction in order to avoid inconsistencies when fetching them. Note that most o

[Xen-devel] [PATCH 4/6] osstest: introduce a helper to get the svn revision of a git commit

This only works when the svn revision is stored as a git note with the format 'revision='. Such conversion is required in order to bootstrap a FreeBSD system without relying on external package repositories. FreeBSD base system only contains a subversion client (no git client), and thus in order t

[Xen-devel] [PATCH 1/6] osstest: introduce a helper to stash a whole directory

Without compressing it. Signed-off-by: Roger Pau Monné --- Osstest/TestSupport.pm | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm index 334cc2cb..c6da5ee9 100644 --- a/Osstest/TestSupport.pm +++ b/Osstest/Tes

[Xen-devel] [PATCH 6/6] osstest: use a locally built pkg repository for FreeBSD

This removes the dependency on the official pkg repository, which is dangerous when not testing stable branches, since the ABI of the development branch is not stable, and thus it's easy for packages to get out of sync, or for osstest to test an old FreeBSD version that has an ABI different than th

[Xen-devel] [PATCH 0/6] osstest: create a local binary FreeBSD package repository

Hello, In order to reliably run FreeBSD test with the development branch (aka HEAD) osstest needs it's custom binary package repository that contains the packages built against the specific version of FreeBSD under test. FreeBSD HEAD doesn't have any ABI guarantees, and as such binary packages are

[Xen-devel] [PATCH] tools/xentop: Display '-' when stats are not available.

From: Pritha Srivastava Displaying 0 is misleading. Signed-off-by: Pritha Srivastava Signed-off-by: Ronan Abhamon --- tools/xenstat/libxenstat/src/xenstat.c | 6 + tools/xenstat/libxenstat/src/xenstat.h | 3 + tools/xenstat/libxenstat/src/xenstat_linux.c | 47 +++--- tools/xe

Re: [Xen-devel] [RESEND PATCH 0/7] Add FOLL_LONGTERM to GUP fast and use it

On Tue, Feb 19, 2019 at 09:30:33PM -0800, ira.we...@intel.com wrote: > From: Ira Weiny > > Resending these as I had only 1 minor comment which I believe we have covered > in this series. I was anticipating these going through the mm tree as they > depend on a cleanup patch there and the IB chang

[Xen-devel] [PATCH] x86/shadow: don't use map_domain_page_global() on paths that may not fail

The assumption (according to one comment) and hope (according to another) that map_domain_page_global() can't fail are both wrong on large enough systems. Do away with the guest_vtable field altogether, and establish / tear down the desired mapping as necessary. The alternatives, discarded as bein

[Xen-devel] [linux-4.9 test] 133308: trouble: blocked/broken/fail/pass

flight 133308 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/133308/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win10-i386 broken test-amd64-amd6

Re: [Xen-devel] [PATCH 4/4] x86/vmx: Properly flush the TLB when an altp2m is modified

>>> On 19.02.19 at 23:18, wrote: > @@ -4319,17 +4320,42 @@ bool vmx_vmenter_helper(const struct cpu_user_regs > *regs) > > if ( paging_mode_hap(curr->domain) ) > { > -struct ept_data *ept = &p2m_get_hostp2m(curr->domain)->ept; > +struct ept_data *ept = &p2m_get_hostp2m

Re: [Xen-devel] [PATCH 3/4] x86/vmx: Fix security issue when a guest balloons out the #VE info page

>>> On 19.02.19 at 23:18, wrote: > @@ -58,25 +57,67 @@ altp2m_vcpu_destroy(struct vcpu *v) > > int altp2m_vcpu_enable_ve(struct vcpu *v, gfn_t gfn) > { > +struct domain *d = v->domain; > +struct altp2mvcpu *a = &vcpu_altp2m(v); > p2m_type_t p2mt; > +mfn_t mfn; > +struct pa

Re: [Xen-devel] [PATCH v3 23/25] hw/ipmi: Assert outlen > outpos

On Wed, Feb 20, 2019 at 02:02:30AM +0100, Philippe Mathieu-Daudé wrote: > A througfull audit show that all time data is added to outbuf[], > 'outlen' is incremented. Then at creation and each time > continue_send() returns it pass thru check_reset which resets > 'outpos', thus we always have 'outl

Re: [Xen-devel] [Qemu-devel] [PATCH v3 00/25] chardev: Convert qemu_chr_write() to take a size_t argument

On 2/20/19 5:30 AM, Daniel P. Berrangé wrote: >> Since Paolo you suggested the change, could you give some convincing >> arguments that it's worth taking the plunge? > > The chardev write/read methods will end up calling libc read/write > methods, whose parameters are "size_t count". In my mind,

Re: [Xen-devel] xen/evtchn and forced threaded irq

Hi Boris, Thank you for your answer. On 20/02/2019 00:02, Boris Ostrovsky wrote: On Tue, Feb 19, 2019 at 05:31:10PM +, Julien Grall wrote: Hi all, I have been looking at using Linux RT in Dom0. Once the guest is started, the console is ending to have a lot of warning (see trace below). A

Re: [Xen-devel] [PATCH 1/4] xen/common: Break domain_unmap_resources() out of domain_kill()

>>> On 19.02.19 at 23:46, wrote: > On 19/02/2019 22:39, Razvan Cojocaru wrote: >> On 2/20/19 12:18 AM, Andrew Cooper wrote: >>> A subsequent change is going to need an x86-specific unmapping step, so take >>> the opportunity to split the current vcpu unmapping out into a dedicated > path. >>> >>>

Re: [Xen-devel] [PATCH 2/4] x86/altp2m: Rework #VE enable/disable paths

>>> On 20.02.19 at 00:10, wrote: > On 2/20/19 12:18 AM, Andrew Cooper wrote: >> Split altp2m_vcpu_{enable,disable}_ve() out of the >> HVMOP_altp2m_vcpu_{enable,disable}_notify marshalling logic. A future > change >> is going to need to call altp2m_vcpu_disable_ve() from the domain_kill() > path

Re: [Xen-devel] [PATCH v3 09/11] optee: add support for RPC commands

Hi, On 19/02/2019 16:14, Volodymyr Babchuk wrote: Hi Julien, Julien Grall writes: Hi Volodymyr, On 18/12/2018 21:11, Volodymyr Babchuk wrote: From: Volodymyr Babchuk OP-TEE can issue multiple RPC requests. We are interested mostly in request that asks NW to allocate/free shared memory fo

Re: [Xen-devel] [PATCH v3 24/25] chardev: Let qemu_chr_fe_write[_all] use size_t type argument

On Wed, Feb 20, 2019 at 2:08 AM Philippe Mathieu-Daudé wrote: > > All caller have been audited and call these functions with > unsigned arguments. > > Most of them use a size_t argument, or directly pass sizeof(). > > One case is unclear: the mux_chr_write() call in chardev/char-mux.c. > There we

Re: [Xen-devel] [PATCH v2 for-4.12] x86/vpmu: Improve documentation and parsing for vpmu=

>>> On 20.02.19 at 14:29, wrote: > The behaviour of vpmu= being exclusive of vpmu=bts|ipc|arch is odd and > contrary to Xen's normal command line parsing behaviour. Rewrite the parsing > to use the normal form, but retain the previous behaviour where the use of > bts/ipc/arch implies vpmu=true. >

Re: [Xen-devel] [PATCH v3 23/25] hw/ipmi: Assert outlen > outpos

Hi On Wed, Feb 20, 2019 at 2:08 AM Philippe Mathieu-Daudé wrote: > > A througfull audit show that all time data is added to outbuf[], througfull? :) thorough? > 'outlen' is incremented. Then at creation and each time > continue_send() returns it pass thru check_reset which resets > 'outpos', th

[Xen-devel] [PATCH v2 for-4.12] x86/vpmu: Improve documentation and parsing for vpmu=

The behaviour of vpmu= being exclusive of vpmu=bts|ipc|arch is odd and contrary to Xen's normal command line parsing behaviour. Rewrite the parsing to use the normal form, but retain the previous behaviour where the use of bts/ipc/arch implies vpmu=true. Parts of the documenation are stale, most

Re: [Xen-devel] [PATCH v3 04/25] chardev: Let qemu_chr_be_can_write() return a size_t types

Hi On Wed, Feb 20, 2019 at 12:26 PM Philippe Mathieu-Daudé wrote: > > On 2/20/19 11:40 AM, Marc-André Lureau wrote: > > Hi > > > > On Wed, Feb 20, 2019 at 2:04 AM Philippe Mathieu-Daudé > > wrote: > >> > >> In the previous commit we added an assert to be sure than > >> qemu_chr_be_can_write() wi

Re: [Xen-devel] [PATCH v3 08/11] optee: add support for arbitrary shared memory

On 19/02/2019 15:59, Volodymyr Babchuk wrote: Hello Julien, Hi Volodymyr, Julien Grall writes: Hi Volodymyr, On 18/12/2018 21:11, Volodymyr Babchuk wrote: From: Volodymyr Babchuk Shared memory is widely used by NW to communicate with TAs in OP-TEE. NW can share part of own memory with T

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

On Wed, Feb 20, 2019 at 02:00:52PM +0100, Roger Pau Monné wrote: > On Wed, Feb 20, 2019 at 12:29:01PM +, Wei Liu wrote: > > On Thu, Jan 24, 2019 at 11:44:55AM +, Wei Liu wrote: > > > 3. Implement xenheap using vmap infrastructure > > > > > > This helps preserve xenheap's "always mapped" pr

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

On Wed, Feb 20, 2019 at 12:29:01PM +, Wei Liu wrote: > On Thu, Jan 24, 2019 at 11:44:55AM +, Wei Liu wrote: > > 3. Implement xenheap using vmap infrastructure > > > > This helps preserve xenheap's "always mapped" property. At the moment, > > vmap relies on xenheap, we want to turn this rel

Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

On Thu, Jan 24, 2019 at 11:44:55AM +, Wei Liu wrote: > 3. Implement xenheap using vmap infrastructure > > This helps preserve xenheap's "always mapped" property. At the moment, > vmap relies on xenheap, we want to turn this relationship around. > > There is a loop what needs breaking in the n

Re: [Xen-devel] [PATCH v3 19/25] s390/ebcdic: Use size_t to iterate over arrays

On 2/20/19 10:40 AM, Cornelia Huck wrote: > On Wed, 20 Feb 2019 02:02:26 +0100 > Philippe Mathieu-Daudé wrote: > >> Signed-off-by: Philippe Mathieu-Daudé >> --- >> include/hw/s390x/ebcdic.h | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/include/hw/s390x/ebcd

Re: [Xen-devel] [Qemu-devel] [PATCH v3 25/25] chardev: Let qemu_chr_write[_all] use size_t

On 2/20/19 11:42 AM, Marc-André Lureau wrote: > Hi > > On Wed, Feb 20, 2019 at 11:39 AM Daniel P. Berrangé > wrote: >> >> On Wed, Feb 20, 2019 at 02:02:32AM +0100, Philippe Mathieu-Daudé wrote: >> >>> diff --git a/include/chardev/char.h b/include/chardev/char.h >>> index 0341dd1ba2..2e3b5a15ca 1

Re: [Xen-devel] [Qemu-devel] [PATCH v3 00/25] chardev: Convert qemu_chr_write() to take a size_t argument

On Wed, Feb 20, 2019 at 11:53:42AM +0100, Marc-André Lureau wrote: > Hi > > On Wed, Feb 20, 2019 at 2:02 AM Philippe Mathieu-Daudé > wrote: > > > > Hi, > > > > This series convert the chardev::qemu_chr_write() to take unsigned > > length argument. To do so I went through all caller and checked if

Re: [Xen-devel] [PATCH v3 04/25] chardev: Let qemu_chr_be_can_write() return a size_t types

On 2/20/19 11:40 AM, Marc-André Lureau wrote: > Hi > > On Wed, Feb 20, 2019 at 2:04 AM Philippe Mathieu-Daudé > wrote: >> >> In the previous commit we added an assert to be sure than >> qemu_chr_be_can_write() will never return a negative value. >> We can now change its prototype to return a size

Re: [Xen-devel] [PATCH v3 17/25] net/filter-mirror: Use size_t

Hi On Wed, Feb 20, 2019 at 2:07 AM Philippe Mathieu-Daudé wrote: > > Since iov_size() returns a size_t, no need to use a signed type. And it is the variable only purpose. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Marc-André Lureau > --- > net/filter-mirror.c | 2 +- > 1 file

Re: [Xen-devel] [PATCH v3 16/25] tpm: Use size_t to hold sizes

On Wed, Feb 20, 2019 at 2:06 AM Philippe Mathieu-Daudé wrote: > > Avoid to use a signed type to hold an unsigned value. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Marc-André Lureau > --- > hw/tpm/tpm_emulator.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > di

Re: [Xen-devel] [PATCH v3 14/25] virtio-serial: Let VirtIOSerialPortClass::have_data() use size_t

On Wed, Feb 20, 2019 at 2:06 AM Philippe Mathieu-Daudé wrote: > > Both callers in hw/char/virtio-serial-bus.c provide unsigned values, > even the trace event display an unsigned value. > Convert the have_data() handler to take an unsigned value. > > Signed-off-by: Philippe Mathieu-Daudé Reviewe

Re: [Xen-devel] [PATCH v3 12/25] xen: Let buffer_append() return the size consumed

Hi On Wed, Feb 20, 2019 at 2:06 AM Philippe Mathieu-Daudé wrote: > > The buffer.size and buffer.consumed fields are only updated within the > buffer_append() body. We can simply let buffer_append() return the > difference (the buffer consumed). > > Signed-off-by: Philippe Mathieu-Daudé This is

Re: [Xen-devel] [PATCH v3 02/25] chardev: Assert IOCanReadHandler can not be negative

On 2/20/19 11:03 AM, Marc-André Lureau wrote: > Hi > > On Wed, Feb 20, 2019 at 2:03 AM Philippe Mathieu-Daudé > wrote: >> >> The backend should not return a negative length to read. >> We will later change the prototype of IOCanReadHandler to return an >> unsigned length. Meanwhile make sure the

Re: [Xen-devel] [PATCH v3 11/25] xen: Let xencons_send() take a 'size' argument

On Wed, Feb 20, 2019 at 2:05 AM Philippe Mathieu-Daudé wrote: > > The single caller of xencons_send(), con_event() already use the > difference 'con->buffer.size - con->buffer.consumed'. > Deduplicate by passing the difference as an argument. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-b

Re: [Xen-devel] [PATCH v3 09/25] vhost-user: Express sizeof with size_t

On Wed, Feb 20, 2019 at 2:05 AM Philippe Mathieu-Daudé wrote: > > VHOST_USER_HDR_SIZE uses offsetof(), thus is an expression of type > size_t. Update the format string accordingly. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Marc-André Lureau > --- > hw/virtio/vhost-user.c | 14 +++

Re: [Xen-devel] [PATCH v3 07/25] gdbstub: Let put_buffer() use size_t

On Wed, Feb 20, 2019 at 2:04 AM Philippe Mathieu-Daudé wrote: > > All callers provide a size_t argument, we can safely use size_t > for this function. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Marc-André Lureau > --- > gdbstub.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 dele

Re: [Xen-devel] [PATCH v3 06/25] gdbstub: Use size_t to hold GDBState::last_packet_len

On Wed, Feb 20, 2019 at 2:04 AM Philippe Mathieu-Daudé wrote: > > In put_packet_binary() we have: > > uint8_t *p; > for(;;) { > p = s->last_packet; > *(p++) = ... > s->last_packet_len = p - s->last_packet; > put_buffer(s, (uint8_t *)s->last_packet, s->last_p

Re: [Xen-devel] [PATCH v3 05/25] gdbstub: Use size_t for strlen() return value

On Wed, Feb 20, 2019 at 2:04 AM Philippe Mathieu-Daudé wrote: > > Since strlen() returns an unsigned value, it is pointless to > convert it to a signed one. Use size_t to hold its return value. > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Marc-André Lureau (it looks like the variable

Re: [Xen-devel] [PATCH v3 00/25] chardev: Convert qemu_chr_write() to take a size_t argument

On Wed, 20 Feb 2019 11:53:42 +0100 Marc-André Lureau wrote: > Hi > > On Wed, Feb 20, 2019 at 2:02 AM Philippe Mathieu-Daudé > wrote: > > > > Hi, > > > > This series convert the chardev::qemu_chr_write() to take unsigned > > length argument. To do so I went through all caller and checked if > >

Re: [Xen-devel] [PATCH v3 00/25] chardev: Convert qemu_chr_write() to take a size_t argument

Hi On Wed, Feb 20, 2019 at 2:02 AM Philippe Mathieu-Daudé wrote: > > Hi, > > This series convert the chardev::qemu_chr_write() to take unsigned > length argument. To do so I went through all caller and checked if > there are no negative value possible. Changing signedness is problematic and can

Re: [Xen-devel] [PATCH v3 21/25] s390x/sclp: Use size_t in process_mdb()

On Wed, 20 Feb 2019 02:02:28 +0100 Philippe Mathieu-Daudé wrote: > Since it is unlikely we have sizeof(mdbo->mto.message) < 0, > we can convert this variable to an unsigned type. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/char/sclpconsole-lm.c | 3 ++- > 1 file changed, 2 insertions(

Re: [Xen-devel] [PATCH v3 22/25] s390x/sclp: Let write_console_data() take a size_t

On Wed, 20 Feb 2019 02:02:29 +0100 Philippe Mathieu-Daudé wrote: > Since all callers provide an unsigned value, we can safely > use a size_t argument. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/char/sclpconsole-lm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by

Re: [Xen-devel] [PATCH v3 20/25] s390x/sclp: Use a const variable to improve readability

On Wed, 20 Feb 2019 02:02:27 +0100 Philippe Mathieu-Daudé wrote: > We will reuse this variable in the next patch. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/char/sclpconsole-lm.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/hw/char/sclpconsole-lm.c

Re: [Xen-devel] [Qemu-devel] [PATCH v3 25/25] chardev: Let qemu_chr_write[_all] use size_t

Hi On Wed, Feb 20, 2019 at 11:39 AM Daniel P. Berrangé wrote: > > On Wed, Feb 20, 2019 at 02:02:32AM +0100, Philippe Mathieu-Daudé wrote: > > > diff --git a/include/chardev/char.h b/include/chardev/char.h > > index 0341dd1ba2..2e3b5a15ca 100644 > > --- a/include/chardev/char.h > > +++ b/include/c

Re: [Xen-devel] [PATCH v3 04/25] chardev: Let qemu_chr_be_can_write() return a size_t types

Hi On Wed, Feb 20, 2019 at 2:04 AM Philippe Mathieu-Daudé wrote: > > In the previous commit we added an assert to be sure than > qemu_chr_be_can_write() will never return a negative value. > We can now change its prototype to return a size_t. > Adapt the backends accordingly. Each variable you c

Re: [Xen-devel] [Qemu-devel] [PATCH v3 25/25] chardev: Let qemu_chr_write[_all] use size_t

On Wed, Feb 20, 2019 at 02:02:32AM +0100, Philippe Mathieu-Daudé wrote: > diff --git a/include/chardev/char.h b/include/chardev/char.h > index 0341dd1ba2..2e3b5a15ca 100644 > --- a/include/chardev/char.h > +++ b/include/chardev/char.h > @@ -221,7 +221,7 @@ void qemu_chr_set_feature(Chardev *chr, >

Re: [Xen-devel] [PATCH v3 03/25] chardev/wctablet: Use unsigned type to hold unsigned value

Hi On Wed, Feb 20, 2019 at 2:03 AM Philippe Mathieu-Daudé wrote: > > TabletChardev::query is an array of uint8_t. > Use the same type to hold it (this also silent a -Wsign-conversion > warning in the trace function). > > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Marc-André Lureau > -

  1   2   >