On 8/27/19 3:43 PM, Boris Ostrovsky wrote:
>
>
> Something like this. I only lightly tested this but if there is interest
> I can test it more.
This was a bit too aggressive with changes to arch-specific code, only
changes to __reload_late() would be needed.
-boris
On 8/24/19 4:53 AM, Borislav Petkov wrote:
>
> +wait_for_siblings:
> + if (__wait_for_cpus(&late_cpus_out, NSEC_PER_SEC))
> + panic("Timeout during microcode update!\n");
> +
> /*
> - * Increase the wait timeout to a safe value here since we're
> - * serializing th
On 8/24/19 4:53 AM, Borislav Petkov wrote:
> From: Borislav Petkov
> Date: Sat, 24 Aug 2019 10:01:53 +0200
>
> ... in order to not pollute dmesg with a line for each updated microcode
> engine.
>
> Signed-off-by: Borislav Petkov
> Cc: Ashok Raj
> Cc: Boris Ostro
On 9/3/19 12:46 PM, Borislav Petkov wrote:
>
>
> @@ -629,8 +639,12 @@ static ssize_t reload_store(struct device *dev,
> if (ret)
> return ret;
>
> - if (val != 1)
> + if (val == 2) {
> + add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
Why do we need
On 9/10/19 5:46 AM, Igor Druzhinin wrote:
> On 10/09/2019 02:47, Boris Ostrovsky wrote:
>> On 9/9/19 5:48 PM, Igor Druzhinin wrote:
>>> On 09/09/2019 20:19, Boris Ostrovsky wrote:
>>>> On 9/8/19 7:37 PM, Igor Druzhinin wrote:
>>>>> On 09/09/2019 00:30,
On 9/10/19 4:36 PM, Igor Druzhinin wrote:
> On 10/09/2019 18:48, Boris Ostrovsky wrote:
>> On 9/10/19 5:46 AM, Igor Druzhinin wrote:
>>> On 10/09/2019 02:47, Boris Ostrovsky wrote:
>>>> On 9/9/19 5:48 PM, Igor Druzhinin wrote:
>>>>> On 09/09/2019 2
On 9/10/19 9:15 PM, Igor Druzhinin wrote:
> On 10/09/2019 22:19, Boris Ostrovsky wrote:
>> On 9/10/19 4:36 PM, Igor Druzhinin wrote:
>>> On 10/09/2019 18:48, Boris Ostrovsky wrote:
>>>> On 9/10/19 5:46 AM, Igor Druzhinin wrote:
>>>>> On 10/09/2019 02:
since all the boot time buses must have their MCFG areas in MCFG table
> already and we don't support PCI bus hot-plug.
>
> Signed-off-by: Igor Druzhinin
Reviewed-by: Boris Ostrovsky
and applied to for-linus-5.4
On 10/2/19 3:40 AM, Jan Beulich wrote:
> On 01.10.2019 17:16, Boris Ostrovsky wrote:
>> Currently execution of panic() continues until Xen's panic notifier
>> (xen_panic_event()) is called at which point we make a hypercall that
>> never returns.
>>
>> This me
On 10/2/19 9:42 AM, Jan Beulich wrote:
>
> I can only guess that the thinking probably was that e.g. external
> dumping (by the tool stack) would be more reliable (including but
> not limited to this meaning less change of state from when the
> original crash reason was detected) than having the do
l
preserve original behavior during crash. This option could be used,
for example, if running kernel dumper (which happens after panic
notifiers) is undesirable.
Reported-by: James Dingwall
Signed-off-by: Boris Ostrovsky
---
v2: Added xen_legacy_crash boot option to preserve current behaviour.
from
kmsg_dump()) is never executed.
There is no reason for xen_panic_event() to be this last point in
execution since panic()'s emergency_restart() will call into
xen_emergency_restart() from where we can perform our hypercall.
Reported-by: James Dingwall
Signed-off-by: Boris Ostrovsky
---
ar
river for multiple concurrent
> xenstore accesses")
> Cc: # 4.11
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 10/1/19 5:01 AM, David Hildenbrand wrote:
> Let's simply use balloon_append() directly.
>
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Signed-off-by: David Hildenbrand
For the series (and your earlier patch)
Reviewed-by: Boris Ostrovsky
On 10/3/19 10:02 AM, Zhenzhong Duan wrote:
> void __init kvm_spinlock_init(void)
> {
> - /* Does host kernel support KVM_FEATURE_PV_UNHALT? */
> - if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT))
> - return;
> -
> - if (kvm_para_has_hint(KVM_HINTS_REALTIME))
> + /*
>
On 10/3/19 10:02 AM, Zhenzhong Duan wrote:
> Map "xen_nopvspin" to "nopvspin", fix stale description of "xen_nopvspin"
> as we use qspinlock now.
>
> Signed-off-by: Zhenzhong Duan
> Cc: Jonathan Corbet
> Cc: Boris Ostrovsky
> Cc: Juergen Gro
On 10/6/19 3:49 AM, Zhenzhong Duan wrote:
> On 2019/10/4 22:52, Boris Ostrovsky wrote:
>
>> On 10/3/19 10:02 AM, Zhenzhong Duan wrote:
>>> void __init kvm_spinlock_init(void)
>>> {
>>> - /* Does host kernel support KVM_FEATURE_PV_UNHALT
On 9/19/19 12:14 PM, James Dingwall wrote:
> On Thu, Sep 19, 2019 at 03:51:33PM +, Luck, Tony wrote:
>>> I have been investigating a regression in our environment where pstore
>>> (efi-pstore specifically but I suspect this would affect all
>>> implementations) no longer works after upgrading
On 9/25/19 7:01 AM, James Dingwall wrote:
> On Mon, Sep 23, 2019 at 08:41:05PM -0400, Boris Ostrovsky wrote:
>> On 9/23/19 6:59 PM, Kees Cook wrote:
>>> On Mon, Sep 23, 2019 at 03:42:27PM +, James Dingwall wrote:
>>>> On Thu, Sep 19, 2019 at 12:37:40PM -0400, Bor
--
> kernel BUG at include/linux/page-flags.h:744!
> invalid opcode: [#1] SMP NOPTI
>
> Reported-by: Marek Marczykowski-Górecki
> Tested-by: Marek Marczykowski-Górecki
> Fixes: 77c4adf6a6df ("xen/balloon: mark inflated pages PG_offline")
> Cc: sta...@vger.kernel
On 9/23/19 6:59 PM, Kees Cook wrote:
> On Mon, Sep 23, 2019 at 03:42:27PM +, James Dingwall wrote:
>> On Thu, Sep 19, 2019 at 12:37:40PM -0400, Boris Ostrovsky wrote:
>>> On 9/19/19 12:14 PM, James Dingwall wrote:
>>>> On Thu, Sep 19, 2019 at 03:51:33PM +, L
r.
>
> Move xen_platform_hvm() after xen_hvm_guest_late_init() to avoid compile
> error.
>
> Signed-off-by: Zhenzhong Duan
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
Reviewed-by: Boris Ostrovsky
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index 084de77a109e..d42737f31304 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> -OBJECT_FILES_NON_STANDARD_xen-asm_$(BITS).o := y
> +OBJECT_FILES_NON_STANDA
>> setting the DMA masks and there's no reason to restrict the masks to
>> 32-bits. So set the masks to 64 bits.
>>
>> Cc: Robin Murphy
>> Cc: Julien Grall
>> Cc: Nicolas Saenz Julienne
>> Cc: Oleksandr Andrushchenko
>> Cc: Boris Ostrovsky
&
On 10/10/19 11:32 AM, Rob Herring wrote:
> On Thu, Oct 10, 2019 at 9:00 AM Boris Ostrovsky
> wrote:
>> On 10/9/19 7:42 AM, Oleksandr Andrushchenko wrote:
>>> On 10/8/19 10:41 PM, Rob Herring wrote:
>>>> As the removed comments say, these aren't DT based dev
On 4/28/20 11:36 AM, Wei Liu wrote:
> All callers within the same file pass in -1 (no override).
>
> Signed-off-by: Wei Liu
Reviewed-by: Boris Ostrovsky
sical_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
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 b
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(&gntdev_dmabuf->next);
> + fput(gntdev_
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 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
> th
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 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 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 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
>> wro
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 lin
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 deliver
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 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:
>>&
e x86 'unstable'
> sched_clock() interface")
> Cc: # 4.11
> Reported-by: Hans van Kranenburg
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
free_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&quo
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-kernel@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 c
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
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/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&id=9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19
is queued and addresses this problem.
(Please run scrip
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.
>>>
>>>
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")
> Rep
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 ../arch
On 5/13/19 7:51 AM, Raslan, KarimAllah wrote:
> On Mon, 2019-05-13 at 07:31 -0400, Konrad Rzeszutek Wilk wrote:
>> On May 13, 2019 5:20:37 AM EDT, Wanpeng Li wrote:
>>> On Wed, 8 May 2019 at 02:57, Marcelo Tosatti
>>> wrote:
Certain workloads perform poorly on KVM compared to barem
ot used [-Wunused-but-set-variable]
>
> It is never used so can be removed.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Reviewed-by: Boris Ostrovsky
On 7/30/19 2:03 AM, Souptick Joarder wrote:
> On Mon, Jul 29, 2019 at 7:06 PM Marek Marczykowski-Górecki
> wrote:
>> On Mon, Jul 29, 2019 at 02:02:54PM +0530, Souptick Joarder wrote:
>>> On Mon, Jul 29, 2019 at 1:35 PM Souptick Joarder
>>> wrote:
On Sun, Jul 28, 2019 at 11:36 PM Marek Marcz
to use vm_map_pages_zero() will fix the
> problem.
>
> Marek has tested and confirmed the same.
Cc: sta...@vger.kernel.org # v5.2+
Fixes: df9bde015a72 ("xen/gntdev.c: convert to use vm_map_pages()")
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Souptick Joarder
On Mon, Jul 01, 2019 at 10:20:27AM +0800, Zhenzhong Duan wrote:
> This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
>
> Instead we use an unified parameter 'nopv' for all the hypervisor
> platforms.
>
> Signed-off-by: Zhenzhong Duan
> Reviewed
ly") adds jump_label_init() call in setup_arch() to make static
> > keys initialized early, so we could use the original simpler code
> > again.
> >
> > Signed-off-by: Zhenzhong Duan
> > Cc: Waiman Long
> > Cc: Peter Zijlstra (Intel)
> > Cc: Thom
On 7/1/19 1:19 AM, Zhenzhong Duan wrote:
>
> There is already 'xen_nopv' parameter for XEN platform but not for
> others. 'xen_nopv' can then be removed with this change.
This is no longer true.
-boris
anic itself if 'nopv' enabled for a
> PVH guest.
>
> Signed-off-by: Zhenzhong Duan
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> ---
> arch/x86/xen/enlighte
On 7/1/19 1:19 AM, Zhenzhong Duan wrote:
> Map 'xen_nopv' to 'nopv' and mark 'xen_nopv' obsolete in
> kernel-parameters.txt
I am not sure we want patch #3, why not do everything in a single patch?
>
> Signed-off-by: Zhenzhong Duan
> Cc: Boris
nd the event channel won't be moved to another vcpu
> in case the original vcpu they were bound to is going offline.
>
> Cc: # 4.13
> Fixes: c48f64ab472389df ("xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to
> next online VCPU")
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 7/2/19 9:19 PM, Zhenzhong Duan wrote:
> Clean up unnecessory code after that operation.
>
> Signed-off-by: Zhenzhong Duan
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
Reviewed-by: Boris Ostrovsky
nic itself if nopv enabled for a
> PVH guest.
>
> Signed-off-by: Zhenzhong Duan
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> ---
> arch/x86/xen/enlighten_hvm.c |
On 7/7/19 5:15 AM, Zhenzhong Duan wrote:
>
> +static uint32_t __init xen_platform_hvm(void)
> +{
> + if (xen_pv_domain())
> + return 0;
> +
> + if (xen_pvh_domain() && nopv) {
> + /* Guest booting via the Xen-PVH boot entry goes here */
> + pr_info("\"n
On 7/9/19 12:20 AM, Zhenzhong Duan wrote:
>
> -const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
> +static uint32_t __init xen_platform_hvm(void)
> +{
> + uint32_t xen_domain = xen_cpuid_base();
> + struct x86_hyper_init *h = &x86_hyper_xen_hvm.init;
> +
> + if (xen_pv
On 7/9/19 10:07 PM, Zhenzhong Duan wrote:
> On 2019/7/9 22:54, Boris Ostrovsky wrote:
>> On 7/9/19 12:20 AM, Zhenzhong Duan wrote:
>>> -const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
>>> +static uint32_t __init xen_platform_hvm(void)
>>>
On 1/8/19 5:48 AM, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote:
>> For drivers that do not support context exclusion let's advertise the
>> PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
>> prevent us from handling events where any exclusion
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 ‘xen_pcibk_frontend_c
On 3/22/19 2:29 PM, thibo...@gmail.com wrote:
> From: Ryan Thibodeaux
>
> Add a new command-line option "xen_timer_slop=" that sets the
> minimum delta of virtual Xen timers. This commit does not change the
> default timer slop value for virtual Xen timers.
>
> Lowering the timer slop value should
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 i
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 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
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 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/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 xen_c
er to detect that situation.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 9/19/18 9:42 AM, Juergen Gross wrote:
> When a driver domain (e.g. dom0) is running out of maptrack entries it
> can't map any more foreign domain pages. Instead of silently stalling
> the affected domUs issue a rate limited warning in this case in order
> to make it easier to detect that situat
On 09/06/2018 08:21 PM, Ben Hutchings wrote:
> On Sat, 2018-08-04 at 11:01 +0200, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> --
>>
>> From: Xiao Liang
>>
>> [ Upstream commit 822fb18a82abaf4ee7058793d95d340f5dab7bf
On 09/06/2018 08:36 PM, Sasha Levin wrote:
> From: Vitaly Kuznetsov
>
> [ Upstream commit 2d408c0d4574b01b9ed45e02516888bf925e11a9 ]
>
> Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
> open") changed the initialization order: xennet_create_queues() now
> happens before we d
On 9/7/18 12:49 PM, Marek Marczykowski-Górecki wrote:
> Scrubbing pages on initial balloon down can take some time, especially
> in nested virtualization case (nested EPT is slow). When HVM/PVH guest is
> started with memory= significantly lower than maxmem=, all the extra
> pages will be scrubbed
On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote:
> On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:
>> On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>
>> A commit message would be useful.
> Sure, v1 will have i
On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:
>> On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote:
>>> On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:
>>>> On 05/17/2018 04:26 AM, Oleksandr Andrushchenk
On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 09:53 PM, Boris Ostrovsky wrote:
>> On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote:
>>> On 05/21/2018 07:35 PM, Boris Ostrovsky wrote:
>>>> On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wr
We are making calls to C code (e.g. xen_prepare_pvh()) which may use
stack canary (stored in GS segment).
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/xen-pvh.S | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86
Fix stack canary handling (in the first patch) and re-index PVH GDT to
make it explicit that the GDT PVH-specific
v4:
* Load %gs after base address is calculated
* Increase stack canary segment size to 48 bytes for long mode.
Boris Ostrovsky (2):
xen/PVH: Set up GS segment for stack canary
We don't need to share PVH GDT layout with other GDTs, especially
since we now have a PVH-speciific entry (for stack canary segment).
Define PVH's own selectors.
(As a side effect of this change we are also fixing improper
reference to __KERNEL_CS)
Signed-off-by: Boris Ostrovsky
---
On 03/31/2018 01:38 PM, Jason Andryuk wrote:
On Wed, Mar 21, 2018, 5:12 PM Boris Ostrovsky
mailto:boris.ostrov...@oracle.com>> wrote:
On 03/19/2018 12:58 PM, Jason Andryuk wrote:
> Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings")
introduced a
&g
On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote:
> On 04/23/2018 02:52 PM, Wei Liu wrote:
>> On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote:
> the gntdev.
>
> I think this is generic enough that it could be implemented by a
> device not tied to Xe
Writing to it directly does not work for Xen PV guests.
Signed-off-by: Boris Ostrovsky
---
arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c
b/arch/x86/entry/vsyscall/vsyscall_64.c
index 8560ef68a9d6
On 04/13/2018 06:11 PM, Laura Abbott wrote:
> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> turn on -Wvla. The few VLAs in use have an upper bound based on a size
> of 64K. This doesn't produce an excessively large stack so just switch
> the upper bound.
>
> [1] https:
Boris Ostrovsky (2):
xen/PVH: Set up GS segment for stack canary
xen/PVH: Make GDT selectors PVH-specific
arch/x86/xen/xen-pvh.S | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
--
2.9.3
We don't need to share PVH GDT layout with other GDTs, especially
since we now have a PVH-speciific entry (for stack canary segment).
Define PVH's own selectors.
(As a side effect of this change we are also fixing improper
reference to __KERNEL_CS)
Signed-off-by: Boris Ostrovsky
---
We are making calls to C code (e.g. xen_prepare_pvh()) which may use
stack canary (stored in GS segment).
(We have to set the segment base to @canary at runtime just like
head_32.S does, from where the code fragment is taken)
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/xen-pvh.S | 19
ll fallback code for very old
> hypervisors")
> Signed-off-by: Arnd Bergmann
> ---
> [v2] use a table lookup instead of a switch/case statement, after
> multiple suggestions.
> [v3] remove that file completely
(+Jan who added this file originally)
Reviewed-by: Boris Ostrovsky
n existent of acpi_processor given that ACPI isn't creating
> an acpi_processor for non-dom0 CPUs.
>
> Signed-off-by: Joao Martins
Reviewed-by: Boris Ostrovsky
setting it
> immediately after the remap.
>
> Signed-off-by: Frank van der Linden
> Reviewed-by: Eduardo Valentin
> Reviewed-by: Alakesh Haloi
> Reviewed-by: Vallish Vaidyeshwara
> Cc: Juergen Gross
> Cc: Boris Ostrovsky
> Cc: xen-de...@lists.xenproject.org
> -
On 05/07/2018 02:00 PM, van der Linden, Frank wrote:
> Hi Boris,
>
> Thanks for the feedback.
>
> On 5/7/18, 8:13 AM, "Boris Ostrovsky" wrote:
>
> > diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> > index 6b424da1ce75..c7
On 04/09/2018 11:03 AM, Jia-Ju Bai wrote:
> pcistub_probe() is never called in atomic context.
> This function is only set as ".probe" in struct pci_driver.
>
> Despite never getting called from atomic context,
> pcistub_probe() calls kmalloc() with GFP_ATOMIC,
> which does not sleep for allocation
On 04/12/2018 01:26 PM, Oleksandr Andrushchenko wrote:
> This is the sync up with the canonical definition of the sound
> protocol in Xen:
>
> 1. Protocol version was referenced in the protocol description,
>but missed its definition. Fixed by adding a constant
>for current protocol version
On 04/17/2018 03:33 AM, Juergen Gross wrote:
> On 15/03/18 04:08, Simon Gaiser wrote:
>> xenbus_command_reply() did not actually copy the response string and
>> leaked stack content instead.
>>
>> Fixes: 9a6161fe73bd ("xen: return xenstore command failures via response
>> instead of rc")
>> Signed
On 04/17/2018 07:33 PM, Laura Abbott wrote:
> On 04/17/2018 12:16 AM, Juergen Gross wrote:
>> On 16/04/18 15:27, Boris Ostrovsky wrote:
>>> On 04/13/2018 06:11 PM, Laura Abbott wrote:
>>>> There's an ongoing effort to remove VLAs[1] from the kernel to
>>
> + int level;
> + pte_t *ptep;
> + void *virt;
>
> - BUG_ON(size > 65536);
> + BUG_ON(size > GDT_SIZE);
I'd probably BUG_ON(size>PAGE_SIZE) because that's what we are really
trying to avoid. Maybe with a comment that we expect GDT_SIZE at most,
and it is less than PAGE_SIZE.
I can fix it while committing if you don't object.
Reviewed-by: Boris Ostrovsky
On 12/02/2016 01:15 AM, Juergen Gross wrote:
>
> -static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info *info)
> +static int scsifront_do_request(struct vscsifrnt_info *info,
> + struct vscsifrnt_shadow *shadow)
> {
> struct vscsiif_front_ring *
801 - 900 of 1678 matches
Mail list logo
