tializer for 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
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
On 3/14/19 9:17 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Currently on driver resume we remove all the network queues and
> destroy shared Tx/Rx rings leaving the driver in its current state
> and never signaling the backend of this frontend's state change.
> This lead
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/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:
>&
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:
>>>
14041388 -16
> svm_vmexit_handler 62716239 -32
> start_svm818 738 -80
> Total: Before=3347569, After=3347433, chg -0.00%
>
> Signed-off-
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_flag
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 com
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 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/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 I
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/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/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/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 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/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/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/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 you
ss.
>
> 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(+)
>
>
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
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 'xen_swiotlb_sync_single_for
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 gran
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/
: 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
erge 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
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 xen_destroy_contiguous_re
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 Dev
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 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 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
Appl
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’:
> drivers/net/xen-netfront.c:203
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/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/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 *p
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
>> https://lists.xenproject.org/archives/html/xen-devel/
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"), bes
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/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: Initializat
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 {
> vcpu_info->evtc
On 11/28/19 3:48 AM, Jürgen Groß wrote:
> On 07.11.19 12:15, Juergen Gross wrote:
>> The Xen gntdev driver's checking of the number of allowed mapped pages
>> is in need of some sanitizing work.
>>
>> Changes in V2:
>> - enhanced commit message of patch 1 (Andrew Cooper)
>>
>> Juergen Gross (2):
>>
On 11/28/19 5:23 AM, Jan Beulich wrote:
> On 28.11.2019 10:38, Paul Durrant wrote:
>
>> --- a/xen/arch/x86/cpu/vpmu.c
>> +++ b/xen/arch/x86/cpu/vpmu.c
>> @@ -576,11 +576,36 @@ static void vpmu_arch_destroy(struct vcpu *v)
>>
>> vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>> }
>> +
>
> be removed.
>
> 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 Dec 4, 2019, at 10:55 AM, Julien Grall wrote:
>
> Hi Boris,
>
> On 28/11/2019 21:50, Boris Ostrovsky wrote:
>> On 11/28/19 5:23 AM, Jan Beulich wrote:
>>> On 28.11.2019 10:38, Paul Durrant wrote:
>>>
>>>> --- a/xen/arch/x86/cpu/vpmu.c
On 12/6/19 8:48 AM, Stefan Nuernberger wrote:
> From: Uwe Dannowski
>
> Reading /sys/bus/pci/drivers/pciback/quirks while unbinding can result
> in dereferencing a NULL pointer. Instead, skip printing information
> about the dangling quirk.
>
> Reported-by: Conny Seidel
> Signed-off-by: Uwe Danno
On 12/6/19 1:09 PM, Nuernberger, Stefan wrote:
> On Fri, 2019-12-06 at 10:11 -0500, Boris Ostrovsky wrote:
>> On 12/6/19 8:48 AM, Stefan Nuernberger wrote:
>>> From: Uwe Dannowski
>>>
>>> Reading /sys/bus/pci/drivers/pciback/quirks while unbinding can
&g
On 12/6/19 11:57 AM, Jan Beulich wrote:
> On 06.12.2019 17:51, Ian Jackson wrote:
>> Ian Jackson writes ("Re: [Xen-devel] [xen-unstable test] 144289: tolerable
>> FAIL"):
>>> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 144289: tolerable
>>> FAIL"):
On 25.11.2019 14:58, osstest s
On 12/9/19 1:16 PM, Nuernberger, Stefan wrote:
On Fri, 2019-12-06 at 15:15 -0500, Boris Ostrovsky wrote:
On 12/6/19 1:09 PM, Nuernberger, Stefan wrote:
On Fri, 2019-12-06 at 10:11 -0500, Boris Ostrovsky wrote:
On 12/6/19 8:48 AM, Stefan Nuernberger wrote:
From: Uwe Dannowski
balloon_process() no longer be triggered when
ballooned pages are freed in batches.
Reported-by: Nicholas Tsirakis
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
> On Dec 17, 2019, at 9:08 AM, Sergey Dyasli wrote:
>
> This series allows to boot and run Xen PV kernels (Dom0 and DomU) with
> CONFIG_KASAN=y. It has been used internally for some time now with good
> results for finding memory corruption issues in Dom0 kernel.
>
> Only Outline instrumentati
On 12/18/19 12:36 AM, Roman Shaposhnik wrote:
On Wed, Dec 11, 2019 at 12:41 AM Jan Beulich wrote:
On 11.12.2019 09:16, Jürgen Groß wrote:
On 11.12.19 08:28, Jan Beulich wrote:
Jürgen, Boris,
I've noticed
<6>clocksource: Switched to clocksource tsc
as the final clocksource related boot me
On 12/18/19 10:49 PM, Marek Marczykowski-Górecki wrote:
---
drivers/xen/xen-pciback/conf_space.c | 35
drivers/xen/xen-pciback/conf_space.h | 10 +++
.../xen/xen-pciback/conf_space_capability.c | 88 +++
drivers/xen/xen-pciback/conf_space_header
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
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
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)
Revie
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.
>> 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 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
ttached 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 Andrush
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
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 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 orde
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 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/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 (u
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
R
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 p
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 mcel
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/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/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/2017 14:05, Boris Ostrovsky wrote:
>>>> Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
>
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 e
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/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/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 is i
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 allocated
> ---
> 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 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:
>>>
te_unmap_gfn_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/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
microcode_update(XEN_GUE
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 disabling
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/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 negotiat
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
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 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/
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
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/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 bi
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 non-x
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 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 possible 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 does
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, c
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 nex
On 12/12/18 1:09 PM, Maran Wilson wrote:
> On 12/6/2018 1:21 PM, Paolo Bonzini wrote:
>> On 06/12/18 07:02, 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 nee
101 - 200 of 1149 matches
Mail list logo
