flight 130646 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130646/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Mon, Nov 19, 2018 at 11:15:15PM +0530, Souptick Joarder wrote:
> On Mon, Nov 19, 2018 at 9:56 PM Mike Rapoport wrote:
> >
> > On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote:
> > > Hi Mike,
> > >
> > > On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox
> > > wrote:
> > > >
> > >
On Thu, Nov 22, 2018 at 06:05:26PM +, Russell King - ARM Linux wrote:
> An alternative idea would be to migrate away from the
> dma_map_single() and dma_map_page() interfaces that return a
> dma_addr_t, and instead have them return an error code or zero
> on success.
See here for a proposal:
On Thu, Nov 22, 2018 at 09:55:25AM -0800, Linus Torvalds wrote:
> No, the big immediate benefit of allowing "return -EINVAL" etc is
> simply legibility and error avoidance.
Well, I can tweak the last patch to return -EINVAL from dma_mapping_error
instead of the old 1 is as bool true. The callers
flight 130708 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130708/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
On 2018-10-22 1:23 p.m., Arun KS wrote:
> Remove managed_page_count_lock spinlock and instead use atomic
> variables.
>
> Suggested-by: Michal Hocko
> Suggested-by: Vlastimil Babka
> Signed-off-by: Arun KS
Acked-by: Felix Kuehling
Regards,
Felix
>
> ---
> As discussed here,
> https://patch
On Thu, Nov 22, 2018 at 03:18:05PM +0100, Roger Pau Monné wrote:
> On Thu, Nov 22, 2018 at 08:11:20AM -0500, Zhao Yan wrote:
> > On Thu, Oct 18, 2018 at 03:56:36PM +0100, Roger Pau Monné wrote:
> > > On Thu, Oct 18, 2018 at 08:22:41AM +, Zhao, Yan Y wrote:
> > > > Hi
> > > > The background for
Hello,
In case of Ethernet a bridge interface is created between Dom0 and DomU, so
that DomU has the internet access bridge interface. We have only wireless
chip in our board and how to create interface in case of wireless?
Bridging doesn't work in case of wireless network. If we want use NAT, the
flight 130644 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
flight 130703 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 21, 2018 9:21 PM
>
> Seemingly, a majority of users either override the helpers anyway, or have
> an
> gfn_t in their hands.
>
> Update the API, and adjust all users to match.
>
> Doing this highlighted a gaping
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, November 15, 2018 11:31 PM
>
> On 15/11/2018 15:28, Sergey Dyasli wrote:
> > On 15/11/2018 13:52, Andrew Cooper wrote:
> >> This ends up corrupting L1's view of RFLAGS by setting ZF. The correct
> value
> >> is established
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, November 15, 2018 9:53 PM
>
> * Don't assume that decode_vmx_inst() always returns
> X86EMUL_EXCEPTION.
> * The okay boolean is never written, making the else case dead.
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, November 15, 2018 9:53 PM
>
> The referenced addresses also need checking against MAXPHYSADDR.
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
___
Xen-devel mailing list
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, November 15, 2018 9:53 PM
>
> These have been obsolete since c/s 053ae230 "x86/vvmx: Remove enum
> vmx_regs_enc".
>
> Signed-off-by: Andrew Cooper
Acked-by: Kevin Tian
___
Xen
flight 130645 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130645/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 130700 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130700/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
flight 130695 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130695/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
flight 130636 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130636/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
Hi Matthew,
Sorry for the late answer and thank you for testing the patch.
On 11/13/18 10:43 PM, Matthew Daley wrote:
On Tue, 13 Nov 2018 at 02:01, Julien Grall wrote:
On 11/11/18 1:15 AM, Matthew Daley wrote:
I gave this a go but unfortunately the same problem occurs (error
-9s). Just to ch
Please ignore this one. I used the wrong e-mail address.
Sorry for the noise.
On 11/22/18 8:46 PM, Julien Grall wrote:
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make be
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires to switch
between two sets of page-table. This is not entirely trivial to fix as
it would require us to g
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires to switch
between two sets of page-table. This is not entirely trivial to fix as
it would require us to g
On Thu, Nov 22, 2018 at 5:15 AM Razvan Cojocaru
wrote:
>
> On 11/21/18 2:09 PM, Razvan Cojocaru wrote:
> > Minor improvement; simply improving code quality by using consts
> > wherever reasonable.
> >
> > Suggested-by: Jan Beulich
> > Signed-off-by: Razvan Cojocaru
>
> Tamas, I think we need you
flight 130623 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130623/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On Mon, Nov 12, 2018 at 04:49:24PM +, Anthony PERARD wrote:
(...)
> +/* QMP FD callbacks */
> +
> +static void qmp_ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev_fd,
> + int fd, short events, short revents)
> +{
> +EGC_GC;
> +int rc;
> +libxl__json_ob
On 11/22/18 7:08 PM, Roger Pau Monné wrote:
> On Thu, Nov 22, 2018 at 06:52:07PM +0200, Razvan Cojocaru wrote:
>> On 11/22/18 5:37 PM, Roger Pau Monné wrote:
>>> I don't think you are supposed to try to pause other vcpus while
>>> holding a lock, as you can see it's quite likely that you will end u
Ping VT-x.
On 15/11/2018 13:52, Andrew Cooper wrote:
> All from code inspection
>
> Andrew Cooper (4):
> x86/vvmx: Drop unused CASE_{GET,SET}_REG() macros
> x86/vvmx: Correct the INVALID_PADDR checks for VMPTRLD/VMCLEAR
> x86/vvmx: Fixes to VMWRITE emulation
> x86/vvmx: Don't call vmsuccee
flight 130693 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130693/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
On Thu, Nov 22, 2018 at 09:55:25AM -0800, Linus Torvalds wrote:
> On Thu, Nov 22, 2018 at 9:52 AM Robin Murphy wrote:
> >
> > Unfortunately, with things like the top-down IOVA allocator, and 32-bit
> > systems in general, "the top 4095" values may well still be valid
> > addresses -
>
> Ugh.
>
>
On Thu, 22 Nov 2018 18:51:13 +0200
Andrii Anisov wrote:
Hi,
> On 20.11.18 20:47, Julien Grall wrote:
> >
> >
> > On 20/11/2018 18:10, Andrii Anisov wrote:
> >> Hello Julien,
> >>
> >>
> >> On 19.11.18 18:42, Julien Grall wrote:
> >>> There are no issue about processing IRQs before the sync
On 21/11/2018 13:21, Andrew Cooper wrote:
> * Use XFREE() when appropriate
> * Drop stale comments and unnecessary brackets
> * Fold asm constraints
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> ---
> xen/include/asm
On Thu, Nov 22, 2018 at 9:52 AM Robin Murphy wrote:
>
> Unfortunately, with things like the top-down IOVA allocator, and 32-bit
> systems in general, "the top 4095" values may well still be valid
> addresses -
Ugh.
> The only immediate benefit I can see is that we could distinguish cases
> like
On 22/11/2018 17:09, Linus Torvalds wrote:
On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux
wrote:
I'm afraid that won't work very well - 32 bit platforms with 64-bit
addresses (LPAE) would have dma_addr_t as a 64-bit value, which
wouldn't fit into an unsigned long.
Good point. So we
On 22/11/2018 14:51, Jan Beulich wrote:
>
>> @@ -220,12 +219,18 @@ void guest_iommu_add_ppr_log(struct domain *d, u32
>> entry[])
>> unmap_domain_page(log_base);
>>
>> guest_iommu_deliver_msi(d);
>> +
>> +out:
> Please indent by at least one blank (same further down).
I thought you've
On 11/22/18 5:04 PM, George Dunlap wrote:
On 11/22/18 4:45 PM, Julien Grall wrote:
Hi Roger,
On 11/22/18 4:39 PM, Roger Pau Monné wrote:
On Thu, Nov 22, 2018 at 04:22:34PM +, Andrew Cooper wrote:
On 22/11/2018 16:07, Roger Pau Monné wrote:
On Thu, Nov 22, 2018 at 03:23:41PM +, Andr
On 11/22/18 4:51 PM, Andrii Anisov wrote:
Hello Julien,
Hi Andrii,
On 20.11.18 20:47, Julien Grall wrote:
On 20/11/2018 18:10, Andrii Anisov wrote:
Hello Julien,
On 19.11.18 18:42, Julien Grall wrote:
There are no issue about processing IRQs before the syncs. It is the
same as if an
On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux
wrote:
>
> I'm afraid that won't work very well - 32 bit platforms with 64-bit
> addresses (LPAE) would have dma_addr_t as a 64-bit value, which
> wouldn't fit into an unsigned long.
Good point. So we'd have to have a special IS_DMA_ERR() f
On Thu, Nov 22, 2018 at 09:09:47AM -0800, Linus Torvalds wrote:
> On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux
> wrote:
> >
> > I'm afraid that won't work very well - 32 bit platforms with 64-bit
> > addresses (LPAE) would have dma_addr_t as a 64-bit value, which
> > wouldn't fit into
On Thu, Nov 22, 2018 at 06:52:07PM +0200, Razvan Cojocaru wrote:
> On 11/22/18 5:37 PM, Roger Pau Monné wrote:
> > I don't think you are supposed to try to pause other vcpus while
> > holding a lock, as you can see it's quite likely that you will end up
> > deadlocking because the vCPU you are tryi
On Thu, Nov 22, 2018 at 08:50:47AM -0800, Linus Torvalds wrote:
> On Thu, Nov 22, 2018 at 6:03 AM Christoph Hellwig wrote:
> >
> > The 0 return doesn't work for direct mappings that have ram at address
> > zero and a lot of IOMMUs that start allocating bus space from address
> > zero, so we can't
On 11/22/18 4:45 PM, Julien Grall wrote:
> Hi Roger,
>
> On 11/22/18 4:39 PM, Roger Pau Monné wrote:
>> On Thu, Nov 22, 2018 at 04:22:34PM +, Andrew Cooper wrote:
>>> On 22/11/2018 16:07, Roger Pau Monné wrote:
On Thu, Nov 22, 2018 at 03:23:41PM +, Andrew Cooper wrote:
> On 22/11/
On Thu, Nov 22, 2018 at 6:03 AM Christoph Hellwig wrote:
>
> The 0 return doesn't work for direct mappings that have ram at address
> zero and a lot of IOMMUs that start allocating bus space from address
> zero, so we can't consolidate on that, but I think we can move everyone
> to all-Fs, which t
On 11/22/18 5:37 PM, Roger Pau Monné wrote:
> I don't think you are supposed to try to pause other vcpus while
> holding a lock, as you can see it's quite likely that you will end up
> deadlocking because the vCPU you are trying to pause is stuck waiting
> on the lock that you are holding.
>
> You
Hello Julien,
On 20.11.18 20:47, Julien Grall wrote:
On 20/11/2018 18:10, Andrii Anisov wrote:
Hello Julien,
On 19.11.18 18:42, Julien Grall wrote:
There are no issue about processing IRQs before the syncs. It is the
same as if an IRQ was raised from ila different pCPUs.
So why do you nee
Hi Roger,
On 11/22/18 4:39 PM, Roger Pau Monné wrote:
On Thu, Nov 22, 2018 at 04:22:34PM +, Andrew Cooper wrote:
On 22/11/2018 16:07, Roger Pau Monné wrote:
On Thu, Nov 22, 2018 at 03:23:41PM +, Andrew Cooper wrote:
On 22/11/2018 15:20, Roger Pau Monné wrote:
On Thu, Nov 22, 2018 at
Instead of parsing the dom0_mem command line parameter as custom
parameter do that only when building dom0. This will enable a later
addition of specifying the memory size by fractions of the host memory
size, which isn't known when doing custom parameter parsing.
As this is needed later anyway mo
Setting the memory size of dom0 on a server for the non autoballooning
case requires always specification of a boot parameter today. The value
to set will depend mostly on the host memory size.
In order to support that scenario add the possibility to set dom0_mem
depending on the amount of physica
Today the memory size of dom0 can be specified only in terms of bytes
(either an absolute value or "host-mem - value"). When dom0 shouldn't
be auto-ballooned this requires nearly always a manual adaption of the
Xen boot parameters to reflect the actual host memory size.
Add more possibilities to s
With being able to specify a dom0_mem value depending on host memory
size make it easy for distros to specify a default dom0 size by adding
a CONFIG_DOM0_MEM item which presets the dom0_mem boot parameter value.
Signed-off-by: Juergen Gross
---
xen/arch/x86/Kconfig | 9 +
xen/arch/x
On Thu, Nov 22, 2018 at 04:22:34PM +, Andrew Cooper wrote:
> On 22/11/2018 16:07, Roger Pau Monné wrote:
> > On Thu, Nov 22, 2018 at 03:23:41PM +, Andrew Cooper wrote:
> >> On 22/11/2018 15:20, Roger Pau Monné wrote:
> >>> On Thu, Nov 22, 2018 at 02:03:55PM +, Julien Grall wrote:
>
On Wed, 21 Nov 2018 15:42:11 +0100
Samuel Ortiz wrote:
> Hi Igor,
>
> On Thu, Nov 08, 2018 at 03:16:23PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:28 +0100
> > Samuel Ortiz wrote:
> >
> > > XSDT is the 64-bit version of the legacy ACPI RSDT (Root System
> > > Description Tabl
On 22/11/2018 16:07, Roger Pau Monné wrote:
> On Thu, Nov 22, 2018 at 03:23:41PM +, Andrew Cooper wrote:
>> On 22/11/2018 15:20, Roger Pau Monné wrote:
>>> On Thu, Nov 22, 2018 at 02:03:55PM +, Julien Grall wrote:
Hi Jan,
On 11/22/18 1:36 PM, Jan Beulich wrote:
On 22
On Thu, Nov 22, 2018 at 09:12:44AM -0700, Jan Beulich wrote:
> >>> On 22.11.18 at 16:30, wrote:
> > On Thu, Nov 22, 2018 at 03:47:41AM -0700, Jan Beulich wrote:
> >> --- a/xen/arch/arm/Makefile
> >> +++ b/xen/arch/arm/Makefile
> >> @@ -100,9 +100,6 @@ prelink.o: $(ALL_OBJS)
> >>$(LD) $(LDFLAGS
>>> On 22.11.18 at 16:30, wrote:
> On Thu, Nov 22, 2018 at 03:47:41AM -0700, Jan Beulich wrote:
>> --- a/xen/arch/arm/Makefile
>> +++ b/xen/arch/arm/Makefile
>> @@ -100,9 +100,6 @@ prelink.o: $(ALL_OBJS)
>> $(LD) $(LDFLAGS) -r -o $@ $^
>> endif
>>
>> -$(BASEDIR)/common/symbols-dummy.o:
>>
On Thu, Nov 22, 2018 at 03:23:41PM +, Andrew Cooper wrote:
> On 22/11/2018 15:20, Roger Pau Monné wrote:
> > On Thu, Nov 22, 2018 at 02:03:55PM +, Julien Grall wrote:
> >> Hi Jan,
> >>
> >> On 11/22/18 1:36 PM, Jan Beulich wrote:
> >> On 22.11.18 at 14:31, wrote:
> I think Julien'
>>> On 21.11.18 at 14:21, wrote:
> * Use XFREE() when appropriate
> * Drop stale comments and unnecessary brackets
> * Fold asm constraints
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel maili
On 22/11/2018 15:44, Jan Beulich wrote:
On 21.11.18 at 14:21, wrote:
>> Seemingly, a majority of users either override the helpers anyway, or have an
>> mfn_t in their hands.
>>
>> Update the API, and adjust all users to match. In some places, use the
>> unsigned long variant in places where
Wei Liu (2):
automation: add a qemu smoke test for clang build
automation: break .gitlab-yaml into smaller files
.gitlab-ci.yml | 400 +---
automation/gitlab-ci/build.yaml | 379 +
automation/gitlab-ci/te
Anthony PERARD writes ("Re: [PATCH v6 08/11] libxl: QEMU startup sync based on
QMP"):
> On Wed, Nov 21, 2018 at 04:49:06PM +, Anthony PERARD wrote:
> > I wounder what to do for this.
> > Maybe invent a JSON macro which would be:
> > JSON(o) (libxl__json_object_to_json(gc, (o)) : ? "\"null\
Also rename the old test to have -gcc suffix.
Signed-off-by: Wei Liu
---
This can only apply after Roger's patch to fix clang has been applied.
---
.gitlab-ci.yml | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index b3ca779
>>> On 21.11.18 at 14:21, wrote:
> * Reflow some lines to remove unnecessary line breaks.
> * Factor out the gnttab_get_frame_gfn() calculation. Neither x86 nor ARM
>builds seem to be able to fold the two calls, and the resulting code is far
>easier to follow.
>
> Signed-off-by: Andrew
Break out files for build jobs and test jobs. Keep the top level
.gitlab-ci.yaml small.
Signed-off-by: Wei Liu
---
.gitlab-ci.yml | 417 +---
automation/gitlab-ci/build.yaml | 379
automation/gitlab-ci/test
>>> On 21.11.18 at 14:21, wrote:
> share_xen_page_with_guest() is a common API. Use it directly rather than
> wrapping it with unnecessary boilerplate.
I was wondering a couple of times whether we should undo this "abstraction".
I simply wasn't sure why this had been introduced in the first plac
On Thu, 22 Nov 2018 11:02:30 +0100,
Oleksandr Andrushchenko wrote:
>
> @@ -214,12 +221,19 @@ static void stream_clear(struct
> xen_snd_front_pcm_stream_info *stream)
> stream->out_frames = 0;
> atomic_set(&stream->hw_ptr, 0);
> xen_snd_front_evtchnl_pair_clear(stream->evt_pair);
>>> On 21.11.18 at 14:21, wrote:
> Seemingly, a majority of users either override the helpers anyway, or have an
> mfn_t in their hands.
>
> Update the API, and adjust all users to match. In some places, use the
> unsigned long variant in places where we are interacting with an external
> struct
On Thu, Nov 22, 2018 at 05:25:02PM +0200, Razvan Cojocaru wrote:
> On 11/22/18 4:49 PM, Roger Pau Monné wrote:
> > On Thu, Nov 22, 2018 at 02:48:07PM +0200, Razvan Cojocaru wrote:
> >> On 11/22/18 12:58 PM, Roger Pau Monné wrote:
> >>> On Thu, Nov 22, 2018 at 12:14:59PM +0200, Razvan Cojocaru wrote
>>> On 21.11.18 at 14:21, wrote:
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -512,7 +512,7 @@ int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct
> domain *d,
> * XXX following situation missed:
> * PoD, Foreign mapped, Granted, Shared
> */
> -int u
On Thu, Nov 22, 2018 at 03:47:41AM -0700, Jan Beulich wrote:
> The per-arch top level make files don't record any dependencies for the
> file, so its mere existence is enough for make to consider it up-to-
> date. As of ab3e5f5ff9 ("xsplice, symbols: Implement fast symbol names
> -> virtual address
flight 130690 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130690/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
On 11/22/18 4:49 PM, Roger Pau Monné wrote:
> On Thu, Nov 22, 2018 at 02:48:07PM +0200, Razvan Cojocaru wrote:
>> On 11/22/18 12:58 PM, Roger Pau Monné wrote:
>>> On Thu, Nov 22, 2018 at 12:14:59PM +0200, Razvan Cojocaru wrote:
On 11/22/18 12:05 PM, Roger Pau Monné wrote:
> On Wed, Nov 21,
On 22/11/2018 15:20, Roger Pau Monné wrote:
> On Thu, Nov 22, 2018 at 02:03:55PM +, Julien Grall wrote:
>> Hi Jan,
>>
>> On 11/22/18 1:36 PM, Jan Beulich wrote:
>> On 22.11.18 at 14:31, wrote:
I think Julien's point is that without explicitly barriers, CPU0's
update to system_sta
On Thu, Nov 22, 2018 at 02:03:55PM +, Julien Grall wrote:
> Hi Jan,
>
> On 11/22/18 1:36 PM, Jan Beulich wrote:
> > > > > On 22.11.18 at 14:31, wrote:
> > > I think Julien's point is that without explicitly barriers, CPU0's
> > > update to system_state may not be visible on CPU1, even though
>>> On 21.11.18 at 14:21, wrote:
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -901,8 +901,8 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
> shr_handle_t sh,
> struct two_gfns tg;
> struct rmap_iterator ri;
>
> -get_two_gfns(sd, gfn_x(
>>> On 21.11.18 at 14:21, wrote:
> On x86, get_gfn_*() and put_gfn() are reference counting pairs. All the
> get_gfn_*() functions are called from within CONFIG_X86 sections, but
> put_gfn() is stubbed out on ARM.
>
> As a result, the common code reads as if ARM is dropping references it never
>
On Wed, 21 Nov 2018 15:42:37 +0100
Samuel Ortiz wrote:
> Hi Igor,
>
> On Fri, Nov 09, 2018 at 03:23:16PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:24 +0100
> > Samuel Ortiz wrote:
> >
> > > ACPI tables are platform and machine type and even architecture
> > > agnostic, and as
>>> On 21.11.18 at 14:21, wrote:
> @@ -776,7 +776,7 @@ guest_physmap_add_entry(struct domain *d, gfn_t gfn,
> mfn_t mfn,
>&a, 0, NULL, NULL);
> if ( p2m_is_shared(ot) )
> {
> -/* Do an unshare to cleanly take care of all corner
> +
>>> On 21.11.18 at 14:21, wrote:
> Drop the ap2m_active boolean, and consistently use the unlocking form:
>
> if ( p2m != hostp2m )
>__put_gfn(p2m, gfn);
> __put_gfn(hostp2m, gfn);
>
> which makes it clear that we always unlock the altp2m's gfn if it is in use,
> and always unlock th
>>> On 21.11.18 at 14:21, wrote:
> The final parameter to p2m_altp2m_lazy_copy() appears to be unnecessary, and
> results in very hard-to-follow code. Have the sole caller set its local p2m
> pointer appropriately, and drop the parameter.
>
> With that done, a level of indirection of ap2m can be
>>> On 21.11.18 at 14:21, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -2184,24 +2184,29 @@ bool_t p2m_altp2m_lazy_copy(struct vcpu *v, paddr_t
> gpa,
> unsigned long mask;
> mfn_t mfn;
> int rv;
> +bool ret;
>
> *ap2m = p2m_get_altp2m(v);
>
On Thu, Nov 22, 2018 at 12:23:22PM +, Andrew Cooper wrote:
> On 22/11/2018 12:03, Roger Pau Monne wrote:
> > LLVM code generation can attempt to perform a load from a variable in
> > the next condition of an expression under certain circumstances, thus
> > turning the following condition:
> >
>
>>> On 21.11.18 at 14:21, wrote:
> Most of these issues would be XSAs if these paths were accessible to guests.
>
> First, override the {get,put}_gfn() helpers to use gfn_t, which was the
> original purpose of this patch.
>
> guest_iommu_get_table_mfn() has two bugs. First, it gets a ref on one
Hi,
Please provide a cover letter when you send multiple patches together.
On 11/16/18 4:24 PM, Andrii Anisov wrote:
From: Andrii Anisov
Signed-off-by: Andrii Anisov
Acked-by: Julien Grall
---
xen/arch/arm/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/
On Thu, Nov 22, 2018 at 02:48:07PM +0200, Razvan Cojocaru wrote:
> On 11/22/18 12:58 PM, Roger Pau Monné wrote:
> > On Thu, Nov 22, 2018 at 12:14:59PM +0200, Razvan Cojocaru wrote:
> >> On 11/22/18 12:05 PM, Roger Pau Monné wrote:
> >>> On Wed, Nov 21, 2018 at 08:55:48PM +0200, Razvan Cojocaru wrot
>>> On 21.11.18 at 14:21, wrote:
> get_gfn_query() internally takes the p2m lock, and this error path leaves it
> locked.
>
> This wasn't included in XSA-277 because the error path can only be triggered
> by a carefully timed phymap operation concurrent with the domain being paused
> and the tool
>>> On 21.11.18 at 14:21, wrote:
> get_gfn_type_access() internally takes the p2m lock, and nothing ever unlocks
> it. Switch to using the unlocked accessor instead.
>
> This wasn't included in XSA-277 because neither mem-sharing nor altp2m are
> supported.
>
> Signed-off-by: Andrew Cooper
Sa
>>> On 20.11.18 at 15:37, wrote:
> The final remnanat of PVRDTSCP is that we would emulate RDTSCP even on
> hardware which lacked the instruction. RDTSCP is available on almost all
> 64-bit x86 hardware.
>
> Remove this emulation, drop the TSC_MODE_PVRDTSCP constant, and allow RDTSCP
> in a PV g
On Wed, Nov 21, 2018 at 04:49:06PM +, Anthony PERARD wrote:
> On Fri, Nov 16, 2018 at 12:14:43PM +, Ian Jackson wrote:
> > Anthony PERARD writes ("[PATCH v6 08/11] libxl: QEMU startup sync based on
> > QMP"):
> > > +LOGD(DEBUG, ev->domid, ".. instead, got: %s",
> > > +
Hi Andrew,
On 11/21/18 1:21 PM, Andrew Cooper wrote:
* Reflow some lines to remove unnecessary line breaks.
* Factor out the gnttab_get_frame_gfn() calculation. Neither x86 nor ARM
builds seem to be able to fold the two calls, and the resulting code is far
easier to follow.
Signed-
Hi Andrew,
On 11/21/18 1:21 PM, Andrew Cooper wrote:
share_xen_page_with_guest() is a common API. Use it directly rather than
wrapping it with unnecessary boilerplate.
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
Cheers,
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC:
On Thu, Nov 22, 2018 at 12:02:29PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Use page directory based shared buffer implementation
> now available as common code for Xen frontend drivers.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/Kco
Hi Andrew,
On 11/21/18 1:21 PM, Andrew Cooper wrote:
Seemingly, a majority of users either override the helpers anyway, or have an
mfn_t in their hands.
Update the API, and adjust all users to match. In some places, use the
unsigned long variant in places where we are interacting with an exter
>>> On 22.11.18 at 14:58, wrote:
> On 22/11/2018 13:19, Jan Beulich wrote:
> On 22.11.18 at 13:38, wrote:
>>> On 22/11/2018 08:57, Jan Beulich wrote:
>>> On 21.11.18 at 20:37, wrote:
> @@ -79,31 +72,27 @@ static always_inline unsigned long __cmpxchg(
> switch ( size )
Hi,
On 10/8/18 7:33 PM, Julien Grall wrote:
Julien Grall (16):
xen/arm: Introduce helpers to get/set an MFN from/to an LPAE entry
xen/arm: Allow lpae_is_{table, mapping} helpers to work on invalid
entry
xen/arm: guest_walk_tables: Switch the return to bool
xen/arm: p2m: Introduc
On Thu, Nov 22, 2018 at 01:40:23PM +0200, Razvan Cojocaru wrote:
> Signed-off-by: Razvan Cojocaru
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Thu, Nov 22, 2018 at 08:11:20AM -0500, Zhao Yan wrote:
> On Thu, Oct 18, 2018 at 03:56:36PM +0100, Roger Pau Monné wrote:
> > On Thu, Oct 18, 2018 at 08:22:41AM +, Zhao, Yan Y wrote:
> > > Hi
> > > The background for this patch is that: for some pci device, even it's
> > > PCI_INTERRUPT_PIN
Hi Andrew,
On 11/21/18 1:21 PM, Andrew Cooper wrote:
On x86, get_gfn_*() and put_gfn() are reference counting pairs. All the
get_gfn_*() functions are called from within CONFIG_X86 sections, but
put_gfn() is stubbed out on ARM.
As a result, the common code reads as if ARM is dropping reference
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 7 +++
drivers/iommu/dma-iommu.c | 23 ---
include/linux/dma-iommu.h | 1 -
3 files c
Return DMA_MAPPING_ERROR instead of 0 on a dma mapping failure and let
the core dma-mapping code handle the rest.
Note that the existing code used AMD_IOMMU_MAPPING_ERROR to check from
a 0 return from the IOVA allocator, which is replaced with an explicit
0 as in the implementation and other users
No users left except for vmd which just forwards it. Also switch
dma_mapping_error to an explicit bool return value.
Signed-off-by: Christoph Hellwig
---
drivers/pci/controller/vmd.c | 6 --
include/linux/dma-mapping.h | 13 ++---
2 files changed, 2 insertions(+), 17 deletions(-)
1 - 100 of 186 matches
Mail list logo
