On 3/23/20 12:15 PM, Yan Yankovskyi wrote:
> Make event channel functions pass event channel port using
> evtchn_port_t type. It eliminates signed <-> unsigned conversion.
>
> Signed-off-by: Yan Yankovskyi
If the difference is only the whitespace fix then
Reviewed-by: Boris
;>>>
>>>>> 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/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 inte
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 Biesh
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 +93,24
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
>> unbind_from_i
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 1/8/20 10:20 AM, Sergey Dyasli wrote:
@@ -1943,6 +1973,15 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
unsigned long max_pfn)
if (i && i < pgd_index(__START_KERNEL_map))
init_top_pgt[i] = ((pgd_t *)xen_start_info->pt_base)[i];
+#ifdef CONFIG_KASAN
+
On 1/7/20 6:37 PM, Anchal Agarwal wrote:
+
+static int xen_setup_pm_notifier(void)
+{
+ if (!xen_hvm_domain())
+ return -ENODEV;
ARM guests are also HVM domains. Is it OK for them to register the
notifier? The diffstat suggests that you are supporting ARM.
-boris
+
+
On 1/9/20 6:46 PM, Boris Ostrovsky wrote:
On 1/7/20 6:37 PM, Anchal Agarwal wrote:
+
+static int xen_setup_pm_notifier(void)
+{
+ if (!xen_hvm_domain())
+ return -ENODEV;
ARM guests are also HVM domains. Is it OK for them to register the
notifier? The diffstat suggests that you
On 1/10/20 10:43 PM, Marek Marczykowski-Górecki wrote:
@@ -117,6 +117,24 @@ static int command_write(struct pci_dev *dev, int offset,
u16 value, void *data)
pci_clear_mwi(dev);
}
+ if (dev_data && dev_data->allow_interrupt_control) {
+ if ((cmd->val ^
On 1/15/20 11:48 AM, Roger Pau Monné wrote:
On Wed, Jan 15, 2020 at 02:46:29AM +0100, Marek Marczykowski-Górecki wrote:
QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
MSI(-X) enable flags in the PCI config space. This adds an attribute
'allow_interrupt_control' which w
hvm guest")
in case the static memory maximum can't be read.
Fixes: 3aa6c19d2f38be ("xen/balloon: Support xend-based toolstack")
Signed-off-by: Juergen Gross
Cc: # 4.13
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
X
On 1/17/20 7:58 AM, Sergey Dyasli wrote:
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -13,6 +13,9 @@
#include
#include
+#include
+#include
+
#include
#include
#include
@@ -332,6 +335,11 @@ void __init kasan_early_init(void)
for (i = 0; pgta
On 1/22/20 3:07 PM, Anchal Agarwal wrote:
>> In this case tsc_verify_tsc_adjust(true) this does nothing as
>> feature bit X86_FEATURE_TSC_ADJUST is not available to guest.
Is it not available to your specific guest? Because AFAICT it is
available in general (to HVM/PVH guests).
> 4. Also, th
On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 27, 2020 at 03:45:11PM +0100, Jürgen Groß wrote:
>> On 27.01.20 14:16, Ilpo Järvinen wrote:
>>> Hi,
>>>
>>> I've noted that 5.5-rcs and now 5.5-based kernel fails to boot in VM.
>>> 5.4 based kernels worked fine and there seems t
On 1/27/20 6:29 PM, Boris Ostrovsky wrote:
>
>
> On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
>> On Mon, Jan 27, 2020 at 03:45:11PM +0100, Jürgen Groß wrote:
>>> On 27.01.20 14:16, Ilpo Järvinen wrote:
>>>> Hi,
>>>>
>>>> I
(Sorry, with proper addressing now)
On 1/27/20 6:29 PM, Boris Ostrovsky wrote:
>
>
> On 1/27/20 4:37 PM, Marek Marczykowski-Górecki wrote:
>>
>>>> Loading Linux 5.5.0-accecn30 ...
>>>>
>>>> .[5;22H [ initrd.img-5.5.0-acc 16.52MiB 100% 10.
nen
Tested-by: Ilpo Järvinen
Signed-off-by: Boris Ostrovsky
---
drivers/xen/gntdev.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 4fc83e3f5ad3..0258415ca0b2 100644
--- a/drivers/xen/gntdev.c
+++ b/
On 1/27/20 3:18 AM, sjp...@amazon.com wrote:
> From: SeongJae Park
>
> Granting pages consumes backend system memory. In systems configured
> with insufficient spare memory for those pages, it can cause a memory
> pressure situation. However, finding the optimal amount of the spare
> memory is
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
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
y consulted for 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
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
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
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
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
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/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 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 x86
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 7:51 AM, Jan Beulich wrote:
> On 20.01.2021 23:49, Boris Ostrovsky wrote:
>
>> +
>> +/*
>> + * Accesses to unimplemented MSRs as part of emulation of instructions
>> + * other than guest's RDMSR/WRMSR should never succeed.
>> +
On 21-01-25 11:22:08, Jan Beulich wrote:
> On 22.01.2021 20:52, Boris Ostrovsky wrote:
> > On 1/22/21 7:51 AM, Jan Beulich wrote:
> >> On 20.01.2021 23:49, Boris Ostrovsky wrote:
> >>> +
> >>> +/*
> >>> + * Accesses to unimplem
On 21-01-26 10:05:47, Jan Beulich wrote:
> On 25.01.2021 19:42, Boris Ostrovsky wrote:
> > On 21-01-25 11:22:08, Jan Beulich wrote:
> >> On 22.01.2021 20:52, Boris Ostrovsky wrote:
> >>> On 1/22/21 7:51 AM, Jan Beulich wrote:
> >>>&g
On 1/26/21 12:01 PM, David Woodhouse wrote:
> From: David Woodhouse
>
> In commit 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI")
> I reworked the triggering of xenbus_probe().
>
> I tried to simplify things by taking out the workqueue based startup
> triggered from wake_waiting
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: libxl_device.c:1105:device_backend_callbac
On 1/22/21 6:51 AM, Jan Beulich wrote:
> Also, Andrew, (I think I did say so before) - I definitely
> would want your general consent with this model, as what gets
> altered here is almost all relatively recent contributions
> by you. Nor would I exclude the approach being controversial.
>
Andre
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 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
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(&info->is_active, 0);
Can this be done in lateeoi_ack_dynirq()/lateeoi_mask_ack_dynirq(
being rogue on purpose.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On 2/18/21 10:57 AM, Jan Beulich wrote:
> On 18.02.2021 16:52, Roger Pau Monné wrote:
>> On Thu, Feb 18, 2021 at 12:54:13PM +0100, Jan Beulich wrote:
>>> On 18.02.2021 11:42, Roger Pau Monné wrote:
Not that you need to implement the full thing now, but maybe we could
have something like
On 2/18/21 5:51 AM, Roger Pau Monné wrote:
> On Wed, Jan 20, 2021 at 05:49:10PM -0500, Boris Ostrovsky wrote:
>> 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
On 2/18/21 6:48 AM, Roger Pau Monné wrote:
>
>> +/* Get the domain's default policy. */
>> +nr_leaves = 0;
>> +rc = xc_get_system_cpu_policy(xch, di.hvm ?
>> XEN_SYSCTL_cpu_policy_hvm_default
>> + :
>> XEN_SYSCTL_cpu_policy_pv_default,
>>
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 X
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/22/21 6:08 AM, Roger Pau Monné wrote:
> On Fri, Feb 19, 2021 at 09:56:32AM -0500, Boris Ostrovsky wrote:
>> On 2/18/21 5:51 AM, Roger Pau Monné wrote:
>>> On Wed, Jan 20, 2021 at 05:49:10PM -0500, Boris Ostrovsky wrote:
>>>> When toolstack updates MSR policy,
t;>>>> On 22.02.2021 22:19, Boris Ostrovsky wrote:
>>>>>> On 2/22/21 6:08 AM, Roger Pau Monné wrote:
>>>>>>> On Fri, Feb 19, 2021 at 09:56:32AM -0500, Boris Ostrovsky wrote:
>>>>>>>> On 2/18/21 5:51 AM, Roger Pau Monné wrote:
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
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: K
On 2/23/21 11:11 AM, Roger Pau Monné wrote:
> On Tue, Feb 23, 2021 at 10:39:48AM -0500, Boris Ostrovsky wrote:
>
>> Before I do that though --- what was the conclusion on verbosity control?
> Ideally I would like to find a way to have a more generic interface to
> change verbos
On 2/23/21 1:02 PM, Roger Pau Monné wrote:
> On Tue, Feb 23, 2021 at 11:40:07AM -0500, Boris Ostrovsky wrote:
>> On 2/23/21 11:11 AM, Roger Pau Monné wrote:
>>> On Tue, Feb 23, 2021 at 10:39:48AM -0500, Boris Ostrovsky wrote:
>>>
>>>> Before I do tha
On 2/23/21 1:28 PM, Oleksandr Andrushchenko wrote:
> Hello, Jan!
>
> On 2/23/21 6:26 PM, Jan Beulich wrote:
>> In order for subsequent unmapping to not mistakenly unmap handle 0,
>> record a perceived always-invalid one instead.
>>
>> Signed-off-by: Jan Beulich
>> Reviewed-by: Juergen Gross
> R
at code.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Boris Ostrovsky
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/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
>>
(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/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
>> +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/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
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_
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
>> +++ b/drivers/xen/unpopulated
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/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/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 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
rm_parameters, &pp) == 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/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
>
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:
> @@ -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 = PVOP
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/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, a
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
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] Documentation/core-api/pin_user_page
On 3/19/20 3:14 AM, Juergen Gross wrote:
> There have been reports of races in evtchn_from_irq() where the info
> pointer has been NULL.
>
> Avoid that case by testing info before dereferencing it.
>
> In order to avoid accessing a just freed info structure do the kfree()
> via kfree_rcu().
Looks
On 4/28/20 11:36 AM, Wei Liu wrote:
> All callers within the same file pass in -1 (no override).
>
> Signed-off-by: Wei Liu
Reviewed-by: Boris Ostrovsky
On 5/21/20 2:46 PM, Marek Marczykowski-Górecki wrote:
> On Thu, May 21, 2020 at 01:22:03PM -0400, Boris Ostrovsky wrote:
>> On 3/19/20 3:14 AM, Juergen Gross wrote:
>>> There have been reports of races in evtchn_from_irq() where the info
>>> pointer has been NULL.
On 5/20/20 7:45 PM, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Call dma_to_phys in is_xen_swiotlb_buffer.
> Call phys_to_dma in xen_phys_to_bus.
> Call dma_to_phys in xen_bus_to_phys.
>
> Everything is taken care of by these changes except for
> xen_swiotlb_alloc_coherent and xen_swi
On 5/22/20 1:34 PM, Stefano Stabellini wrote:
> On Thu, 21 May 2020, Boris Ostrovsky wrote:
>> On 5/20/20 7:45 PM, Stefano Stabellini wrote:
>>> From: Stefano Stabellini
>>>
>>> Call dma_to_phys in is_xen_swiotlb_buffer.
>>> Call phys_to_dm
On 5/27/20 1:43 PM, Bjorn Helgaas wrote:
> @@ -155,8 +157,8 @@ int xen_pcibk_config_read(struct pci_dev *dev, int
> offset, int size,
> u32 value = 0, tmp_val;
>
> if (unlikely(verbose_request))
> - printk(KERN_DEBUG DRV_NAME ": %s: read %d bytes at 0x%x\n",
> -
intended.
>
> Signed-off-by: Bjorn Helgaas
Reviewed-by: Boris Ostrovsky
On 5/27/20 6:50 PM, Bjorn Helgaas wrote:
> On Wed, May 27, 2020 at 03:34:26PM -0700, Boris Ostrovsky wrote:
>> On 5/27/20 1:43 PM, Bjorn Helgaas wrote:
>>> @@ -155,8 +157,8 @@ int xen_pcibk_config_read(struct pci_dev *dev, int
>>> offset, int size,
>>> u32
Information printed under verbose_request is clearly used for debugging
only. Remove it and use dev_dbg() instead.
Signed-off-by: Boris Ostrovsky
---
drivers/pci/xen-pcifront.c | 27 +-
drivers/xen/xen-pciback/conf_space.c| 14
drivers
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
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: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: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: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: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: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 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 6/2/20 11:18 AM, Randy Dunlap wrote:
> On 6/2/20 3:37 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> News: The merge window has opened, so please do *not* add v5.9 material
>> to your linux-next included branches until after v5.8-rc1 has been
>> released.
>>
>> Changes since 20200529:
>>
> on x86_
On 6/2/20 5:51 PM, Stefano Stabellini wrote:
> I would like to ask the maintainers, Juergen, Boris, Konrad, whether you
> have any more feedback before I send v2 of the series.
I think I only had one comment and that's all. Most were from Julien.
-boris
>
> Cheers,
>
> Stefano
>
>
> On Wed, 2
On 6/4/20 1:46 PM, Boris Ostrovsky wrote:
> On 6/3/20 6:22 PM, Stefano Stabellini wrote:
>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>> index 0a6cb67f0fc4..60ef07440905 100644
>> --- a/drivers/xen/swiotlb-xen.c
>> +++ b/drivers/xen/swiotl
On 6/3/20 6:22 PM, Stefano Stabellini wrote:
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 0a6cb67f0fc4..60ef07440905 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -64,16 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct dev
dresses, and swiotlb-xen was written with the
> assumption that phys addr == dma addr.
>
> This series adds the phys_to_dma and dma_to_phys calls to make it work.
>
> Cheers,
>
> Stefano
(+ Julien)
Reviewed-by: Boris Ostrovsky
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/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/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/16/20 11:14 PM, 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.
>
> [1] Documentation/core-api/pin_user_pages.rst
>
> [2] "Explicit pinning of use
701 - 800 of 1149 matches
Mail list logo
