de is of no interest to anyone and therefore
should be removed.
Signed-off-by: Boris Ostrovsky
---
drivers/xen/Kconfig | 31 ---
drivers/xen/Makefile | 3 -
drivers/xen/pcpu.c| 35 ---
drivers/xen/xen-acpi-cpuhotplug.c | 446
On 4/6/21 6:51 AM, Luca Fancellu wrote:
> Unmask operation must be called with interrupt disabled,
> on preempt_rt spin_lock_irqsave/spin_unlock_irqrestore
> don't disable/enable interrupts, so use raw_* implementation
> and change lock variable in struct irq_info from spinlock_t
> to
On 4/6/21 5:35 PM, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> da3b45cbcb0f ("xen/evtchn: Change irq_info lock to raw_spinlock_t")
>
> Fixes tag
>
> Fixes: 25da4618af24 ("xen/events: don't unmask an event channel
>
> has these problem(s):
>
> - Subject has leading but no trailing
On 3/24/21 7:09 PM, Boris Ostrovsky wrote:
> On 3/24/21 8:24 AM, Roger Pau Monne wrote:
>> Hello,
>>
>> This is a proposal for an alternative fix for XSA-369 that instead of
>> special casing XEN_UNPOPULATED_ALLOC to size the p2m relies on making
>> XEN_BA
> Revert "xen: fix p2m size in dom0 for disabled memory hotplug case"
>
> arch/x86/include/asm/xen/page.h | 12
> arch/x86/xen/p2m.c | 7 ++-
> arch/x86/xen/setup.c| 16 ++--
> drivers/xen/Kconfig
On 3/17/21 7:04 AM, Roger Pau Monne wrote:
>
> /*
> - * Clamp the amount of extra memory to a XEN_EXTRA_MEM_RATIO
> - * factor the base size.
> + * Clamp the amount of extra memory to a EXTRA_MEM_RATIO
> + * factor the base size. On non-highmem systems, the base
> +
On 3/16/21 11:04 PM, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./drivers/xen/evtchn.c:412:2-5: WARNING: Use BUG_ON instead of if
> condition followed by BUG.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/xen/evtchn.c | 3 +--
> 1 file
On 3/6/21 11:18 AM, Juergen Gross wrote:
> Those are fixes for XSA-332.
>
> The rest of the V3 patches have been applied already. There is one
> additional fix in patch 2 which addresses network outages when a guest
> is doing reboot loops.
>
> Juergen Gross (3):
> xen/events: reset affinity
On 3/10/21 4:23 PM, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 1103e2826a9f ("xen/events: don't unmask an event channel when an eoi is
> pending")
>
> Fixes tag
>
> Fixes: 54c9de89895e0a36047 ("xen/events: add a new late EOI evtchn
> framework")
>
> has these problem(s):
>
> -
EOI evtchn framework")
> Reported-by: Julien Grall
> Signed-off-by: Juergen Gross
> Reviewed-by: Julien Grall
> ---
> V2:
> - introduce a lock around masking/unmasking
> - merge patch 3 into this one (Jan Beulich)
> V4:
> - don't set eoi masking flag in latee
On 3/8/21 7:28 AM, Juergen Gross wrote:
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -379,11 +379,6 @@ void xen_timer_resume(void)
> }
> }
>
> -static const struct pv_time_ops xen_time_ops __initconst = {
> - .sched_clock = xen_sched_clock,
> - .steal_clock =
On 3/1/21 9:11 AM, Rafael J. Wysocki wrote:
> On Sun, Feb 28, 2021 at 2:49 AM Boris Ostrovsky
> wrote:
>>
>> On 2/24/21 1:47 PM, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki
>>>
>>> The ACPI_DEBUG_PRINT() macro is used in a few pla
On 2/24/21 1:47 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The ACPI_DEBUG_PRINT() macro is used in a few places in
> xen-acpi-cpuhotplug.c and xen-acpi-memhotplug.c for printing debug
> messages, but that is questionable, because that macro belongs to
> ACPICA and it should not
at code.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Boris Ostrovsky
On 2/10/21 6:46 PM, Kees Cook wrote:
> As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org
> links with lore"), replace lkml.org links with lore to better use a
> single source that's more likely to stay available long-term.
>
> Signed-off-by: Kees C
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
On 2/22/21 4:03 PM, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 99bbb6e0b436 ("xen/events: don't unmask an event channel when an eoi is
> pending")
>
> Fixes tag
>
> Fixes: 54c9de89895e0a36047 ("xen/events: add a new late EOI evtchn
> framework")
>
> has these problem(s):
>
> -
On 2/19/21 10:40 AM, Juergen Gross wrote:
> For avoiding read- and write-tearing by the compiler use READ_ONCE()
> and WRITE_ONCE() for accessing the ring indices in evtchn.c.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 2/19/21 3:32 PM, Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
>> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
>>> So one thing that has been on my mind for a while: I'd really like
>>> to kill the separate dma ops in
being rogue on purpose.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 2/11/21 5:16 AM, Juergen Gross wrote:
> @@ -622,6 +623,7 @@ static void xen_irq_lateeoi_locked(struct irq_info *info,
> bool spurious)
> }
>
> info->eoi_time = 0;
> + smp_store_release(>is_active, 0);
Can this be done in lateeoi_ack_dynirq()/lateeoi_mask_ack_dynirq(),
On 2/6/21 5:49 AM, Juergen Gross wrote:
> Add sysfs nodes for each xenbus device showing event statistics (number
> of events and spurious events, number of associated event channels)
> and for setting a spurious event threshold in case a frontend is
> sending too many events without being rogue
the pointer 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 1/28/21 6:52 PM, Michael D Labriola wrote:
> Hey, everyone. I've run into problems starting up my Xen domUs as of
> the latest batch of stable updates. Whenever I try to create one, I
> get a bunch of block device errors like this:
>
> libxl: error:
On 1/19/21 8:25 PM, Sasha Levin wrote:
> From: David Woodhouse
>
> [ Upstream commit 3d7746bea92530e8695258a3cf3ddec7a135edd6 ]
Sasha, you will also want
https://lore.kernel.org/lkml/20210115191123.27572-1-rdun...@infradead.org/, it
is sitting in Xen staging tree.
-boris
On 1/14/21 2:40 PM, Josh Poimboeuf wrote:
> It's kernel policy to not have (unannotated) indirect jumps because of
> Spectre v2. This one's probably harmless, but better safe than sorry.
> Convert it to a retpoline.
>
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Signed-o
ge don't matter, since it
> gets mapped to the hypervisor. Make it more palatable to objtool by
> making each hypervisor function a true empty function, with nops and a
> return.
>
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Signed-off-by: Josh Poimboeuf
Reviewed-by: Boris Ostrovsky
On 1/14/21 2:40 PM, Josh Poimboeuf wrote:
> The OBJECT_FILES_NON_STANDARD annotation is used to tell objtool to
> ignore a file. File-level ignores won't work when validating vmlinux.o.
>
> Tweak the ELF metadata and unwind hints to allow objtool to follow the
> code.
>
>
On 1/11/21 10:29 AM, Roger Pau Monne wrote:
>
> + xdata.domid = kdata.dom;
> + xdata.type = kdata.type;
> + xdata.id = kdata.id;
> +
> + if (!kdata.addr && !kdata.num) {
I think we should not allow only one of them to be zero. If it's only kdata.num
then we will end up with
On 12/15/20 6:10 AM, Juergen Gross wrote:
> In case a process waits for any Xenstore action in the xenbus driver
> it should be interruptible by signals.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - don't special case SIGKILL as libxenstore is handling -EINTR fine
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
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(
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()
On 12/9/20 5:11 AM, Juergen Gross wrote:
> In case a process waits for any Xenstore action in the xenbus driver
> it should be interruptible via SIGKILL.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
e or next_allocated_page?
Either way
Reviewed-by: Boris Ostrovsky
On 12/7/20 8:30 AM, Juergen Gross wrote:
> Instead of having similar helpers in multiple backend drivers use
> common helpers for caching pages allocated via gnttab_alloc_pages().
>
> Make use of those helpers in blkback and scsiback.
>
> Signed-off-by: Juergen Gross
tialising:
> case XenbusStateInitialised:
> case XenbusStateReconfiguring:
Reviewed-by Boris Ostrovsky
(for patch 138 as well)
Although I thought using 'fallthrough' attribute was the more common approach.
-boris
On 11/9/20 12:34 AM, Jürgen Groß wrote:
> On 07.11.20 02:11, Brian Masney wrote:
>> When booting a hyperthreaded system with the kernel parameter
>> 'mitigations=auto,nosmt', the following warning occurs:
>>
>> WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
>>
On 11/5/20 7:47 PM, Brian Masney wrote:
> On Thu, Nov 05, 2020 at 07:35:29PM -0500, Brian Masney wrote:
>> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
>> index 799f4eba0a62..4a052459a08e 100644
>> --- a/arch/x86/xen/spinlock.c
>> +++ b/arch/x86/xen/spinlock.c
>> @@ -93,9
On 10/22/20 5:49 AM, Juergen Gross wrote:
> Do some cleanups in Xen event handling code.
>
> Changes in V2:
> - addressed comments
>
> Juergen Gross (5):
> xen: remove no longer used functions
> xen/events: make struct irq_info private to events_base.c
> xen/events: only register debug
On 10/15/20 9:10 AM, Andrew Cooper wrote:
> On 15/10/2020 13:37, boris.ostrov...@oracle.com wrote:
>> On 10/14/20 1:53 PM, Jason Andryuk wrote:
>>> +config XEN_512GB
>>> + bool "Limit Xen pv-domain memory to 512GB"
>>> + depends on XEN_PV && X86_64
>> Why is X86_64 needed here?
>> 512G
On 10/14/20 1:53 PM, Jason Andryuk wrote:
> +config XEN_512GB
> + bool "Limit Xen pv-domain memory to 512GB"
> + depends on XEN_PV && X86_64
Why is X86_64 needed here?
-boris
> Link: https://lkml.kernel.org/r/20200926121402.GA7467@kadam
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Vishal Verma
> Cc: Vivek Goyal
> Cc: Dave Jiang
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Ira We
>>> 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
On 9/27/20 1:28 PM, Hui Su wrote:
> arch/x86: fix some typos in xen_pagetable_p2m_free():
> s/Fortunatly/Fortunately
>
> Signed-off-by: Hui Su
Applied to for-linus-5.10 (after rewording slightly the commit message)
-boris
or guests.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross
> Reviewed-by: Boris Ostrovsky
Applied to for-linus-5.10
-boris
On 9/24/20 7:49 PM, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> The VCPUOP_register_runstate_memory_area hypercall takes a virtual
> address of a buffer as a parameter. The semantics of the hypercall are
> such that the virtual address should always be valid.
>
> When KPTI is
On 9/18/20 11:17 PM, Jing Xiangfeng wrote:
> After commit 9f51c05dc41a ("pvcalls-front: Avoid
> get_free_pages(GFP_KERNEL) under spinlock"), the variable ret is being
> initialized with '-ENOMEM' that is meaningless. So remove it.
>
> Signed-off-by: Jing Xiangfeng
Applied to for-linus-5.10
gt;>> [1] Documentation/core-api/pin_user_pages.rst
>>>>>
>>>>> [2] "Explicit pinning of user-space pages":
>>>>> https://lwn.net/Articles/807108/
>>>>>
>>>>> Signed-off-by: Souptick Joarder
>>>&
30fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to
> store a per interrupt XEN data pointer which contains XEN specific
> information.")
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
+Lennart
On 9/29/20 9:36 AM, Philipp Rudo wrote:
> Hi,
>
> On Fri, 25 Sep 2020 10:56:25 -0400
> Konrad Rzeszutek Wilk wrote:
>
>> On Fri, Sep 25, 2020 at 11:05:58AM +0800, Dave Young wrote:
>>> Hi,
>>>
>>> On 09/24/20 at 01:16pm, boris.ostrov...@oracle.com wrote:
On 9/24/20 12:43 PM,
. [1] & [2] could
>>> be referred for more information. This is case 5 as per document [1].
>>>
>>> [1] Documentation/core-api/pin_user_pages.rst
>>>
>>> [2] "Explicit pinning of user-space pages":
>>> https://lwn.net/Articles/8
On 9/25/20 3:12 PM, Dan Williams wrote:
>
> diff --git a/drivers/xen/unpopulated-alloc.c b/drivers/xen/unpopulated-alloc.c
> index 3b98dc921426..091b8669eca3 100644
> --- a/drivers/xen/unpopulated-alloc.c
> +++ b/drivers/xen/unpopulated-alloc.c
> @@ -18,27 +18,37 @@ static unsigned int
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
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
ctable memory
> + * errors, as this is the duty of the hypervisor to decide.
> + */
> + acpi_disable_cmcff = 1;
> +#endif
Not that it matters greatly but should this go under if (xen_initial_domain())
clause a bit further down?
Either way:
Reviewed-by: Boris Ostrovsky
On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replace the last call to alloc_vm_area with an open coded version using
> an iterator in struct gnttab_vm_area instead of the triple indirection
> magic in alloc_vm_area.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
On 9/24/20 9:58 AM, Christoph Hellwig wrote:
> Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
> allows to fill put the phys_addr values directly instead of doing
> another loop over all addresses.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
-boris
On 9/24/20 12:43 PM, Michael Kelley wrote:
> From: Eric W. Biederman Sent: Thursday, September 24,
> 2020 9:26 AM
>> Michael Kelley writes:
>>
> Added Hyper-V people and people who created the param, it is below
> commit, I also want to remove it if possible, let's see how people
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
On 9/22/20 11:27 AM, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 11:24:20AM -0400, boris.ostrov...@oracle.com wrote:
>> On 9/22/20 10:58 AM, Christoph Hellwig wrote:
>>> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
This will end up incrementing
On 9/22/20 10:58 AM, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
>> This will end up incrementing area->ptes pointer. So perhaps something like
>>
>>
>> pte_t **ptes = area->ptes;
>>
>> if (apply_to_page_range(_mm, (unsigned
On 9/22/20 6:58 AM, Philipp Rudo wrote:
>
> AFAIK pstore requires UEFI to work. So what's the point to enable it on
> non-UEFI
> systems?
I don't think UEFI is required, ERST can specify its own backend. And that, in
fact, can be quite useful in virtualization scenarios (especially in cases
On 9/18/20 12:37 PM, Christoph Hellwig wrote:
>
> +static int gnttab_apply(pte_t *pte, unsigned long addr, void *data)
> +{
> + pte_t ***p = data;
> +
> + **p = pte;
> + (*p)++;
> + return 0;
> +}
> +
> static int arch_gnttab_valloc(struct gnttab_vm_area *area, unsigned
>
>>
>>
> +
> +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
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
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
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
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
>
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
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
>
copy_batch, set
> it in gntdev_grant_copy_seg() (and drop `writeable` argument to
> gntdev_get_page()) and then, based on batch->writeable, use
> set_page_dirty_lock().
>
> Fixes: a4cdb556cae0 (xen/gntdev: add ioctl for grant copy)
> Suggested-by: Boris Ostrovsky
> Signed-off-by: Souptick J
umentation/core-api/pin_user_pages.rst
>
> [2] "Explicit pinning of user-space pages":
> https://lwn.net/Articles/807108/
>
> Signed-off-by: Souptick Joarder
> Cc: John Hubbard
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: David Vrabel
Reviewed-by: Boris Ostrovsky
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?
On 8/18/20 12:32 AM, Souptick Joarder wrote:
> In 2019, we introduced pin_user_pages*() and now we are converting
> get_user_pages*() to the new API as appropriate. [1] & [2] could
> be referred for more information. This is case 5 as per document [1].
>
> [1]
t;
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 8/15/20 6:06 AM, Juergen Gross wrote:
> The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone.
>
> Remove 32-bit specific parts.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
(There is another '#ifdef CONFIG_X86_64' in paravirt.h, at the b
On 8/10/20 12:39 AM, Jürgen Groß wrote:
> On 09.08.20 04:34, Boris Ostrovsky wrote:
>> On 8/7/20 4:38 AM, Juergen Gross wrote:
>>> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
>>> {
>>> pteval_t ret;
>>> - if (size
On 8/7/20 4:38 AM, Juergen Gross wrote:
> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
> {
> pteval_t ret;
>
> - if (sizeof(pteval_t) > sizeof(long))
> - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32);
> - else
> - ret =
On 8/7/20 4:38 AM, Juergen Gross wrote:
> With support for 32-bit pv guests gone pure pv-code no longer needs to
> test for highmem. Dropping those tests removes the need for flushing
> in some places.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
wi
On 8/7/20 4:38 AM, Juergen Gross wrote:
> With 32-bit pv-guest support removed xen-asm_64.S can be merged with
> xen-asm.S
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
except for
> diff --git a/arch/x86/xen/xen-asm.S b/arch/x86/xen/xen-asm.S
>
= 0)
> - top = pp.virt_start;
> -
> - reserve_top_address(-top);
> -#endif /* CONFIG_X86_32 */
> }
>
We should be able now to get rid of xen_reserve_top() altogether.
Other than that
Reviewed-by: Boris Ostrovsky
-boris
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
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/28/20 7:42 AM, Roger Pau Monne wrote:
> In order to protect against the header being included multiple times
> on the same compilation unit.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Boris Ostrovsky
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 =
On 7/24/20 10:34 AM, David Hildenbrand wrote:
> CCing Dan
>
> On 24.07.20 14:42, Roger Pau Monne wrote:
>> diff --git a/drivers/xen/unpopulated-alloc.c
>> b/drivers/xen/unpopulated-alloc.c
>> new file mode 100644
>> index ..aaa91cefbbf9
>> --- /dev/null
>> +++
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) ||
On 7/21/20 12:12 PM, Hayato Ohhashi wrote:
> If the TSC frequency is known from the pvclock page,
> the TSC frequency does not need to be recalibrated.
> We can avoid recalibration by setting X86_FEATURE_TSC_KNOWN_FREQ.
>
> Signed-off-by: Hayato Ohhashi
Reviewed-by: Boris Ostrovsky
>> +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.
On 7/16/20 5:06 AM, Qinglang Miao wrote:
> From: Chen Huang
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Chen Huang
Reviewed-by: Boris Ostrovsky
(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
>
On 7/1/20 8:16 AM, Juergen Gross wrote:
> Avoid allocating large amount of data on the stack in
> xenbus_map_ring_valloc() and some related return value cleanups.
>
> Juergen Gross (2):
> xen/xenbus: avoid large structs and arrays on the stack
> xen/xenbus: let xenbus_map_ring_valloc() return
On 7/2/20 7:24 PM, Andrew Cooper wrote:
> On 02/07/2020 23:59, Boris Ostrovsky wrote:
>> On 7/1/20 7:06 AM, Juergen Gross wrote:
>>>
>>> -#ifdef CONFIG_X86_PAE
>>> -static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
>>> -{
&
On 7/1/20 7:06 AM, Juergen Gross wrote:
> Xen is requiring 64-bit machines today and since Xen 4.14 it can be
> built without 32-bit PV guest support. There is no need to carry the
> burden of 32-bit PV guest support in the kernel any longer, as new
> guests can be either HVM or PVH, or they can
/hvm specific mapping
> functions to the single caller.
>
> Reported-by: Arnd Bergmann
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
1 - 100 of 3117 matches
Mail list logo
