On 11/23/2017 03:11 AM, Christian König wrote:
Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:
On 11/22/2017 11:54 AM, Christian König wrote:
Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
On 11/22/2017 05:09 AM, Christian König wrote:
Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
On
Andy,
(Can't find the original patch in my mailbox)
This hunk from 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
them NMI-safe")
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index a9a8027..0d4483a 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/e
On 11/27/2017 12:34 AM, Juergen Gross wrote:
> On 27/11/17 05:03, Andy Lutomirski wrote:
>> On Sun, Nov 26, 2017 at 9:10 AM, Boris Ostrovsky
>> wrote:
>>> Andy,
>>>
>>> (Can't find the original patch in my mailbox)
>>>
>>> This hu
in 'ud2'.
Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op
when running paravirt.
Signed-off-by: Boris Ostrovsky
---
arch/x86/entry/entry_64.S|5 ++---
arch/x86/include/asm/irqflags.h |3 +++
arch/x86/include/asm/paravirt.h |9 +
arch/x86/
On 11/23/2017 09:12 AM, Boris Ostrovsky wrote:
>
>
> On 11/23/2017 03:11 AM, Christian König wrote:
>> Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:
>>> On 11/22/2017 11:54 AM, Christian König wrote:
>>>> Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
>
On 11/27/2017 02:22 PM, Juergen Gross wrote:
> On 27/11/17 19:05, Boris Ostrovsky wrote:
>> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
>> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
>> eflags using 'pushfq' i
in 'ud2'.
Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op
when running paravirt.
Signed-off-by: Boris Ostrovsky
---
V2:
* Preserve %rax in DEBUG_ENTRY_ASSERT_IRQS_OFF
* Return (pop) %rax in SAVE_FLAGS for !CONFIG_PARAVIRT (irqflags.h)
arch/x86/entry/entry_64.S|
On 11/28/2017 04:12 AM, Christian König wrote:
>
>
> How about the attached patch? It limits the newly added MMIO space to
> the upper 256GB of the address space. That should still be enough for
> most devices, but we avoid both issues with Xen dom0 as most likely
> problems with memory hotplug as
On 11/29/2017 03:50 AM, Roger Pau Monné wrote:
> On Wed, Nov 29, 2017 at 09:21:59AM +0100, Juergen Gross wrote:
>> On 28/11/17 20:34, Maran Wilson wrote:
>>> For certain applications it is desirable to rapidly boot a KVM virtual
>>> machine. In cases where legacy hardware and software support withi
On 11/29/2017 09:18 AM, Roger Pau Monné wrote:
> On Wed, Nov 29, 2017 at 03:11:12PM +0100, Juergen Gross wrote:
>> On 29/11/17 15:03, Boris Ostrovsky wrote:
>>> On 11/29/2017 03:50 AM, Roger Pau Monné wrote:
>>>> On Wed, Nov 29, 2017 at 09:21:59AM +0100, Juergen Gro
On 12/01/2017 11:22 AM, Andy Lutomirski wrote:
> On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky
> wrote:
>> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
>> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
>> eflags using
in 'ud2'.
Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op
when running paravirt.
Signed-off-by: Boris Ostrovsky
---
V3:
* Use CLBR_RAX to preserve all registers except %rax
arch/x86/entry/entry_64.S|7 ---
arch/x86/include/asm/irqflags.h |3 +++
a
On 12/05/2017 01:26 PM, Stefano Stabellini wrote:
> On Tue, 5 Dec 2017, Dan Carpenter wrote:
>> Smatch complains that "len" is uninitialized if xenbus_read() fails so
>> let's add some error handling.
>>
>> Signed-off-by: Dan Carpenter
> Reviewed-by: Stefano Stabellini
Applied to for-linus-4.15.
On 12/05/2017 01:29 PM, Stefano Stabellini wrote:
> On Tue, 5 Dec 2017, Dan Carpenter wrote:
>> bedata->ref can't be less than zero because it's unsigned. This affects
>> certain error paths in probe. We first set ->ref = -1 and then we set
>> it to a valid value later.
>>
>> Fixes: 219681909913
On 12/07/2017 05:45 PM, Maran Wilson wrote:
>
> Juergen also had a suggestion to split the different hypervisor types
> early and use a common set of service functions instead of special casing
> xen_guest everywhere.
>
> There are certainly less special cases in this version of the patch, but
> if
On 12/08/2017 12:56 PM, Bjorn Helgaas wrote:
> On Wed, Dec 06, 2017 at 01:51:18PM -0600, Bjorn Helgaas wrote:
>> On Wed, Nov 29, 2017 at 03:12:29PM +0100, Christian König wrote:
>>> This avoids problems with Xen which hides some memory resources from the
>>> OS and potentially also allows memory ho
;>>> but I found out my 'perf' does not support the feature:
>>>>
>>>>> nickeys@nickeys-linux-machine:~/ubuntu/tools/perf$ sudo ./perf stat -e
>>>>> r412e sleep 1
>>>>> Performance counter stats for 'sleep 1'
On 12/12/2017 01:38 PM, Christian König wrote:
> Am 12.12.2017 um 19:12 schrieb Bjorn Helgaas:
>> [+cc Boris, Juergen, xen-devel]
>>
>> On Mon, Dec 11, 2017 at 04:04:52PM +0100, Christian König wrote:
>>> Xen hides a bit of system memory from the OS for its own purpose by
>>> intercepting e820. Thi
On 12/08/2017 06:17 AM, Jan Beulich wrote:
> Unconditionally reporting a value seen on the P4 or older invokes
> functionality like io_apic_get_unique_id() on 32-bit builds, resulting
> in a panic() with sufficiently many CPUs and/or IO-APICs. Doing what
> that function does would be the hypervisor
On 12/12/2017 05:18 AM, Jan Beulich wrote:
> Add a respective dependency.
>
> Signed-off-by: Jan Beulich
Committed to for-linus-4.15.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-d
plug.
Signed-off-by: Boris Ostrovsky
---
I don't see /proc/meminfo reporting the hotplugged memory (although
internal data such as max_pfn is updated properly). Need to look at
hotplug code some more. But then I didn't see meminfo changing with
existing code either.
>> +
>> +hostmem_resource->start = max_addr;
>> +hostmem_resource->end = entry->addr + entry->size;
>> +for (; i < memmap.nr_entries; i++) {
>> +entry = &xen_e820_table->entries[i];
>> +if (entry->type == E820_TYPE_RAM)
> Shouldn't that be != ?
No, the idea her
On 12/15/2017 09:47 AM, Juergen Gross wrote:
> On 15/12/17 15:24, Boris Ostrovsky wrote:
>>>> +
>>>> + hostmem_resource->start = max_addr;
>>>> + hostmem_resource->end = entry->addr + entry->size;
>>>> + for (; i < memmap.nr_
On 12/15/2017 10:33 AM, Juergen Gross wrote:
> On 15/12/17 15:58, Boris Ostrovsky wrote:
>> On 12/15/2017 09:47 AM, Juergen Gross wrote:
>>> On 15/12/17 15:24, Boris Ostrovsky wrote:
>>>>>> +
>>>>>> +hostmem_resource->start = max_
us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Boris-Ostrovsky/xen-balloon-Mark-unallocated-host-memory-as-UNUSABLE/20171215-231511
> base: https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
> config: i386-rand
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, size_
(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/3/19 5:42 AM, Jan Beulich wrote:
>
> For TSC I see little point in making the intercepts dynamic, hence they
> get established right when a VMCB/VMCS gets created.
Why is this not treated in the same manner as rdtsc intercepts?
-boris
___
Xen-deve
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 thi
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 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_coh
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/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 Specif
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 explicitly after ACPI
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:
>&g
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/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/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
___
Xen-devel mailing
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
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 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
(drivers/hypervisor/sys-
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.
Sign
> 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/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
> hig
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) in
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/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/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
pvcalls-front.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 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
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 t
nused-but-set-variable]
>
> 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
_
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 ini
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 l
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
_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().
>
&
e x86 'unstable'
> 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
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")
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 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/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:
>>&
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/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 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
ory leaks. 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
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
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 fix
d 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
gt; 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
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
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
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
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/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/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,
>>
rs have failed to start.
>
> 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
>
> Thi
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, th
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 / t
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 rev
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
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
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
1 - 100 of 1148 matches
Mail list logo
