On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote:
> On 3/14/19 4:47 PM, Boris Ostrovsky wrote:
>> On 3/14/19 9:17 AM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Currently on driver resume we remove all the network queues and
&g
On 3/12/19 1:24 PM, Andrew Cooper wrote:
> On 12/03/2019 17:18, David Hildenbrand wrote:
>> On 12.03.19 18:14, Matthew Wilcox wrote:
>>> On Tue, Mar 12, 2019 at 05:05:39PM +, Julien Grall wrote:
On 3/12/19 3:59 PM, Julien Grall wrote:
> It looks like all the arm test for linus [1] and
or p2mt as well.
>>
>> Reported-by: Andrew Cooper
>> Signed-off-by: Jan Beulich
> Reviewed-by: Wei Liu
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
gt; + return false;
> if (same_page && (vec_end_addr & PAGE_MASK) != page_addr)
> return false;
>
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
rovsky
> Cc: Juergen Gross
> Cc: xen-devel@lists.xenproject.org
> Cc: Omar Sandoval
> Cc: Christoph Hellwig
> Signed-off-by: Ming Lei
Reviewed-by: Boris Ostrovsky
^^
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 3/5/19 8:30 AM, Arnd Bergmann wrote:
>
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index b24ddac1604b..290b6aca7e1d 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -723,26 +723,6 @@ static long privcmd_ioctl_restrict(struct file *file,
> void __user
On 3/4/19 3:47 PM, Arnd Bergmann wrote:
> Building the privcmd code as a loadable module on ARM, we get
> a link error due to the private cache management functions:
>
> ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
Can __sync_icache_dcache be exported in arm32, just like
On 2/28/19 2:45 PM, Andrew Morton wrote:
> On Wed, 27 Feb 2019 13:32:14 +0800 Dave Young wrote:
>
>> This series have been in -next for some days, could we get this in
>> mainline?
> It's been in -next for two months?
>
>> Andrew, do you have plan about them, maybe next release?
> They're all
On 2/25/19 10:26 AM, Jan Beulich wrote:
On 25.02.19 at 15:11, wrote:
>> On 25/02/2019 13:11, Jan Beulich wrote:
>>> For Intel, afaics, we indeed produce a blank CPUID leaf in
>>> all cases, so the behavior looks reasonably consistent. I would
>>> question though whether a blank CPUID leaf /
On 2/22/19 5:44 PM, Andrew Cooper wrote:
> On 22/02/2019 21:58, Boris Ostrovsky wrote:
>> On 2/22/19 4:13 PM, Andrew Cooper wrote:
>>> vPMU isn't security supported, and in general guests can't access any of the
>>> performance counter MSRs. However, the RDPMC in
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Jun Nakajima
> CC: Kevin Tian
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Brian Woods
> CC: Juergen Gross
>
> This should be taken in
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 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 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
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).
>
> After some investigation, this is because the irq handler will now be
>
On 2/15/19 10:07 AM, Oleksandr Andrushchenko wrote:
> On 2/15/19 5:03 PM, Boris Ostrovsky wrote:
>> On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
>>> /* DMA buffer export support. */
>>> @@ -311,6 +317,7 @@ static void dmabuf_ex
On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Check if there are any imported dma-bufs left not released by
> user-space when grant device's release callback is called and
> free those if this is the case. This can happen if user-space
> leaks the buffers
On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
>
> /* DMA buffer export support. */
> @@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref)
>
> dmabuf_exp_wait_obj_signal(gntdev_dmabuf->priv, gntdev_dmabuf);
> list_del(_dmabuf->next);
> +
_mapping_init+0xf5/0x1d4
> [ 584.695682] [] init_memory_mapping+0x18d/0x380
> [ 584.702631] [] arch_add_memory+0x59/0xf0
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Tue, Feb 12, 2019 at 02:37:20PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warning:
>
> drivers/xen/xen-pciback/xenbus.c: In function
t; Norbert Manthey, as the first call now also needs to update the local
> variable "p2mt".
>
> Do a few cosmetics at the same time: Move a comment up a little, drop
> the pointless "case 0" (seeing in particular the comment's wording),
> and correct formatting
, and update the
> trace record independenly.
>
> Fixes: 9a779e4f (Implement SVM specific part for Nested Virtualization)
>
> Signed-off-by: Norbert Manthey
Reviewed-by: Boris Ostrovsky
>
> ---
>
> Notes:
> v2: keep type, use local variable in function call and
&g
On 2/5/19 4:33 AM, Jan Beulich wrote:
>
> SVM maintainers / George: I find it odd that there are two calls
> to __get_gfn_type_access() here. Doesn't this bear the risk of
> the trace record not reflecting what has actually happened (i.e.
> what has lead to the domain crash)? Perhaps the better
On 1/30/19 3:22 AM, Juergen Gross wrote:
> Don't allow memory to be added above the allowed maximum allocation
> limit set by Xen.
>
> Trying to do so would result in cases like the following:
>
> [ 584.559652] [ cut here ]
> [ 584.564897] WARNING: CPU: 2 PID: 1 at
On 1/28/19 3:29 AM, Oleksandr Andrushchenko wrote:
> +Boris and Juergen who can also help getting it in
I can put this in but I'd like to have Stefano's ack, this being ARM.
-boris
>
> On 1/28/19 8:34 AM, Souptick Joarder wrote:
>> On Mon, Jan 14, 2019 at 4:08 PM Oleksandr Andrushchenko
>>
On 1/16/19 10:29 AM, Juergen Gross wrote:
> On 16/01/2019 16:07, Boris Ostrovsky wrote:
>> On 1/16/19 9:33 AM, Juergen Gross wrote:
>>> On 16/01/2019 14:17, Boris Ostrovsky wrote:
>>>> On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote:
>>&
On 1/16/19 9:33 AM, Juergen Gross wrote:
> On 16/01/2019 14:17, Boris Ostrovsky wrote:
>> On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote:
>>
>>> @@ -1650,13 +1650,14 @@ void xen_callback_vector(void)
>>>
On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote:
> @@ -1650,13 +1650,14 @@ void xen_callback_vector(void)
> xen_have_vector_callback = 0;
> return;
> }
> - pr_info("Xen HVM callback vector for event
On 1/15/19 4:06 PM, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 786e1048e7f4 ("pvcalls-front: fix potential null dereference")
>
> has a malformed Fixes tag:
>
> Fixes: 9f51c05dc41a ("pvcalls-front: Avoid get_free_pages(GFP_KERNEL)
> under spinlock")
>
> It should not be split over 2
free_active_ring(map);
> ^^^
> Add null check on map->active.ring before dereferencing it to avoid
> any NULL pointer dereferences.
>
> Fixes: 9f51c05dc41a ("pvcalls-front: Avoid get_free_pages(GFP_KERNEL)
> under spinlock")
> Reported-by:
On 1/14/19 11:49 PM, Souptick Joarder wrote:
> On Tue, Jan 15, 2019 at 4:58 AM Boris Ostrovsky
> wrote:
>> On 1/11/19 10:12 AM, Souptick Joarder wrote:
>>> Convert to use vm_insert_range() to map range of kernel
>>> memory to user vma.
>>>
>>&
On 1/14/19 10:48 AM, wangbo wrote:
> Create_active may called inside spinlock,replace GFP_KERNEL with GFP_ATOMIC
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.21=9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19
is queued and addresses this problem.
(Please run
if (ret)
> - break;
> - }
> + ret = vm_insert_range_buggy(vma, vma_priv->pages,
> + vma_priv->n_pages);
This can use the non-buggy version. But since the orig
On 1/11/19 10:12 AM, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
Reviewed-by: Boris Ostrovsky
(although it would be good to mention in the commit that you are also
replacing count with v
On 1/14/19 7:43 AM, Igor Druzhinin wrote:
> ping?
Applied to for-linus-4.21 (nka 5.0)
(this should have been copied to linux-ker...@vger.kernel.org and to me,
which is partly the reason why it was missed)
-boris
>
> On 10/12/2018 10:03, Xin Li wrote:
>> From: Talons Lee
>>
>> Commit e657fcc
_active_ring(map);
> ^^^
> Replace map->active.ring->ring_order with PVCALLS_RING_ORDER
> to avoid potential null dereference.
>
> Fixes: 9f51c05dc41a ("pvcalls-front: Avoid get_free_pages(GFP_KERNEL)
> under spinlock")
> Repo
table'
> sched_clock() interface")
> Cc: # 4.11
> Reported-by: Hans van Kranenburg
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
_INTR_INFO) ->
> hvm_vm_event_do_resume() -> hvm_emulate_one_vm_event()
> (possibly overwriting the VM_ENTRY_INTR_INFO value).
>
> This patch may also be helpful for the future removal
> of may_defer in hvm_set_cr{0,3,4} and hvm_set_msr().
>
&
On 1/11/19 7:08 AM, Juergen Gross wrote:
> @@ -421,6 +424,11 @@ void xen_restore_time_memory_area(void)
> if (ret != 0)
> pr_notice("Cannot restore secondary vcpu_time_info (err %d)",
> ret);
> +
> +out:
> + /* Need pvclock_resume() before using
On 1/10/19 12:17 PM, Boris Ostrovsky wrote:
> On 1/10/19 11:14 AM, Juergen Gross wrote:
>> On 10/01/2019 16:34, Boris Ostrovsky wrote:
>>> On 1/10/19 5:07 AM, Juergen Gross wrote:
>>>>
>>>> +void xen_clocksource_suspend(void)
>>>> +
On 1/10/19 11:14 AM, Juergen Gross wrote:
> On 10/01/2019 16:34, Boris Ostrovsky wrote:
>> On 1/10/19 5:07 AM, Juergen Gross wrote:
>>>
>>> +void xen_clocksource_suspend(void)
>>> +{
>>> + xen_clock_value_saved = xen_clocksource_read() - xen_sc
On 1/10/19 5:07 AM, Juergen Gross wrote:
>
> +void xen_clocksource_suspend(void)
> +{
> + xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
xen_clock_value_saved = xen_sched_clock() maybe?
-boris
___
Xen-devel mailing
On 1/9/19 6:53 AM, Stefano Garzarella wrote:
> Hi Liam,
>
> On Tue, Jan 8, 2019 at 3:47 PM Liam Merwick wrote:
>> QEMU sets the hvm_modlist_entry in load_linux() after the call to
>> load_elfboot() and then qboot loads it in boot_pvh_from_fw_cfg()
>>
>> But the current PVH patches don't handle
gt; It not used since e6587cdbd732 ("pvcalls-back: set -ENOTCONN in
> pvcalls_conn_back_read")
>
> Signed-off-by: YueHaibing
Reviewed-by: Boris Ostrovsky
and applied to for-linus-4.21.
Thanks.
-boris
___
Xen-devel mailing l
On 1/3/19 12:45 PM, Roger Pau Monné wrote:
> Hello,
>
> While looking at some tangential issues I realized that the 'VGA Not
> Present' flag that Xen currently sets for PVH DomUs might be slightly
> different from what we expect it to mean. The purpose was that Xen
> would set this flag to denote
On 1/2/19 1:58 PM, Souptick Joarder wrote:
> On Mon, Dec 24, 2018 at 6:53 PM Souptick Joarder wrote:
>> Convert to use vm_insert_range() to map range of kernel
>> memory to user vma.
>>
>> Signed-off-by: Souptick Joarder
>> Reviewed-by: Matthew Wilcox
ont.c | 20 +---
> 2 files changed, 17 insertions(+), 10 deletions(-)
Reviewed-by: Boris Ostrovsky
Applied to for-linus-21.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 12/20/18 2:23 PM, Julien Grall wrote:
> No functional change intended.
>
> Only reasonable clean-ups are done in this patch. The rest will use _gfn
> for the time being.
>
> Signed-off-by: Julien Grall
SVM bits:
Reviewed-b
On 12/21/18 5:02 AM, Pu Wen wrote:
> On 2018/12/20 22:25, Boris Ostrovsky wrote:
> ...
>>> diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
>>> index 5efc39b..e9f0a5c 100644
>>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>>> +++ b/xen/ar
On 12/19/18 4:25 PM, Ken Pizzini wrote:
> Since 4.19.5 I have not been able to boot kernels on my Xen-hosted VM on
> a system with an Intel Xeon L5520 processor (microcode 0x1d).
>
> 4.19.4 worked fine; I've tried kernels 4.19.5, 4.19.6, 4.19.7 4.19.9, 4.19.10,
> 4.20-rc7, and they all throw:
>
On 12/20/18 8:12 AM, Pu Wen wrote:
> The PMU architecture for the Hygon Dhyana CPU is similar to the AMD
> family 17h one. To support it, add Hygon Dhyana support in the similar
> way as AMD does.
>
> Signed-off-by: Pu Wen
> ---
> xen/arch/x86/cpu/vpmu.c | 2 ++
> xen/arch/x86/cpu/vpmu_amd.c
On 12/18/18 11:15 AM, Noralf Trønnes wrote:
>
> Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:
>> From: Oleksandr Andrushchenko
>>
>> Use page directory based shared buffer implementation
>> now available as common code for Xen frontend drivers.
>>
>> Remove flushing of shared buffer on
On 12/18/18 6:28 AM, Andrew Cooper wrote:
> On 18/12/2018 10:42, YueHaibing wrote:
>> On 2018/12/18 16:31, Juergen Gross wrote:
>>> On 18/12/2018 09:19, YueHaibing wrote:
Fix smatch warning:
arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
buffer overflow
On 12/14/18 7:55 AM, Ross Lagerwall wrote:
> If pcistub_init_device fails, the release function will be called with
> dev_data set to NULL. Check it before using it to avoid a NULL pointer
> dereference.
>
> Signed-off-by: Ross Lagerwall
I think this should go to stable trees too (copying them)
On 12/10/18 10:12 AM, Andrea Righi wrote:
> Blacklist symbols in Xen probe-prohibited areas, so that user can see
> these prohibited symbols in debugfs.
>
> See also: a50480cb6d61.
>
> Signed-off-by: Andrea Righi
Applied to for-linus-4.21
-boris
On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote:
> On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
>> On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
>>> Hello, Juergen, Boris!
>>>
>>> As this DRM part of the series is the only one which needs ack/nack
&
On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
> Hello, Juergen, Boris!
>
> As this DRM part of the series is the only one which needs ack/nack
>
> (and it might take quite some time to complete) could we please
>
> merge the patches 1 and 3 now that already have ack/r-b?
>
TBH I am not
On 12/10/18 2:05 PM, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary
On 12/14/18 7:55 AM, Ross Lagerwall wrote:
> If pcistub_init_device fails, the release function will be called with
> dev_data set to NULL. Check it before using it to avoid a NULL pointer
> dereference.
>
> Signed-off-by: Ross Lagerwall
Reviewed-by:
On 12/12/18 2:26 AM, Jan Beulich wrote:
On 11.12.18 at 19:16, wrote:
>> BTW: Apart from the fact its ugly and take a lng time to complete, do you
>> have any practical isssues you want to highlight? maybe that can
>> help upstream as well.
> The situation for a kernel and a hypervisor
On 12/10/18 6:52 AM, Andrew Cooper wrote:
> The intention of this patch was to remove the calls to nsvm_{rd,wr}msr() from
> the default cases of svm_msr_{read,write}_intercept(), but it has turned into
> a more corrective patch than just code motion.
>
> First, collect the VM_CR bit definitions
On 12/7/18 6:15 PM, David Woodhouse wrote:
>
> - load_TLS_descriptor(t, cpu, 0);
> - load_TLS_descriptor(t, cpu, 1);
> - load_TLS_descriptor(t, cpu, 2);
> + load_TLS_descriptor(t, cpu, 0, flush_gs);
> + load_TLS_descriptor(t, cpu, 1, flush_gs);
> + load_TLS_descriptor(t,
On 12/7/18 5:25 AM, Borislav Petkov wrote:
> On Thu, Dec 06, 2018 at 11:14:34PM +0100, Paolo Bonzini wrote:
>>> There are some minor changes in non-xen x86 code so it would be good to
>>> get x86 maintainers' ack.
>> It's not really code, only Kconfig (and I remarked on it just now), but
>> it
On 12/6/18 5:49 PM, Paolo Bonzini wrote:
> On 06/12/18 23:34, Boris Ostrovsky wrote:
>> On 12/6/18 5:11 PM, Paolo Bonzini wrote:
>>
>>> and also
>>>
>>> depends on !EFI
>>>
>>> because even though in principle it would be possib
On 12/6/18 5:11 PM, Paolo Bonzini wrote:
> On 06/12/18 07:04, Maran Wilson wrote:
>> +config PVH
>> +bool "Support for running PVH guests"
>> +---help---
>> + This option enables the PVH entry point for guest virtual machines
>> + as specified in the x86/HVM direct boot ABI.
>> +
On 12/6/18 4:37 PM, Borislav Petkov wrote:
> On Thu, Dec 06, 2018 at 10:21:12PM +0100, Paolo Bonzini wrote:
>> Thanks! I should be able to post a Tested-by next Monday. Boris, are
>> you going to pick it up for 4.21?
> Boris me or Boris O.?
>
> :-)
>
O. ;-)
There are some minor changes in
On 12/5/18 4:32 AM, Roger Pau Monné wrote:
> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest reboot.
>> Assigning it to another guest also meets the same issue. And the only
>> way to make it work again is un-binding and
and display
> frontend drivers without functional changes with the intention
> to remove shared code from the corresponding drivers.
>
> Signed-off-by: Oleksandr Andrushchenko
Acked-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-deve
On 12/3/18 8:14 PM, Dongli Zhang wrote:
> Hi Boris,
>
> On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
>> On 12/2/18 3:31 PM, Manjunath Patil wrote:
>>> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>>>
>>>> On 11/30/18 4:49 PM, Manjunath Patil wrot
On 12/2/18 3:31 PM, Manjunath Patil wrote:
> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>
>> On 11/30/18 4:49 PM, Manjunath Patil wrote:
>>> Thank you Boris for your comments. I removed faulty email of mine.
>>>
>>> replies inline.
>>> On 11/30/
outside the lock and passing the allocated data to
> create_active().
>
> v3: Use the matching deallocators i.e., free_page()
> and free_pages(), respectively.
>
> v4: It would be better to pre-populate map (struct sock_mapping),
> rather than introducing one more new
On 11/30/18 4:49 PM, Manjunath Patil wrote:
> Thank you Boris for your comments. I removed faulty email of mine.
>
> replies inline.
> On 11/30/2018 12:42 PM, Boris Ostrovsky wrote:
>> On 11/29/18 12:17 AM, Manjunath Patil wrote:
>>> Hi,
>>> Feel free to s
On 11/29/18 12:17 AM, Manjunath Patil wrote:
> Hi,
> Feel free to suggest/comment on this.
>
> I am trying to do the following at dst during the migration now.
> 1. Dont clear the old rinfo in blkif_free(). Instead just clean it.
> 2. Store the old rinfo and nr_rings into temp variables in
outside the lock and passing the allocated data to
> create_active().
> v3: Use the matching deallocators i.e., free_page()
> and free_pages(), respectively.
>
> Suggested-by: Juergen Gross
> Signed-off-by: Wen Yang
> CC: Julia Lawall
> CC: Boris Ostrovsky
> CC:
On 11/30/18 4:46 AM, Jan Beulich wrote:
On 29.11.18 at 23:43, wrote:
>> One other comment about this patch (which IIRC was raised by Andrew on
>> an earlier version) is that it may be worth to stop timer calibration. I
>> am pretty sure we've seen deadlocks, which is why we ended up
On 11/29/18 4:56 AM, Roger Pau Monné wrote:
> On Thu, Nov 29, 2018 at 12:43:25PM +0800, Chao Gao wrote:
>> On Wed, Nov 28, 2018 at 04:22:09PM +0100, Roger Pau Monné wrote:
>>> On Wed, Nov 28, 2018 at 01:34:16PM +0800, Chao Gao wrote:
>>>
@@ -311,13 +350,45 @@ int
fn_range(struct vm_area_struct *vma,
> ^
>
> Signed-off-by: Srikanth Boddepalli
> ---
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 11/27/18 4:08 PM, Stefano Stabellini wrote:
> On Tue, 27 Nov 2018, Boris Ostrovsky wrote:
>> On 11/27/18 3:37 PM, Stefano Stabellini wrote:
>>> On Tue, 27 Nov 2018, PanBian wrote:
>>>> On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris Ostrovsky wrote:
>>>
> ---
> arch/x86/xen/enlighten.c | 78
>
> arch/x86/xen/setup.c | 6 ++--
> drivers/xen/balloon.c| 65 ++------
> include/xen/balloon.h| 5
> 4 files changed, 13 insertions(+), 141 del
On 11/27/18 3:37 PM, Stefano Stabellini wrote:
> On Tue, 27 Nov 2018, PanBian wrote:
>> On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris Ostrovsky wrote:
>>> On 11/21/18 9:07 PM, Pan Bian wrote:
>>>> kfree() is incorrectly used to release the pages all
On 11/27/18 2:46 AM, Juergen Gross wrote:
> On 26/11/2018 21:11, Boris Ostrovsky wrote:
>> On 11/23/18 11:24 AM, Juergen Gross wrote:
>>> Failure of an element of a Xen multicall is signalled via a WARN()
>>> only unless the kernel is compiled with MC_DEBUG. It i
On 11/26/18 2:57 PM, Igor Druzhinin wrote:
> On 26/11/2018 19:42, Boris Ostrovsky wrote:
>> On 11/26/18 12:10 PM, Igor Druzhinin wrote:
>>> On 26/11/2018 16:25, Boris Ostrovsky wrote:
>>>> On 11/25/18 8:00 PM, Igor Druzhinin wrote:
>>>>> On 20/12/201
On 11/21/18 9:07 PM, Pan Bian wrote:
> kfree() is incorrectly used to release the pages allocated by
> __get_free_page() and __get_free_pages(). Use the matching deallocators
> i.e., free_page() and free_pages(), respectively.
>
> Signed-off-by: Pan Bian
> ---
> drivers/xen/pvcalls-front.c | 4
On 11/23/18 11:24 AM, Juergen Gross wrote:
> Failure of an element of a Xen multicall is signalled via a WARN()
> only unless the kernel is compiled with MC_DEBUG. It is impossible to
s/unless/if
> know which element failed and why it did so.
>
> Change that by printing the related information
On 11/25/18 8:00 PM, Igor Druzhinin wrote:
> On 20/12/2017 14:05, Boris Ostrovsky wrote:
>> Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
>> reservation") left host memory not assigned to dom0 as available for
>> memory hotplug.
>>
>&g
On 11/21/18 2:56 PM, Souptick Joarder wrote:
> On Thu, Nov 22, 2018 at 1:08 AM Boris Ostrovsky
> wrote:
>> On 11/21/18 1:24 AM, Souptick Joarder wrote:
>>> On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder
>>> wrote:
>>>> Previouly drivers have their own
On 11/21/18 1:24 AM, Souptick Joarder wrote:
> On Thu, Nov 15, 2018 at 9:09 PM 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
On 11/19/18 8:59 AM, Juergen Gross wrote:
> arch/x86/xen/spinlock.c includes several headers which are not needed.
> Remove the #includes.
>
> Signed-off-by: Juergen Gross
> ---
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing
tl 95819099-482
> Total: Before=3314610, After=3313581, chg -0.03%
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Bria
On 11/9/18 9:42 AM, Andrew Cooper wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Jun Nakajima
> CC: Kevin Tian
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Brian Woods
>
NE_PER_CPU(int, lock_kicker_irq) = -1;
> static DEFINE_PER_CPU(char *, irq_name);
> +static DEFINE_PER_CPU(atomic_t, xen_qlock_wait_nest);
I'd move this to xen_qlock_wait().
Either way,
Reviewed-by: Boris Ostrovsky
> static bool xen_pvspin = true;
>
> static void xen_
On 11/9/18 2:03 AM, Juergen Gross wrote:
> Ping?
>
> Jan's remark regarding de-privileged qemu is no issue as the hypercall
> node is being closed by the de-privilege library function.
Reviewed-by: Boris Ostrovsky
___
Xen-devel mail
On 11/7/18 5:45 PM, Sander Eikelenboom wrote:
> On 07/11/18 23:34, Boris Ostrovsky wrote:
>> On 11/7/18 4:30 AM, Sander Eikelenboom wrote:
>>> Hi Juergen / Boris,
>>>
>>> Last week i tested Linux kernel 4.19.0 stable with the Xen "for-linus-4.20"
On 11/7/18 4:30 AM, Sander Eikelenboom wrote:
> Hi Juergen / Boris,
>
> Last week i tested Linux kernel 4.19.0 stable with the Xen "for-linus-4.20"
> branch pulled on top.
> Unfortunately i was seeing guests lockup after some time, see below for the
> logging from one of the guest
> which i was
On 11/7/18 5:49 AM, Daniel Kiper wrote:
> On Tue, Nov 06, 2018 at 09:54:54AM -0700, Jan Beulich wrote:
> On 02.11.18 at 18:59, wrote:
>>> It’s time again for the x86 community call: for the agenda see
>>> https://docs.google.com/document/d/1RxW-iwcFFuKzNjjEqLEtiwFVHgAUlk35c0EtTkRE1
>>>
On 11/6/18 7:07 AM, Sergey Dyasli wrote:
> As a convenient helper function and refactor the code to use it.
>
> No functional change.
>
> Signed-off-by: Sergey Dyasli
> ---
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Brian Woods
>
> v2:
>
I is enabled.
>
> Reported-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Wei Liu
> Cc: Boris Ostrovsky
> Cc: Suravee Suthikulpanit
> Cc: Brian Woods
Reviewed-by: Boris Ostrovsky
___
On 10/25/18 10:23 AM, Joe Jin wrote:
> On 10/25/18 4:45 AM, Boris Ostrovsky wrote:
>> On 10/24/18 10:43 AM, Joe Jin wrote:
>>> On 10/24/18 6:57 AM, Boris Ostrovsky wrote:
>>>> On 10/24/18 9:02 AM, Konrad Rzeszutek Wilk wrote:
>>>>> On Tue, Oc
On 10/25/18 8:36 AM, Juergen Gross wrote:
> On 11/10/2018 13:03, Joao Martins wrote:
>> On 10/11/2018 06:05 AM, Juergen Gross wrote:
>>> On 10/10/2018 18:57, Boris Ostrovsky wrote:
>>>> On 10/10/18 11:53 AM, Juergen Gross wrote:
>>>>> On 10/10/2018 17
he boot message:
>
> [0.00] Xen Platform PCI: unrecognised magic value
>
> Cc: # 4.11
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
601 - 700 of 1105 matches
Mail list logo
