On 1/22/21 6:51 AM, Jan Beulich wrote:
> On 20.01.2021 23:49, Boris Ostrovsky wrote:
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -295,7 +295,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
>> *val)
>> }
>>
>
On 1/22/21 1:33 PM, Julien Grall wrote:
>
> Thanks. In which case, I would suggest to move the definition of ignore_msrs
> in the idle to an x86 specific structure. Maybe "arch_x86"?
I did consider this but left it in common area since there are already a bunch
of fields there that are
On 1/22/21 4:56 AM, Julien Grall wrote:
> Hi Boris,
>
> On 20/01/2021 22:49, Boris Ostrovsky wrote:
>> diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c
>> index 19168572fd3e..1f2abf6679d7 100644
>> --- a/tools/libs/light/libxl_dom.c
>> +
On 1/22/21 4:52 AM, Julien Grall wrote:
> Hi Boris,
>
> On 20/01/2021 22:49, Boris Ostrovsky wrote:
>> This option allows guest administrator specify what should happen when
>> guest accesses an MSR which is not explicitly emulated by the hypervisor.
>>
>&g
On 1/21/21 9:56 AM, Wei Liu wrote:
> On Wed, Jan 20, 2021 at 05:49:09PM -0500, Boris Ostrovsky wrote:
>> This option allows guest administrator specify what should happen when
>> guest accesses an MSR which is not explicitly emulated by the hypervisor.
>>
>> Sig
When toolstack updates MSR policy, this MSR offset (which is the last
index in the hypervisor MSR range) is used to indicate hypervisor
behavior when guest accesses an MSR which is not explicitly emulated.
Signed-off-by: Boris Ostrovsky
---
Changes in v2:
* Use 0x42ff for MSR_UNHANDLED
When creating a guest, if ignore_msrs option has been specified,
apply it to guest's MSR policy.
Signed-off-by: Boris Ostrovsky
---
tools/include/xenctrl.h | 2 +
tools/libs/guest/Makefile | 1 +
tools/libs/guest/xg_msrs_x86.c| 110
ssing MSRs that
potentially may not be present.
Instead of special-casing RAPL registers we decide what to do when any
non-emulated MSR is accessed based on ignore_msrs field of msr_policy.
Signed-off-by: Boris Ostrovsky
---
Changes in v2:
* define x86_emul_guest_msr_access() and use it to determi
guest's MSR acceses
Boris Ostrovsky (4):
xl: Add support for ignore_msrs option
x86: Introduce MSR_UNHANDLED
x86: Allow non-faulting accesses to non-emulated MSRs if policy
permits this
tools/libs: Apply MSR policy to a guest
docs/man/xl.cfg.5.pod.in | 20 +-
too
This option allows guest administrator specify what should happen when
guest accesses an MSR which is not explicitly emulated by the hypervisor.
Signed-off-by: Boris Ostrovsky
---
docs/man/xl.cfg.5.pod.in | 20 +++-
tools/libs/light/libxl_types.idl | 7 +++
tools/xl
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/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 1/11/21 2:48 AM, Jan Beulich wrote:
> On 08.01.2021 21:39, boris.ostrov...@oracle.com wrote:
>> On 1/8/21 10:18 AM, Jan Beulich wrote:
>>
>>>
>>> Just to re-raise the question raised by Andrew already earlier
>>> on: Has Solaris been fixed in the meantime, or is this at least
>>> firmly
On 1/8/21 10:18 AM, Jan Beulich wrote:
> On 07.01.2021 21:34, Boris Ostrovsky wrote:
>> Starting with commit 84e848fd7a16 ("x86/hvm: disallow access to unknown
>> MSRs")
>> accesses to unhandled MSRs result in #GP sent to the guest. This caused a
>> regres
On 1/8/21 9:55 AM, Jan Beulich wrote:
> On 07.01.2021 21:34, Boris Ostrovsky wrote:
>> --- a/xen/include/xen/lib/x86/msr.h
>> +++ b/xen/include/xen/lib/x86/msr.h
>> @@ -2,8 +2,21 @@
>> #ifndef XEN_LIB_X86_MSR_H
>> #define XEN_LIB_X86_MSR_H
>>
>
Apparently I can't spell my own name. Please drop it from CC when responding.
-boris
When creating a guest, if ignore_msrs option has been specified,
apply it to guest's MSR policy.
Signed-off-by: Boris Ostrovsky
---
tools/include/xenctrl.h | 2 +
tools/libs/guest/Makefile | 1 +
tools/libs/guest/xg_msrs_x86.c| 110
est. This is default.
silent: MSR reads return 0, MSR writes are ignored. No warnings to the log.
verbose: Similar to silent but a warning is written.
Boris Ostrovsky (4):
xl: Add support for ignore_msrs option
x86: Introduce MSR_UNHANDLED
x86: Allow non-faulting accesses to non-emu
ssing MSRs that
potentially may not be present.
Instead of special-casing RAPL registers we decide what to do when any
non-emulated MSR is accessed based on ignore_msrs field of msr_policy.
Signed-off-by: Boris Ostrovsky
---
xen/arch/x86/hvm/svm/svm.c | 10 --
xen/arch/x86/hvm/vmx/vmx.
When toolstack updates MSR policy, this MSR offset (which is an invalid
MSR index) is used to indicate hypervisor behavior when a guest accesses
an MSR which is not explicitly emulated.
Signed-off-by: Boris Ostrovsky
---
xen/include/xen/lib/x86/msr.h | 17 -
xen/lib/x86/msr.c
This option allows guest administrator specify what should happen when
guest accesses an MSR which is not explicitly emulated by the hypervisor.
Signed-off-by: Boris Ostrovsky
---
docs/man/xl.cfg.5.pod.in | 20 +++-
tools/libs/light/libxl_types.idl | 7 +++
tools/xl
atible hypervisors,
> because there are guest kernels still in active use which use PCI INTX
> even when vector delivery is available.
>
> Signed-off-by: David Woodhouse
Reviewed-by: Boris Ostrovsky
w in the !vector_callback case; all three teardown functions
>it calls should be no-ops. But to guard against future regressions
>it's useful to call it anyway, and for it to explicitly check for
>xen_have_vector_callback before calling those additional functions.
>
> Signed-off-by: David Woodhouse
Reviewed-by: Boris Ostrovsky
Signed-off-by: David Woodhouse
Reviewed-by: Boris Ostrovsky
On 1/5/21 6:57 PM, David Woodhouse wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index c722ec19cd00..35b10982d363 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++
On 1/4/21 8:41 PM, David Woodhouse wrote:
> On Mon, 2021-01-04 at 18:44 -0500, boris.ostrov...@oracle.com wrote:
>> On 1/4/21 6:19 PM, David Woodhouse wrote:
>>> On Mon, 2021-01-04 at 18:04 -0500, boris.ostrov...@oracle.com
>>> wrote:
Why not xen_hvm_cpu_die too? common_cpu_die() sounds
On 1/4/21 6:19 PM, David Woodhouse wrote:
> On Mon, 2021-01-04 at 18:04 -0500, boris.ostrov...@oracle.com wrote:
>> On 1/4/21 5:37 PM, David Woodhouse wrote:
>>> @@ -33,9 +33,11 @@ static void __init
>>> xen_hvm_smp_prepare_cpus(unsigned int max_cpus)
>>> int cpu;
>>>
>>>
On 1/4/21 5:37 PM, David Woodhouse wrote:
>
> @@ -33,9 +33,11 @@ static void __init xen_hvm_smp_prepare_cpus(unsigned int
> max_cpus)
> int cpu;
>
> native_smp_prepare_cpus(max_cpus);
> - WARN_ON(xen_smp_intr_init(0));
>
> - xen_init_lock_cpu(0);
> + if
On 1/4/21 3:51 PM, David Woodhouse wrote:
> On Mon, 2021-01-04 at 14:06 -0500, boris.ostrov...@oracle.com wrote:
>>
>> OK, but we still need to do something about virt_spin_lock_key.
> Right, I suppose we should just call xen_init_spinlocks() and then my
> defensive check stops being defensive
On 1/4/21 12:32 PM, David Woodhouse wrote:
> On Mon, 2021-01-04 at 12:06 -0500, boris.ostrov...@oracle.com wrote:
>>> @@ -115,7 +115,7 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_vcpu_stolen);
>>> void __init xen_init_spinlocks(void)
>>> {
>>>/* Don't need to use pvqspinlock code if there is
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> When xen_have_vector_callback is false, we still register the PV spinlock
> kicker IPI on the secondary CPUs. Stop doing that.
>
> Signed-off-by: David Woodhouse
> ---
> arch/x86/xen/spinlock.c | 6 +++---
> 1 file
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> In the case where xen_have_vector_callback is false, we still register
> the IPI vectors in xen_smp_intr_init() for the secondary CPUs even
> though they aren't going to be used. Stop doing that.
>
> Signed-off-by: David
On 12/24/20 6:53 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> It's useful to be able to test non-vector event channel delivery, to make
> sure Linux will work properly on older Xen which doesn't have it.
>
> It's also useful for those working on Xen and Xen-compatible hypervisors,
>
ing to allow other CPUs
> to process CPU0's events, just ensure that the PCI interrupts happens
> only on CPU0.
>
> Signed-off-by: David Woodhouse
Reviewed-by: Boris Ostrovsky
atform device setup, is no longer needed.
>
> Signed-off-by: David Woodhouse
Reviewed-by: Boris Ostrovsky
On 12/21/20 3:21 AM, Jan Beulich wrote:
> On 18.12.2020 21:43, boris.ostrov...@oracle.com wrote:
>> Can we do something like KVM's ignore_msrs (but probably return 0 on reads
>> to avoid leaks from the system)? It would allow to deal with cases when a
>> guest is suddenly unable to boot after
On 12/19/20 3:05 AM, David Woodhouse wrote:
> On Fri, 2020-12-18 at 17:20 -0500, boris.ostrov...@oracle.com wrote:
>> Are there other cases where this would be useful? If it's just to
>> test a hypervisor under development I would think that people who are
>> doing that kind of work are capable
On 12/18/20 11:25 AM, David Woodhouse wrote:
> From: David Woodhouse
>
> For a while, event channel notification via the PCI platform device
> has been broken, because we attempt to communicate with xenstore before
> we even have notifications working, in the xs_reset_watches() call
> called
On 12/17/20 12:49 PM, boris.ostrov...@oracle.com wrote:
> On 12/17/20 11:46 AM, Andrew Cooper wrote:
>> On 17/12/2020 16:25, boris.ostrov...@oracle.com wrote:
>>> On 12/17/20 2:40 AM, Jan Beulich wrote:
On 17.12.2020 02:51, boris.ostrov...@oracle.com wrote:
I think this is acceptable
On 12/17/20 11:46 AM, Andrew Cooper wrote:
> On 17/12/2020 16:25, boris.ostrov...@oracle.com wrote:
>> On 12/17/20 2:40 AM, Jan Beulich wrote:
>>> On 17.12.2020 02:51, boris.ostrov...@oracle.com wrote:
>>> I think this is acceptable as a workaround, albeit we may want to
>>> consider further
On 12/17/20 2:40 AM, Jan Beulich wrote:
> On 17.12.2020 02:51, boris.ostrov...@oracle.com wrote:
> I think this is acceptable as a workaround, albeit we may want to
> consider further restricting this (at least on staging), like e.g.
> requiring a guest config setting to enable the workaround.
ing much about Solaris we only tried some
basic commands).
The patch below lets Solaris guest boot on OVM. Our codebase is somewhat
different from stable branches but if this is an acceptable workaround I will
send proper patch for stable. I won't be able to test it though.
Author: Boris Ostr
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:
> 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/10/20 2:26 PM, Thomas Gleixner wrote:
> Signed-off-by: Thomas Gleixner
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: xen-devel@lists.xenproject.org
> ---
> drivers/xen/events/events_base.c |6 --
> 1 file changed, 6 deletions(
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 11/4/20 5:14 PM, Ard Biesheuvel wrote:
> Now that we have a static inline helper to discover the platform's secure
> boot mode that can be shared between the EFI stub and the kernel proper,
> switch to it, and drop some comments about keeping them in sync manually.
>
> Signed-off-by: Ard
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 Fri, Jan 17, 2020 at 02:13:04PM -0500, Rich Persaud wrote:
>>>>>> On Aug 26, 2019, at 17:08, Pasi Kärkkäinen wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>> On Mon, Oct 08, 2018 at 10:32:45A
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
>>> 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/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
. [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 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/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/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
>
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?
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
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
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
301 - 400 of 1105 matches
Mail list logo
