On 11/28/19 3:45 AM, Juergen Gross wrote:
> -
> static void __xen_evtchn_do_upcall(void)
> {
> struct vcpu_info *vcpu_info = __this_cpu_read(xen_vcpu);
> - int cpu = get_cpu();
> - unsigned count;
> + int cpu = smp_processor_id();
>
> do {
>
On 11/27/19 10:44 AM, Jan Beulich wrote:
> On 27.11.2019 13:00, Paul Durrant wrote:
>> --- a/xen/arch/x86/cpu/vpmu.c
>> +++ b/xen/arch/x86/cpu/vpmu.c
>> @@ -479,6 +479,8 @@ static int vpmu_arch_initialise(struct vcpu *v)
>>
>> if ( ret )
>> printk(XENLOG_G_WARNING "VPMU:
On 11/19/19 9:17 PM, Boris Ostrovsky wrote:
> On 11/19/19 12:50 PM, Boris Ostrovsky wrote:
>> On 11/19/19 7:58 AM, Jan Beulich wrote:
>>> On 11.11.2019 15:30, Jan Beulich wrote:
>>>> The first patch here fixes another regression from 3c88c692c287
>>>&g
On 11/19/19 12:50 PM, Boris Ostrovsky wrote:
> On 11/19/19 7:58 AM, Jan Beulich wrote:
>> On 11.11.2019 15:30, Jan Beulich wrote:
>>> The first patch here fixes another regression from 3c88c692c287
>>> ("x86/stackframe/32: Provide consistent pt_regs"),
On 11/19/19 7:58 AM, Jan Beulich wrote:
> On 11.11.2019 15:30, Jan Beulich wrote:
>> The first patch here fixes another regression from 3c88c692c287
>> ("x86/stackframe/32: Provide consistent pt_regs"), besides the
>> one already addressed by
>>
On 11/13/19 8:44 AM, Jan Beulich wrote:
> On 13.11.2019 01:11, Boris Ostrovsky wrote:
>> On 11/11/19 9:46 AM, Jan Beulich wrote:
>>> --- a/arch/x86/include/asm/msr-index.h
>>> +++ b/arch/x86/include/asm/msr-index.h
>>> @@ -393,6 +393,8 @@
>>> #define
On 11/11/19 9:46 AM, Jan Beulich wrote:
> There's no apparent reason why it can be used on 64-bit only.
>
> Signed-off-by: Jan Beulich
>
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -285,7 +285,7 @@ config XEN_ACPI_PROCESSOR
>
> config XEN_MCE_LOG
> bool "Xen platform
On 11/11/19 9:46 AM, Jan Beulich wrote:
> This is to augment commit 3f5a7896a5 ("x86/mce: Include the PPIN in MCE
> records when available").
>
> I'm also adding "synd" and "ipid" fields to struct xen_mce, in an
> attempt to keep field offsets in sync with struct mce. These two fields
> won't get
On 11/11/19 9:45 AM, Jan Beulich wrote:
> It has never been part of Xen's public interface, and there's therefore
> no guarantee for MCG_CAP's value to always be present in array entry 0.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Bor
On 11/7/19 3:36 PM, Jason Gunthorpe wrote:
> On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
>
>>> So, I suppose it can be relaxed to a null test and a WARN_ON that it
>>> hasn't changed?
>> You mean
>>
>> if (use_pt
On 11/5/19 5:18 AM, David Hildenbrand wrote:
> On 04.11.19 23:44, Boris Ostrovsky wrote:
>> On 10/24/19 8:09 AM, David Hildenbrand wrote:
>>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
>>> index 4f2e78a5e4db..af69f057913a 100644
>>> --- a/drivers
On 11/4/19 9:31 PM, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote:
>> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
>>> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct
>>> *vma)
>>> struct gn
On 10/24/19 8:09 AM, David Hildenbrand wrote:
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 4f2e78a5e4db..af69f057913a 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -374,6 +374,13 @@ static void xen_online_page(struct page *page, unsigned
> int
On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma)
> struct gntdev_priv *priv = file->private_data;
>
> pr_debug("gntdev_vma_close %p\n", vma);
> - if (use_ptemod) {
> - /* It is possible that an
On 11/1/19 1:48 PM, Jason Gunthorpe wrote:
> On Wed, Oct 30, 2019 at 12:55:37PM -0400, Boris Ostrovsky wrote:
>> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
>>> From: Jason Gunthorpe
>>>
>>> gntdev simply wants to monitor a specific VMA for any n
ed until the original VMA is destroyed.
>
> It is unclear if any of this is even sane, but at least a lot of duplicate
> code is removed.
I didn't have a chance to look at the patch itself yet but as a heads-up
--- it crashes dom0.
-boris
>
> Cc: Oleksandr Andrushchenko
&g
On 10/25/19 3:38 AM, Juergen Gross wrote:
> Support for the kernel as Xen 32-bit PV guest will soon be removed.
> Issue a warning when booted as such.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
> ---
> arch/x86/xen/enlighten_pv.c | 8
> 1 file
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 devices.
gt;> 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
>> Cc
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. My
earlier
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
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 means t
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-b
s driver for multiple concurrent
> xenstore accesses")
> 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
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
---
arch/x86/xen
--
> 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/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
mmetries to get introduced). Use the best of both
> worlds by e.g. using "curr" consistently. This then being the only
> caller of hvm_check_cpuid_faulting(), fold in that function as well.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
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
___
Xen-devel mailing list
Xen-devel@
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:
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:
>>>>&g
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/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, Boris Ostrovsky wrote:
>>>> On 9/8/19 5:11 PM, Igor Druzhinin wrote:
>>>>> On 08/09/2019 19:28,
On 9/8/19 7:37 PM, Igor Druzhinin wrote:
> On 09/09/2019 00:30, Boris Ostrovsky wrote:
>> On 9/8/19 5:11 PM, Igor Druzhinin wrote:
>>> On 08/09/2019 19:28, Boris Ostrovsky wrote:
>>>> On 9/6/19 7:00 PM, Igor Druzhinin wrote:
>>>>> On 06/09/2019 23:30
On 9/8/19 5:11 PM, Igor Druzhinin wrote:
> On 08/09/2019 19:28, Boris Ostrovsky wrote:
>> On 9/6/19 7:00 PM, Igor Druzhinin wrote:
>>> On 06/09/2019 23:30, Boris Ostrovsky wrote:
>>>> Where is MCFG parsed? pci_arch_init()?
>>>>> It happens twice:
On 9/6/19 7:00 PM, Igor Druzhinin wrote:
>
> On 06/09/2019 23:30, Boris Ostrovsky wrote:
>> On 9/3/19 8:20 PM, Igor Druzhinin wrote:
>>> If MCFG area is not reserved in E820, Xen by default will defer its usage
>>> until Dom0 registers it explicitl
On 9/3/19 8:20 PM, Igor Druzhinin wrote:
> If MCFG area is not reserved in E820, Xen by default will defer its usage
> until Dom0 registers it explicitly after ACPI parser recognizes it as
> a reserved resource in DSDT. Having it reserved in E820 is not
> mandatory according to "PCI Firmware
On 9/6/19 10:43 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 06, 2019 at 10:19:01AM -0400, Boris Ostrovsky wrote:
>> On 9/6/19 10:01 AM, Christoph Hellwig wrote:
>>> On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote:
>>>> We need nop de
On 9/6/19 10:01 AM, Christoph Hellwig wrote:
> On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote:
>> We need nop definitions of these two for x86.
>>
>> Everything builds now but that's probably because the calls are under
>> 'if (!dev_is_dma_coherent(dev)
On 9/5/19 7:34 AM, Christoph Hellwig wrote:
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index 5e4b83f83dbc..d71380f6ed0b 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -4,6 +4,11 @@
>
> #include
>
> +void xen_dma_sync_for_cpu(struct
On 9/6/19 8:27 AM, Souptick Joarder wrote:
> On Mon, Sep 2, 2019 at 2:04 PM Souptick Joarder wrote:
>> Rather than using static int max_dma_bits, this
>> can be coverted to use as macro.
>>
>> Signed-off-by: Souptick Joarder
>> Reviewed-by: Juergen Gross
> If it is still not late, can we get
(Now with correct address for Juergen)
On 9/3/19 6:15 PM, Boris Ostrovsky wrote:
> On 9/2/19 9:03 AM, Christoph Hellwig wrote:
>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>> index b8808677ae1d..f9dd4cb6e4b3 100644
>> --- a/drivers/xen/swiotlb-xen.c
On 9/2/19 9:03 AM, Christoph Hellwig wrote:
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index b8808677ae1d..f9dd4cb6e4b3 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -299,8 +299,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev,
On 8/23/19 10:25 AM, Andrew Cooper wrote:
> We are now down to 0 SVM maintainers who are active and wish to hold the
> position. Fall back to general x86 maintenance until this position changes.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Boris Ostrovsky
> CC: Suravee Sut
eaks. To fix this issue, invoke the cleanup before
> returning the error.
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
_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
> Tested-by: Mare
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
Wunused-but-set-variable]
>
> It is never used so can be removed.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
> 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
>
t; 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 O
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 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 = _hyper_xen_hvm.init;
> +
> + if
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 */
> +
elf 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 | 27 +++
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
R
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 Ostrovsky
> Cc: Juergen Gr
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 | 27 +++
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
___
Xen-devel mailing list
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-by: Juerg
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: Juer
On 6/4/19 12:51 PM, Stefano Stabellini wrote:
> On Mon, 3 Jun 2019, Boris Ostrovsky wrote:
>> On 6/3/19 2:25 PM, Stefano Stabellini wrote:
>>> On Tue, 28 May 2019, Boris Ostrovsky wrote:
>>>> On 5/28/19 6:48 PM, Stefano Stabellini wrote:
>>>>> From: Ste
On 5/31/19 10:44 AM, Konrad Rzeszutek Wilk wrote:
> On May 31, 2019 10:41:16 AM EDT, Juergen Gross wrote:
>> On 06/05/2019 10:11, Juergen Gross wrote:
>>> On 03/05/2019 17:04, Roger Pau Monne wrote:
There's no reason to request physically contiguous memory for those
allocations.
On 6/3/19 2:25 PM, Stefano Stabellini wrote:
> On Tue, 28 May 2019, Boris Ostrovsky wrote:
>> On 5/28/19 6:48 PM, Stefano Stabellini wrote:
>>> From: Stefano Stabellini
>>>
>>> On arm64 swiotlb is often (not always) already initialized by mem_init.
>>>
On 5/30/19 5:04 AM, Christoph Hellwig wrote:
> Please don't add your private flag to page-flags.h. The whole point of
> the private flag is that you can use it in any way you want withou
> touching the common code.
There is already a bunch of aliases for various sub-components
(including Xen)
On 5/28/19 6:48 PM, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> On arm64 swiotlb is often (not always) already initialized by mem_init.
> We don't want to initialize it twice, which would trigger a second
> memory allocation. Moreover, the second memory pool is typically made of
>
> diff --git a/include/xen/balloon.h b/include/xen/balloon.h
> index 4914b93a23f2..a72ef3f88b39 100644
> --- a/include/xen/balloon.h
> +++ b/include/xen/balloon.h
> @@ -28,14 +28,6 @@ int alloc_xenballooned_pages(int nr_pages, struct page
> **pages);
> void free_xenballooned_pages(int nr_pages,
On 5/16/19 11:33 AM, Alexander Graf wrote:
> On 16.05.19 08:25, Sironi, Filippo wrote:
>>> On 16. May 2019, at 15:56, Graf, Alexander wrote:
>>>
>>> On 14.05.19 08:16, Filippo Sironi wrote:
On x86, we report the UUID in DMI System Information (i.e., DMI Type 1)
as VM UUID.
On 5/16/19 10:08 AM, Alexander Graf wrote:
>
> My point is mostly that we should be as common
> as possible when it comes to /sys/hypervisor, so that tools don't have
> to care about the HV they're working against.
It might make sense to have a common sys-hypervisor.c file
On 4/30/19 7:10 AM, Christian König wrote:
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> index 2c4f324f8626..cacca830b482 100644
> --- a/drivers/xen/gntdev-dmabuf.c
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -608,6 +608,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv
On 4/25/19 6:02 AM, Roger Pau Monné wrote:
> On Wed, Apr 24, 2019 at 11:45:43AM -0400, Boris Ostrovsky wrote:
>> On 4/24/19 11:45 AM, Roger Pau Monné wrote:
>>> On Wed, Apr 24, 2019 at 11:36:41AM -0400, Boris Ostrovsky wrote:
>>>> On 4/23/19 9:04 AM, Roger Pau Mo
On 4/16/19 12:06 AM, Mao Wenan wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> The declarations were introduced with the file, but the declared
> variables were not used.
>
> Fixes: 1107ba885e469("xen: add xenfs to allow usermode <-> Xen interaction")
> Signed-off-by: Mao
On 4/15/19 5:11 PM, 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/net/xen-netfront.c: In function ‘netback_changed’:
>
On 4/6/19 8:29 AM, Hariprasad Kelam wrote:
> Changes passing function argument 0 to NULL to avoid below sparse
> warning
>
> CHECK drivers/xen/xen-pciback/xenbus.c
> drivers/xen/xen-pciback/xenbus.c:700:51: warning: Using plain integer as
> NULL pointer
>
> Signed-off-by: Hariprasad Kelam
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
On 4/24/19 11:45 AM, Roger Pau Monné wrote:
> On Wed, Apr 24, 2019 at 11:36:41AM -0400, Boris Ostrovsky wrote:
>> On 4/23/19 9:04 AM, Roger Pau Monne wrote:
>>> This involves initializing the boot params EFI related fields and the
>>> efi global variable.
>>
On 4/23/19 9:04 AM, Roger Pau Monne wrote:
> This involves initializing the boot params EFI related fields and the
> efi global variable.
>
> Without this fix a PVH dom0 doesn't detect when booted from EFI, and
> thus doesn't support accessing any of the EFI related data.
>
> Reported-by: PGNet
On 4/23/19 6:54 AM, Juergen Gross wrote:
> Instead of always calling xen_destroy_contiguous_region() in case the
> memory is DMA-able for the used device, do so only in case it has been
> made DMA-able via xen_create_contiguous_region() before.
>
> This will avoid a lot of
ce, so merge it into range_straddles_page_boundary().
>
> 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
: sta...@vger.kernel.org
> 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
ree.
-boris
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: xen-devel@lists.xenproject.org
> ---
> arch/x86/xen/enlighten_pvh.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/xen/enlighten_pvh.c b/
On 4/18/19 3:36 AM, Juergen Gross wrote:
> I'm currently investigating a problem related to swiotlb-xen. With a
> specific driver a customer is capable to trigger a situation where a
> MFN is mapped to multiple dom0 PFNs at the same time. There is no
> guest involved, so this is not related to
On 4/16/19 10:49 AM, Yue Haibing wrote:
> From: YueHaibing
>
> Fix sparse warnings:
>
> drivers/xen/swiotlb-xen.c:489:1: warning:
> symbol 'xen_swiotlb_sync_single_for_cpu' was not declared. Should it be
> static?
> drivers/xen/swiotlb-xen.c:496:1: warning:
> symbol
On 3/28/19 10:48 AM, Jan Beulich wrote:
> I'm in particular after getting rid of asm/apicdef.h, but there are more
> no longer (or perhaps never having been) used ones.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
_
gt;
> Fixes: 1246ae0bb992 ("xen: add variable hypercall caller")
> Signed-off-by: Dan Carpenter
Reviewed-by: Boris Ostrovsky
I am also adding sta...@vger.kernel.org
-boris
> ---
> arch/x86/include/asm/xen/hypercall.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> dif
On 3/29/19 11:12 AM, Jan Beulich wrote:
On 29.03.19 at 14:42, wrote:
>> On 3/29/19 4:54 AM, Jan Beulich wrote:
>> On 28.03.19 at 17:50, wrote:
Given especially xen_pv_smp_prepare_cpus(), I think re-working proper
setting of present/possible masks is well beyond the scope of
On 3/29/19 4:54 AM, Jan Beulich wrote:
On 28.03.19 at 17:50, wrote:
>>
>> Given especially xen_pv_smp_prepare_cpus(), I think re-working proper
>> setting of present/possible masks is well beyond the scope of your
>> original patch.
> Well, then the question is, what (if any) changes are you
On 3/28/19 5:03 AM, Jan Beulich wrote:
On 27.03.19 at 18:07, wrote:
>> On 3/27/19 11:12 AM, Jan Beulich wrote:
>>> -
>>> -static void __init xen_filter_cpu_maps(void)
>>> +static void __init _get_smp_config(unsigned int early)
>>> {
>>> int i, rc;
>>> unsigned int subtract = 0;
>>>
On 3/27/19 11:12 AM, Jan Beulich wrote:
> -
> -static void __init xen_filter_cpu_maps(void)
> +static void __init _get_smp_config(unsigned int early)
> {
> int i, rc;
> unsigned int subtract = 0;
>
> - if (!xen_initial_domain())
> + if (early)
> return;
>
>
On 3/25/19 10:40 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
>> Jennifer Herbert
>> Sent: 25 March 2019 14:24
>> To: Boris Ostrovsky ; x...@kernel.org;
>> xen-deve
On 3/27/19 6:00 AM, Ryan Thibodeaux wrote:
> On Tue, Mar 26, 2019 at 07:21:31PM -0400, Boris Ostrovsky wrote:
>> On 3/26/19 5:13 AM, Dario Faggioli wrote:
>>> On Mon, 2019-03-25 at 09:43 -0400, Boris Ostrovsky wrote:
>>>> On 3/25/19 8:05 AM, luca abeni wrote:
>>
On 3/26/19 5:13 AM, Dario Faggioli wrote:
> On Mon, 2019-03-25 at 09:43 -0400, Boris Ostrovsky wrote:
>> On 3/25/19 8:05 AM, luca abeni wrote:
>>> The picture shows the latencies measured with an unpatched guest
>>> kernel
>>> and with a guest kernel havi
On 3/25/19 10:11 AM, Ryan Thibodeaux wrote:
> On Mon, Mar 25, 2019 at 09:43:20AM -0400, Boris Ostrovsky wrote:
>> On 3/25/19 8:05 AM, luca abeni wrote:
>>> Hi all,
>>>
>>> On Sat, 23 Mar 2019 11:41:51 +0100
>>> luca abeni wrote:
>>> [...
On 3/25/19 8:05 AM, luca abeni wrote:
> Hi all,
>
> On Sat, 23 Mar 2019 11:41:51 +0100
> luca abeni wrote:
> [...]
Is there any data that shows effects of using this new parameter?
>>> Yes, I've done some research and experiments on this. I did it
>>> together with a friend, which
On Sat, Mar 23, 2019 at 08:00:52AM -0400, Ryan Thibodeaux wrote:
> On Fri, Mar 22, 2019 at 06:10:16PM -0400, Boris Ostrovsky wrote:
> > On 3/22/19 2:29 PM, thibo...@gmail.com wrote:
> > > From: Ryan Thibodeaux
> > >
> > > Add a new command-line option "xen
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
On 3/19/19 4:02 PM, Jennifer Herbert wrote:
> The ACPI tables doesn't always contain all IRQs for legacy devices
> such as RTC. Since no PIC controller is visible for a PV linux guest,
> under Xen, legacy_pic currently defaults to the null_legacy_pic - with
> reports no legacy IRQs. Since the
On 3/15/19 12:22 PM, Andrew Cooper wrote:
> On 15/03/2019 15:59, Boris Ostrovsky wrote:
>> On 3/15/19 11:23 AM, Andrew Cooper wrote:
>>> Taking svm_feature_flags by pointer and using test_bit() results in
>>> generated
>>> code which loads svm_feature_fl
14041388 -16
> svm_vmexit_handler 62716239 -32
> start_svm818 738 -80
> Total: Before=3347569, After=3347433, chg -0.00%
>
> Signed-off-
On 3/14/19 12:33 PM, Oleksandr Andrushchenko wrote:
> On 3/14/19 17:40, Boris Ostrovsky wrote:
>> On 3/14/19 11:10 AM, Oleksandr Andrushchenko wrote:
>>> On 3/14/19 5:02 PM, Boris Ostrovsky wrote:
>>>> On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote:
>>>
On 3/14/19 11:10 AM, Oleksandr Andrushchenko wrote:
> On 3/14/19 5:02 PM, Boris Ostrovsky wrote:
>> 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:
>&
501 - 600 of 1105 matches
Mail list logo
