On 2/19/21 10:40 AM, Juergen Gross wrote:
> The first four patches are fixes for XSA-332. The avoid WARN splats
> and a performance issue with interdomain events.
>
> Patches 5 and 6 are some additions to event handling in order to add
> some per pv-device statistics to sysfs and the ability to h
inter to the xenbus device as a
> parameter instead of the domain id of the other side.
>
> While at it remove the stale prototype of bind_evtchn_to_irq_lateeoi().
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 12/11/20 7:37 AM, Thomas Gleixner wrote:
> On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote:
>> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
>>> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu interru
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
> All event channel setups bind the interrupt on CPU0 or the target CPU for
> percpu interrupts and overwrite the affinity mask with the corresponding
> cpumask. That does not make sense.
>
> The XEN implementation of irqchip::irq_set_affinity() already
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
> Signed-off-by: Thomas Gleixner
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: xen-de...@lists.xenproject.org
> ---
> drivers/xen/events/events_base.c |6 --
> 1 file changed, 6 deletions(
>>> Also, wrt KASLR stuff, that issue is still seen sometimes but I haven't
>>> had
>>> bandwidth to dive deep into the issue and fix it.
So what's the plan there? You first mentioned this issue early this year
and judged by your response it is not clear whether you will e
On 9/25/20 6:28 PM, Anchal Agarwal wrote:
> On Fri, Sep 25, 2020 at 04:02:58PM -0400, boris.ostrov...@oracle.com wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>> the content is safe
On 9/25/20 3:04 PM, Anchal Agarwal wrote:
> On Tue, Sep 22, 2020 at 11:17:36PM +, Anchal Agarwal wrote:
>> On Tue, Sep 22, 2020 at 12:18:05PM -0400, boris.ostrov...@oracle.com wrote:
>>> CAUTION: This email originated from outside of the organization. Do not
>>> click links or open attachmen
On 9/21/20 5:54 PM, Anchal Agarwal wrote:
> Thanks for the above suggestion. You are right I didn't find a way to declare
> a global state either. I just broke the above check in 2 so that once we have
> support for ARM we should be able to remove aarch64 condition easily. Let me
> know if I am m
>>
>>
> +
> +static int xen_setup_pm_notifier(void)
> +{
> + if (!xen_hvm_domain() || xen_initial_domain())
> + return -ENODEV;
I don't think this works anymore.
>>> What do you mean?
>>> The first check is for xen domain types and other is for archi
On 9/14/20 5:47 PM, Anchal Agarwal wrote:
> On Sun, Sep 13, 2020 at 11:43:30AM -0400, boris.ostrov...@oracle.com wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>> the content is safe
On 8/21/20 6:30 PM, Anchal Agarwal wrote:
> Save/restore xen_sched_clock_offset in syscore suspend/resume during PM
> hibernation. Commit '867cefb4cb1012: ("xen: Fix x86 sched_clock() interface
> for xen")' fixes xen guest time handling during migration. A similar issue
> is seen during PM hibern
On 8/21/20 6:27 PM, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> Add Xen PVHVM specific system core callbacks for PM
> hibernation support. The callbacks suspend and resume
> Xen primitives like shared_info, pvclock and grant table.
> These syscore_ops are specifically for domU hibernation.
On 8/21/20 6:25 PM, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> Guest hibernation is different from xen suspend/resume/live migration.
> Xen save/restore does not use pm_ops as is needed by guest hibernation.
> Hibernation in guest follows ACPI path and is guest inititated , the
> hibern
On 8/21/20 6:26 PM, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> Since commit b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for
> suspend/resume/chkpt"), xenbus uses PMSG_FREEZE, PMSG_THAW and
> PMSG_RESTORE events for Xen suspend. However, they're actually assigned
> to xenbus_dev
On 8/21/20 6:25 PM, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> Guest hibernation is different from xen suspend/resume/live migration.
> Xen save/restore does not use pm_ops as is needed by guest hibernation.
> Hibernation in guest follows ACPI path and is guest inititated , the
> hibe
On 8/21/20 6:22 PM, Anchal Agarwal wrote:
>
> Known issues:
> 1.KASLR causes intermittent hibernation failures. VM fails to resumes and
> has to be restarted. I will investigate this issue separately and shouldn't
> be a blocker for this patch series.
Is there any change in status for this? Thi
On 8/4/20 7:42 PM, Anchal Agarwal wrote:
>
> I think this could be done. PM_HIBERNATION_PREPARE could return -ENOTSUPP
> for arm and pvh dom0 when the notifier call chain is invoked for this case
> in hibernate(). This will then be an empty notifier just for checking two
> usecases.
> Also, for pvh
On 7/30/20 7:06 PM, Anchal Agarwal wrote:
> On Mon, Jul 27, 2020 at 06:08:29PM -0400, Boris Ostrovsky wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>>
On 7/24/20 7:01 PM, Stefano Stabellini wrote:
> Yes, it does, thank you. I'd rather not introduce unknown regressions so
> I would recommend to add an arch-specific check on registering
> freeze/thaw/restore handlers. Maybe something like the following:
>
> #ifdef CONFIG_X86
> .freeze = blkfron
On 7/22/20 2:02 PM, Anchal Agarwal wrote:
> On Tue, Jul 21, 2020 at 05:18:34PM -0700, Stefano Stabellini wrote:
>>
>>
>>> If you are not sure what the effects are (or sure that it won't work) on
>>> ARM then I'd add IS_ENABLED(CONFIG_X86) check, i.e.
>>>
>>>
>>> if (!IS_ENABLED(CONFIG_X86) || !xen_
>> +static int xen_setup_pm_notifier(void)
>> +{
>> + if (!xen_hvm_domain())
>> + return -ENODEV;
>>
>> I forgot --- what did we decide about non-x86 (i.e. ARM)?
> It would be great to support that however, its out of
> scope for this patch set.
>>
(Roger, question for you at the very end)
On 7/17/20 3:10 PM, Anchal Agarwal wrote:
> On Wed, Jul 15, 2020 at 05:18:08PM -0400, Boris Ostrovsky wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can con
On 7/15/20 4:49 PM, Anchal Agarwal wrote:
> On Mon, Jul 13, 2020 at 11:52:01AM -0400, Boris Ostrovsky wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>>
On 7/15/20 3:49 PM, Anchal Agarwal wrote:
> On Mon, Jul 13, 2020 at 03:43:33PM -0400, Boris Ostrovsky wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>>
On 7/10/20 2:17 PM, Agarwal, Anchal wrote:
> Gentle ping on this series.
Have you tested save/restore?
-bois
On 7/2/20 2:21 PM, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> Guest hibernation is different from xen suspend/resume/live migration.
> Xen save/restore does not use pm_ops as is needed by guest hibernation.
> Hibernation in guest follows ACPI path and is guest inititated , the
> hibernation
On 6/8/20 12:52 PM, Anchal Agarwal wrote:
>
> +void xen_hvm_map_shared_info(void)
> +{
> + xen_hvm_init_shared_info();
> + if (shared_info_pfn)
> + HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
> +}
> +
AFAICT it is only called once s
On 6/4/20 7:03 PM, Anchal Agarwal wrote:
> On Sat, May 30, 2020 at 07:02:01PM -0400, Boris Ostrovsky wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>>
On 6/3/20 6:40 PM, Agarwal, Anchal wrote:
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> On 5/19/20 7:26 PM, Anchal Agarwal wrote:
> > From: Munehisa
On 6/1/20 5:00 PM, Agarwal, Anchal wrote:
>
>
> I don't see these last two used anywhere. Are you, in fact,
> distinguishing between PM suspend and hibernation?
>
> Yes, I am. Unless there is a better way to distinguish at runtime which I
> haven't figured out yet.
> The initial desig
On 5/19/20 7:28 PM, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> Save steal clock values of all present CPUs in the system core ops
> suspend callbacks. Also, restore a boot CPU's steal clock in the system
> core resume callback. For non-boot CPUs, restore after they're brought
> up, because
On 5/19/20 7:28 PM, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> Currently, steal time accounting code in scheduler expects steal clock
> callback to provide monotonically increasing value. If the accounting
> code receives a smaller value than previous one, it uses a negative
> value to calc
On 5/19/20 7:26 PM, Anchal Agarwal wrote:
> Many legacy device drivers do not implement power management (PM)
> functions which means that interrupts requested by these drivers stay
> in active state when the kernel is hibernated.
>
> This does not matter on bare metal and on most hypervisors becau
On 5/19/20 7:26 PM, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> Add Xen PVHVM specific system core callbacks for PM suspend and
> hibernation support. The callbacks suspend and resume Xen
> primitives,like shared_info, pvclock and grant table. Note that
> Xen suspend can handle them in a dif
On 5/19/20 7:25 PM, Anchal Agarwal wrote:
> Introduce a small function which re-uses shared page's PA allocated
> during guest initialization time in reserve_shared_info() and not
> allocate new page during resume flow.
> It also does the mapping of shared_info_page by calling
> xen_hvm_init_share
On 5/19/20 7:25 PM, Anchal Agarwal wrote:
>
> int xenbus_dev_resume(struct device *dev)
> {
> - int err;
> + int err = 0;
That's not necessary.
> struct xenbus_driver *drv;
> struct xenbus_device *xdev
> = container_of(dev, struct xenbus_device, dev);
> -
>
On 5/19/20 7:24 PM, Anchal Agarwal wrote:
>
> +enum suspend_modes {
> + NO_SUSPEND = 0,
> + XEN_SUSPEND,
> + PM_SUSPEND,
> + PM_HIBERNATION,
> +};
> +
> +/* Protected by pm_mutex */
> +static enum suspend_modes suspend_mode = NO_SUSPEND;
> +
> +bool xen_suspend_mode_is_xen_suspend
)
>
> Signed-off-by: Jason Andryuk
> Cc: Eduardo Otubo
Reviewed-by: Boris Ostrovsky
we fail to recreate the queues so check for this
> in the open function.
>
> Signed-off-by: Ross Lagerwall
Reviewed-by: Boris Ostrovsky
ate would communicate the netback to create its
> device and establish the connection between them.
>
> Signed-off-by: Eduardo Otubo
Reviewed-by: Boris Ostrovsky
Should this go to stable trees as well?
-boris
> ---
> drivers/net/xen-netfront.c | 1 +
> 1 file changed, 1 inser
driver, the network
>> will become unreachable immediately, the guest can no longer be pinged.
>>
>> xen_net{front|back} should not allow the user to set this value which causes
>> network problems.
>>
>> Reported-by: Chen Shi
>> Signed-off-by: Mohammed Gamal
t;>> drivers/xen/gntdev.c | 11 ++-
>>> 1 file changed, 6 insertions(+), 5 deletions(-)
>> Reviewed-by: Boris Ostrovsky
> Is there a tree that can take this change? Turns out it is better to
> propagate changes via separate trees and only leftovers can be taken via
> Greg's tree.
>
Sure, we can take it via Xen tree for rc3.
-boris
t;
> Signed-off-by: Elena Reshetova
> Signed-off-by: Hans Liljestrand
> Signed-off-by: Kees Cook
> Signed-off-by: David Windsor
> ---
> drivers/xen/gntdev.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
Reviewed-by: Boris Ostrovsky
On 03/02/2017 06:56 AM, Juergen Gross wrote:
> With commits f16f1df65 and 9a6cdf52b we get in our Xen testing:
>
> [ 174.512861] switch: port 2(vif3.0) entered disabled state
> [ 174.522735] BUG: sleeping function called from invalid context at
> /home/build/linux-linus/mm/vmalloc.c:1441
> [ 174
On 02/03/2017 04:38 AM, Juergen Gross wrote:
On 30/01/17 18:45, Boris Ostrovsky wrote:
rx_refill_timer should be deleted as soon as we disconnect from the
backend since otherwise it is possible for the timer to go off before
we get to xennet_destroy_queues(). If this happens we may
ng network stress and OOM)
> Reported-by: Boris Ostrovsky
Reviewed-by: Boris Ostrovsky
info->queues = NULL;
> + goto out;
> + }
I think it might be better to kfree() in xennet_create_queues() (and set
num_queues to zero, while at it). But either way:
Reviewed-by: Boris Ostrovsky
>
> /* Create shared ring, alloc event channel -- f
On 02/07/2017 09:55 AM, Ross Lagerwall wrote:
> This fixes a crash when running out of grant refs when creating many
> queues across many netdevs.
>
> * If creating queues fails (i.e. there are no grant refs available),
> call xenbus_dev_fatal() to ensure that the xenbus device is set to the
> clos
On 02/02/2017 09:54 AM, Ross Lagerwall wrote:
> On 02/01/2017 06:54 PM, Boris Ostrovsky wrote:
>> On 02/01/2017 10:50 AM, Ross Lagerwall wrote:
>>> Improve error handling during initialization. This fixes a crash when
>>> running out of grant refs when creating many que
On 01/31/2017 12:47 PM, Boris Ostrovsky wrote:
> On 01/30/2017 02:31 PM, Boris Ostrovsky wrote:
>> On 01/30/2017 02:06 PM, Eric Dumazet wrote:
>>> On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
>>>
>>>> We do netif_carrier_off() first thing in x
On 02/01/2017 10:50 AM, Ross Lagerwall wrote:
> Improve error handling during initialization. This fixes a crash when
> running out of grant refs when creating many queues across many netdevs.
>
> * Delay timer creation so that if initializing a queue fails, the timer
> has not been setup yet.
> *
On 01/30/2017 02:31 PM, Boris Ostrovsky wrote:
> On 01/30/2017 02:06 PM, Eric Dumazet wrote:
>> On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
>>
>>> We do netif_carrier_off() first thing in xennet_disconnect_backend() and
>>> the only pl
On 01/30/2017 02:06 PM, Eric Dumazet wrote:
> On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
>
>> We do netif_carrier_off() first thing in xennet_disconnect_backend() and
>> the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
>> which is gua
On 01/30/2017 01:07 PM, Eric Dumazet wrote:
> On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote:
>> rx_refill_timer should be deleted as soon as we disconnect from the
>> backend since otherwise it is possible for the timer to go off before
>> we get to xennet_dest
rx_refill_timer should be deleted as soon as we disconnect from the
backend since otherwise it is possible for the timer to go off before
we get to xennet_destroy_queues(). If this happens we may dereference
queue->rx.sring which is set to NULL in xennet_disconnect_backend().
Signed-off-by: Bo
On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:
>
>> 2. It tickles a latent bug during resume where the timer triggers
>> before we re-connect. The trouble is that we now try to dereference
>> queue->rx.sring which is NULL since we disconnect in
>> netfront_resume(). (Curiously, I only observ
On 01/10/2017 08:32 AM, Juergen Gross wrote:
The Xen network frontend/backend supports multiple tx/rx queues for one
virtual interface. The number of queues supported by the backend is
set to the number of cpus of the backend driver domain (usually dom0)
and the number of queues requested by th
On 01/19/2017 11:35 AM, Vineeth Remanan Pillai wrote:
From: Vineeth Remanan Pillai
During an OOM scenario, request slots could not be created as skb
allocation fails. So the netback cannot pass in packets and netfront
wrongly assumes that there is no more work to be done and it disables
polli
ze * sizeof(*new_ring), GFP_KERNEL);
> if (!new_ring)
> return -ENOMEM;
>
Xen bits:
Reviewed-by: Boris Ostrovsky
e CPUs if user has not
> + /* Allow as many queues as there are CPUs inut max. 8 if user has not
Based on comment change in the second patch: s/inut/but/ ? Also, comment
style in both patches.
Other than that, for both:
Reviewed-by: Boris Ostrovsky
>* specified a
> + if (count_strings(body, msg->hdr.len) != 2) {
> + err = -EINVAL;
xenbus_write_watch() returns -EILSEQ when this type of error is
encountered so perhaps for we should return the same error here.
Either way
Reviewed-by: Boris Ostrovsky
On 10/19/2015 01:37 AM, Joe Jin wrote:
Sometimes xennet_create_queues() may failed to created all requested
queues, we need to update num_queues to real created to avoid NULL
pointer dereference.
Signed-off-by: Joe Jin
Cc: Boris Ostrovsky
Cc: Konrad Rzeszutek Wilk
Cc: Wei Liu
Cc: Ian
On 10/16/2015 06:56 AM, Wei Liu wrote:
CC David and Boris (Konrad was already a recipient).
On Thu, Oct 15, 2015 at 10:34:15AM +0800, Joe Jin wrote:
Sometimes xennet_create_queues() may failed to created all requested
queues, we need to update num_queues to real created to avoid NULL
pointer
On 08/05/2015 08:33 AM, Julien Grall wrote:
On 05/08/15 13:19, Boris Ostrovsky wrote:
On 08/05/2015 06:51 AM, Julien Grall wrote:
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b
On 08/05/2015 06:51 AM, Julien Grall wrote:
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_
On 08/04/2015 02:12 PM, Julien Grall wrote:
/*
* We detect special mappings in one of two ways:
@@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned long
mfn)
/* VIRT <-> MACHINE conversion */
#define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
On 07/29/2015 10:23 AM, Julien Grall wrote:
On 29/07/15 15:14, Boris Ostrovsky wrote:
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
But you'd stil
On 07/29/2015 07:25 AM, Julien Grall wrote:
Hi Boris,
On 28/07/15 20:12, Boris Ostrovsky wrote:
On 07/28/2015 11:02 AM, Julien Grall wrote:
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This
On 07/28/2015 11:02 AM, Julien Grall wrote:
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This brough some misimplementation of helpers on ARM and make the
developper confused the expected behavior.
instances) before freeing the netdevice.
Signed-off-by: David Vrabel
Reviewed-by: Boris Ostrovsky
---
drivers/net/xen-netfront.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 3f45afd
71 matches
Mail list logo
