On 11/16/20 3:58 PM, Christoph Hellwig wrote:
Use put_device to put the device instead of poking into the internals
and using kobject_put.
Signed-off-by: Christoph Hellwig
---
block/genhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/genhd.c b/block/genhd.c
inde
On 19.11.2020 18:57, Manuel Bouyer wrote:
> I added an ASSERT() after the printf to ket a stack trace, and got:
> db{0}> call ioapic_dump_raw^M
> Register dump of ioapic0^M
> [ 13.0193374] 00 0800 00170011 0800(XEN) vioapic.c:141:d0v0
> apic_mem_readl:undefined ioregsel 3
> (XEN) vioapic.
On Fri, Nov 20, 2020 at 09:09:51AM +0100, Jan Beulich wrote:
> On 19.11.2020 18:57, Manuel Bouyer wrote:
> > I added an ASSERT() after the printf to ket a stack trace, and got:
> > db{0}> call ioapic_dump_raw^M
> > Register dump of ioapic0^M
> > [ 13.0193374] 00 0800 00170011 0800(XEN) vio
I didn't bother figuring which commit(s) should have deleted them while
removing their last uses.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1402,7 +1402,6 @@ void desc_guest_eoi(struct irq_desc *des
{
irq_guest_action_t *action;
cpumask_t
On Thu, Nov 19, 2020 at 09:25:05AM +0100, Jan Kara wrote:
> OK, understood. Still it would seem more logical to leave blk_lookup_devt()
> declaration inside #ifdef CONFIG_BLOCK and just delete the !CONFIG_BLOCK
> definition (to make it clear we ever expect only users compiled when
> CONFIG_BLOCK is
On Fri, Nov 20, 2020 at 09:28:55AM +0100, Roger Pau Monné wrote:
> > i.e. at that point we're waiting for Dom0 to signal it's done handling
> > the IRQ. There is, however, a timer associated with this. Yet that's
> > actually to prevent the system getting stuck, i.e. the "in-flight"
> > state ought
On 20.11.2020 09:28, Roger Pau Monné wrote:
> On Fri, Nov 20, 2020 at 09:09:51AM +0100, Jan Beulich wrote:
>> On 19.11.2020 18:57, Manuel Bouyer wrote:
>>> I added an ASSERT() after the printf to ket a stack trace, and got:
>>> db{0}> call ioapic_dump_raw^M
>>> Register dump of ioapic0^M
>>> [ 13.
On Thu, Nov 19, 2020 at 10:41:57AM +0100, Jan Kara wrote:
> > rcu_assign_pointer(ptbl->part[0], &disk->part0);
> > @@ -1772,8 +1626,10 @@ struct gendisk *__alloc_disk_node(int minors, int
> > node_id)
> > * converted to make use of bd_mutex and sequence counters.
> > */
> > hd_se
On 11/16/20 3:58 PM, Christoph Hellwig wrote:
Instead of having two structures that represent each block device with
different lift time rules merged them into a single one. This also
greatly simplifies the reference counting rules, as we can use the inode
reference count as the main reference c
On 20.11.2020 09:52, Manuel Bouyer wrote:
> On Fri, Nov 20, 2020 at 09:28:55AM +0100, Roger Pau Monné wrote:
>>> i.e. at that point we're waiting for Dom0 to signal it's done handling
>>> the IRQ. There is, however, a timer associated with this. Yet that's
>>> actually to prevent the system getting
On Thu, Nov 19, 2020 at 11:32:53AM +0100, Jan Kara wrote:
> > @@ -1521,7 +1510,7 @@ static int __blkdev_get(struct block_device *bdev,
> > fmode_t mode, void *holder,
> > if (bdev->bd_bdi == &noop_backing_dev_info)
> > bdev->bd_bdi = bdi_get(disk->queue->backing_dev
On Thu, Nov 19, 2020 at 01:05:25PM +0100, Jan Kara wrote:
> > @@ -613,7 +613,7 @@ void guard_bio_eod(struct bio *bio)
> > rcu_read_lock();
> > part = __disk_get_part(bio->bi_disk, bio->bi_partno);
> > if (part)
> > - maxsector = part_nr_sects_read(part);
> > + maxsec
On 20.11.2020 09:48, Jan Beulich wrote:
> @@ -1663,13 +1661,11 @@ int pirq_guest_bind(struct vcpu *v, stru
Argh, there's yet one more in this function. Will need v2.
Jan
> static irq_guest_action_t *__pirq_guest_unbind(
> struct domain *d, struct pirq *pirq, struct irq_desc *desc)
> {
> -
On Fri, Nov 20, 2020 at 09:54:42AM +0100, Jan Beulich wrote:
> [...]
> >From the stack trace above the only possibility I could derive for
> now would be that we didn't run softirqs for a long time, but I don't
> think that's very realistic here. Otoh, Manuel, does the NMI watchdog
> work on that s
On Thu, Nov 19, 2020 at 03:39:21PM +0100, Jan Kara wrote:
> This patch is kind of difficult to review due to the size of mostly
> mechanical changes mixed with not completely mechanical changes. Can we
> perhaps split out the mechanical bits? E.g. the rq->part => rq->bdev
> renaming is mechanical a
On Thu, Nov 19, 2020 at 03:13:16PM +, Matthew Wilcox wrote:
> On Wed, Nov 18, 2020 at 09:47:57AM +0100, Christoph Hellwig wrote:
> > @@ -2887,13 +2887,13 @@ EXPORT_SYMBOL(filemap_map_pages);
> > vm_fault_t filemap_page_mkwrite(struct vm_fault *vmf)
> > {
> > struct page *page = vmf->page;
On Fri, Nov 20, 2020 at 09:59:57AM +0100, Jan Beulich wrote:
> Well, anything coming through the LAPIC needs ack-ing (except for
> the spurious interrupt of course), or else ISR won't get updated
> and further interrupts at this or lower priority can't be serviced
> (delivered) anymore. This includ
From: Paul Durrant
If hvm_guest_x86_mode() returns something other than 8 or 4 then
viridian_hypercall() will return immediately but, on the way out, will write
back status as if 'mode' was 4. This patch simply makes it leave the registers
alone.
NOTE: The formatting of the 'out' label and the s
From: Paul Durrant
This patch moves the implementation of HVCALL_SEND_IPI that is currently
inline in viridian_hypercall() into a new hvcall_ipi() function.
The new function returns Xen errno values similarly to hvcall_flush(). Hence
the errno translation code in viridial_hypercall() is generali
From: Paul Durrant
A subsequent patch will need to IPI a mask of virtual processors potentially
wider than 64 bits. A previous patch introduced per-cpu hypercall_vpmask
to allow hvcall_flush() to deal with such wide masks. This patch modifies
the implementation of hvcall_ipi() to make use of the
From: Paul Durrant
... and make use of them in hvcall_flush()/need_flush().
Subsequent patches will need to deal with virtual processor masks potentially
wider than 64 bits. Thus, to avoid using too much stack, this patch
introduces global per-cpu virtual processor masks and converts the
impleme
From: Paul Durrant
vlapic_ipi() uses a softirq batching mechanism to improve the efficiency of
sending a IPIs to large number of processors. This patch modifies send_ipi()
(the worker function called by hvcall_ipi()) to also make use of the
mechanism when there multiple bits set the hypercall_vpm
From: Paul Durrant
This patch moves the implementation of HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE/LIST
that is currently inline in viridian_hypercall() into a new hvcall_flush()
function.
The new function returns Xen erro values which are then dealt with
appropriately. A return value of -ERESTART tra
From: Paul Durrant
The Microsoft Hypervisor TLFS specifies variants of the already implemented
HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE/LIST hypercalls that take a 'Virtual
Processor Set' as an argument rather than a simple 64-bit mask.
This patch adds a new hvcall_flush_ex() function to implement the
From: Paul Durrant
Paul Durrant (12):
viridian: don't blindly write to 32-bit registers is 'mode' is invalid
viridian: move flush hypercall implementation into separate function
viridian: move IPI hypercall implementation into separate function
viridian: introduce a per-cpu hypercall_vpma
From: Paul Durrant
Co-locate it with the definition of offsetof() (since this is also in stddef.h
in the Linux kernel source). This macro will be needed in a subsequent patch.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Gral
From: Paul Durrant
A previous patch introduced variants of the flush hypercalls that take a
'Virtual Processor Set' as an argument rather than a simple 64-bit mask.
This patch introduces a similar variant of the HVCALL_SEND_IPI hypercall
(HVCALL_SEND_IPI_EX).
NOTE: As with HVCALL_FLUSH_VIRTUAL_A
On 20.11.2020 10:27, Manuel Bouyer wrote:
> On Fri, Nov 20, 2020 at 09:59:57AM +0100, Jan Beulich wrote:
>> Well, anything coming through the LAPIC needs ack-ing (except for
>> the spurious interrupt of course), or else ISR won't get updated
>> and further interrupts at this or lower priority can't
From: Paul Durrant
Adding the new value into the enumeration makes it immediately available
to xl, so this patch adjusts the xl.cfg(5) documentation accordingly.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Anthony PERARD
---
docs/man/xl.cfg.5.pod.in | 8
From: Paul Durrant
To make is simpler to observe which viridian hypercalls are issued by a
particular Windows guest, this patch adds a per-domain mask to track them.
Each type of hypercall causes a different bit to be set in the mask and
when the bit transitions from clear to set, a log line is e
From: Paul Durrant
... and advertise ExProcessorMasks support if it is set.
Support is advertised by setting bit 11 in CPUID:4004:EAX.
Signed-off-by: Paul Durrant
---
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Gral
On 19.11.2020 22:40, Stefano Stabellini wrote:
> On Thu, 19 Nov 2020, Jan Beulich wrote:
>> On 18.11.2020 22:00, Stefano Stabellini wrote:
>>> On Wed, 18 Nov 2020, Jan Beulich wrote:
On 18.11.2020 01:50, Stefano Stabellini wrote:
> 1) It is not obvious that "Configure standard Xen features
On Fri, Nov 20, 2020 at 11:00:05AM +0100, Jan Beulich wrote:
> On 20.11.2020 10:27, Manuel Bouyer wrote:
> > On Fri, Nov 20, 2020 at 09:59:57AM +0100, Jan Beulich wrote:
> >> Well, anything coming through the LAPIC needs ack-ing (except for
> >> the spurious interrupt of course), or else ISR won't
On Fri 20-11-20 10:15:46, Christoph Hellwig wrote:
> On Thu, Nov 19, 2020 at 03:39:21PM +0100, Jan Kara wrote:
> > This patch is kind of difficult to review due to the size of mostly
> > mechanical changes mixed with not completely mechanical changes. Can we
> > perhaps split out the mechanical bit
flight 156895 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156895/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 156886 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156886/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR.
vs. 152332
test-amd
On Fri 20-11-20 10:08:20, Christoph Hellwig wrote:
> On Thu, Nov 19, 2020 at 01:05:25PM +0100, Jan Kara wrote:
> > > @@ -613,7 +613,7 @@ void guard_bio_eod(struct bio *bio)
> > > rcu_read_lock();
> > > part = __disk_get_part(bio->bi_disk, bio->bi_partno);
> > > if (part)
> > > - maxse
flight 156892 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156892/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Xen PV guests don't use IST. For machine check interrupts switch to
the same model as debug interrupts.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/idtentry.h | 3 +++
arch/x86/xen/enlighten_pv.c | 16 +++-
arch/x86/xen/xen-asm.S
SWAPGS is used only for interrupts coming from user mode or for
returning to user mode. So there is no reason to use the PARAVIRT
framework, as it can easily be replaced by an ALTERNATIVE depending
on X86_FEATURE_XENPV.
There are several instances using the PV-aware SWAPGS macro in paths
which are
Xen PV guests don't use IST. For double fault interrupts switch to
the same model as NMI.
Correct a typo in a comment while copying it.
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
---
V2:
- fix typo (Andy Lutomirski)
---
arch/x86/include/asm/idtentry.h | 3 +++
arch/x86/xen/
USERGS_SYSRET64 is used to return from a syscall via sysret, but
a Xen PV guest will nevertheless use the iret hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the prerequisites for doing a sysret and
then mangling the stack for Xen PV again for doing an iret just u
This is a major cleanup of the paravirt infrastructure aiming at
eliminating all custom code patching via paravirt patching.
This is achieved by using ALTERNATIVE instead, leading to the ability
to give objtool access to the patched in instructions.
In order to remove most of the 32-bit special h
For being able to switch paravirt patching from special cased custom
code sequences to ALTERNATIVE handling some X86_FEATURE_* are needed
as new features. This enables to have the standard indirect pv call
as the default code and to patch that with the non-Xen custom code
sequence via ALTERNATIVE p
"popf" is a rather expensive operation, so don't use it for restoring
irq flags. Instead test whether interrupts are enabled in the flags
parameter and enable interrupts via "sti" in that case.
This results in the restore_fl paravirt op to be no longer needed.
Suggested-by: Andy Lutomirski
Signe
PVOP_VCALL4() is only used for Xen PV, while PVOP_CALL4() isn't used
at all. Keep PVOP_CALL4() for 64 bits due to symmetry reasons.
This allows to remove the 32-bit definitions of those macros leading
to a substantial simplification of the paravirt macros, as those were
the only ones needing non-e
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.
Switch them to use the static_call() mechanism instead of pvops, as
this allows quite some simplification of the pvops implementation.
Due to include hell this requires to split out
Instead of using paravirt patching for custom code sequences add
support for using ALTERNATIVE handling combined with paravirt call
patching.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 62 +++
1 file changed, 62 insertions(+)
diff --git a/ar
The iret paravirt op is rather special as it is using a jmp instead
of a call instruction. Switch it to ALTERNATIVE.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 7 ---
arch/x86/include/asm/paravirt_types.h | 5 +
arch/x86/kernel/asm-offsets.c | 5 -
Instead of using paravirt patching for custom code sequences use
ALTERNATIVE for the functions with custom code replacements.
Instead of patching an ud2 instruction for unpopulated vector entries
into the caller site, use a simple function just calling BUG() as a
replacement.
Signed-off-by: Juerg
There is no need any longer to have different paravirt patch functions
for native and Xen. Eliminate native_patch() and rename
paravirt_patch_default() to paravirt_patch().
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt_types.h | 19 +--
arch/x86/kernel/Makefile
On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
> +static __always_inline void arch_local_irq_restore(unsigned long flags)
> +{
> + if (!arch_irqs_disabled_flags(flags))
> + arch_local_irq_enable();
> +}
If someone were to write horrible code like:
local_irq
On Fri, Nov 20, 2020 at 12:46:24PM +0100, Juergen Gross wrote:
> The time pvops functions are the only ones left which might be
> used in 32-bit mode and which return a 64-bit value.
>
> Switch them to use the static_call() mechanism instead of pvops, as
> this allows quite some simplification of
On 20.11.20 12:59, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
+static __always_inline void arch_local_irq_restore(unsigned long flags)
+{
+ if (!arch_irqs_disabled_flags(flags))
+ arch_local_irq_enable();
+}
If someone were to write
On 20.11.20 13:01, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:24PM +0100, Juergen Gross wrote:
The time pvops functions are the only ones left which might be
used in 32-bit mode and which return a 64-bit value.
Switch them to use the static_call() mechanism instead of pvops, as
this al
On Fri, Nov 20, 2020 at 12:46:26PM +0100, Juergen Gross wrote:
> +#define PVOP_CALL(rettype, op, clbr, call_clbr, extra_clbr, ...) \
> ({ \
> PVOP_CALL_ARGS; \
>
On 20.11.20 13:08, Peter Zijlstra wrote:
On Fri, Nov 20, 2020 at 12:46:26PM +0100, Juergen Gross wrote:
+#define PVOP_CALL(rettype, op, clbr, call_clbr, extra_clbr, ...) \
({ \
PVOP_CALL_ARGS;
ACPI mandates use of E820 (or newer, e.g. EFI), and in fact firmware
has been observed to include E820_ACPI ranges in what E801 reports as
available (really "configured") memory.
Signed-off-by: Jan Beulich
---
TBD: Alternatively we could drop all use of E801 (and older), since
there shouldn'
On 04.11.2020 08:56, Jan Beulich wrote:
> When a page table page gets de-validated, its type reference count drops
> to zero (and PGT_validated gets cleared), but its type remains intact.
> XEN_DOMCTL_getpageframeinfo3, therefore, so far reported prior usage for
> such pages. An intermediate write
On 05.11.2020 16:55, Jan Beulich wrote:
> This array can be large when many grant frames are permitted; avoid
> allocating it when it's not going to be used anyway. Do so indirectly
> though, by making grant_to_status_frames() return zero in this case.
>
> Signed-off-by: Jan Beulich
Ping?
> ---
On Fri, Nov 20, 2020 at 12:46:18PM +0100, Juergen Gross wrote:
> 30 files changed, 325 insertions(+), 598 deletions(-)
Much awesome ! I'll try and get that objtool thing sorted.
Thanks everyone for participating in the meeting!
Here is a recap on topics that was discussed (some partial/draft notes
from me and Damien at Vates, sorry if some are not entirely accurate):
* Page table implementation, hardware page walking, virtual memory in Xen
* Multiple implementation, fi
When the host crashes it would sometimes be nice to have additional
debug data available which could be produced via debug keys, but
halting the server for manual intervention might be impossible due to
the need to reboot/kexec rather sooner than later.
Add support for automatic debug key actions
From: Paul Durrant
It's confusing and not consistent with the terminology introduced with 'dfn_t'.
Just call them IOMMU page tables.
Also remove a pointless check of the 'acpi_drhd_units' list in
vtd_dump_page_table_level(). If the list is empty then IOMMU mappings would
not have been enabled fo
From: Paul Durrant
This is the remainder of the cleanup series deferred until XSA-346 and
XSA-347 were publicly disclosed.
Paul Durrant (7):
remove remaining uses of iommu_legacy_map/unmap
common/grant_table: batch flush I/O TLB
iommu: remove the share_p2m operation
iommu: stop calling I
From: Paul Durrant
The 'legacy' functions do implicit flushing so amend the callers to do the
appropriate flushing.
Unfortunately, because of the structure of the P2M code, we cannot remove
the per-CPU 'iommu_dont_flush_iotlb' global and the optimization it
facilitates. Checking of this flag is
From: Paul Durrant
This patch avoids calling iommu_iotlb_flush() for each individual GNTTABOP and
instead calls iommu_iotlb_flush_all() at the end of a batch. This should mean
non-singleton map/unmap operations perform better.
NOTE: A batch is the number of operations done before a pre-emption c
From: Paul Durrant
This makes the code a little easier to read and also makes it more consistent
with iremap_entry.
Also take the opportunity to tidy up the implementation of device_in_domain().
Signed-off-by: Paul Durrant
---
Cc: Kevin Tian
v10:
- Small tweaks requested by Jan
- Remove ma
From: Paul Durrant
Sharing of HAP tables is now VT-d specific so the operation is never defined
for AMD IOMMU any more. There's also no need to pro-actively set vtd.pgd_maddr
when using shared EPT as it is straightforward to simply define a helper
function to return the appropriate value in the s
From: Paul Durrant
As with a prior patch for context_entry, this removes the need for much
shifting, masking and several magic numbers.
Signed-off-by: Paul Durrant
---
Cc: Kevin Tian
v10:
- Remove macros in favour of direct field access
- Adjust field types
- Use write_atomic() to update t
From: Paul Durrant
This removes the need for much shifting, masking and several magic numbers.
On the whole it makes the code quite a bit more readable.
Signed-off-by: Paul Durrant
---
Cc: Kevin Tian
v10:
- Remove macros in favour of direct field access
- Adjust field types
- Add missing b
Hi Juergen,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v5.10-rc4]
[also build test WARNING on next-20201120]
[cannot apply to tip/x86/core xen-tip/linux-next tip/x86/asm]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
"amd-iommu: use a bitfield for DTE" renamed iommu_dte_set_guest_cr3()'s gcr3
parameter to gcr3_mfn but ended up with an off-by-PAGE_SIZE error when
extracting bits from the address.
First of all, get_guest_cr3_from_dte() and iommu_dte_set_guest_cr3()
are (almost) getters and setters for the same f
On 20.11.2020 10:48, Paul Durrant wrote:
> From: Paul Durrant
>
> If hvm_guest_x86_mode() returns something other than 8 or 4 then
> viridian_hypercall() will return immediately but, on the way out, will write
> back status as if 'mode' was 4. This patch simply makes it leave the registers
> alon
> -Original Message-
> From: Jan Beulich
> Sent: 20 November 2020 14:20
> To: Paul Durrant
> Cc: Durrant, Paul ; Wei Liu ; Andrew
> Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] [PATCH v2 01/12] viridian: don't blindly write to
> 32-bit registe
On 20.11.2020 15:19, Andrew Cooper wrote:
> "amd-iommu: use a bitfield for DTE" renamed iommu_dte_set_guest_cr3()'s gcr3
> parameter to gcr3_mfn but ended up with an off-by-PAGE_SIZE error when
> extracting bits from the address.
>
> First of all, get_guest_cr3_from_dte() and iommu_dte_set_guest_c
On 20/11/2020 14:32, Jan Beulich wrote:
> On 20.11.2020 15:19, Andrew Cooper wrote:
>> "amd-iommu: use a bitfield for DTE" renamed iommu_dte_set_guest_cr3()'s gcr3
>> parameter to gcr3_mfn but ended up with an off-by-PAGE_SIZE error when
>> extracting bits from the address.
>>
>> First of all, get_
On 20.11.2020 15:37, Andrew Cooper wrote:
> On 20/11/2020 14:32, Jan Beulich wrote:
>> On 20.11.2020 15:19, Andrew Cooper wrote:
>>> --- a/xen/drivers/passthrough/amd/iommu_guest.c
>>> +++ b/xen/drivers/passthrough/amd/iommu_guest.c
>>> @@ -68,11 +68,39 @@ static void guest_iommu_disable(struct gue
On 20.11.2020 10:48, Paul Durrant wrote:
> --- a/xen/arch/x86/hvm/viridian/viridian.c
> +++ b/xen/arch/x86/hvm/viridian/viridian.c
> @@ -551,6 +551,25 @@ static bool vpmask_test(const struct hypercall_vpmask
> *vpmask,
> return test_bit(vp, vpmask->mask);
> }
>
> +static unsigned int vpmas
On 20.11.2020 10:48, Paul Durrant wrote:
> From: Paul Durrant
>
> vlapic_ipi() uses a softirq batching mechanism to improve the efficiency of
> sending a IPIs to large number of processors. This patch modifies send_ipi()
> (the worker function called by hvcall_ipi()) to also make use of the
> mec
> -Original Message-
> From: Jan Beulich
> Sent: 20 November 2020 15:09
> To: Paul Durrant
> Cc: Durrant, Paul ; Wei Liu ; Andrew
> Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] [PATCH v2 05/12] viridian: use hypercall_vpmask in
> hvcall_ipi()
On 20.11.2020 10:48, Paul Durrant wrote:
> From: Paul Durrant
>
> Co-locate it with the definition of offsetof() (since this is also in stddef.h
> in the Linux kernel source). This macro will be needed in a subsequent patch.
>
> Signed-off-by: Paul Durrant
Acked-by: Jan Beulich
You don't fan
> -Original Message-
> From: Jan Beulich
> Sent: 20 November 2020 15:16
> To: Paul Durrant
> Cc: Paul Durrant ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Julien Grall
> ; Stefano
> Stabellini ; Wei Liu ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v2 07/12] xen/inclu
On Fri, Nov 20, 2020 at 12:21:21PM +0100, Jan Kara wrote:
> > > AFAICT bd_size_lock is pointless after these changes so we can just remove
> > > it?
> >
> > I don't think it is, as reuqiring bd_mutex for size updates leads to
> > rather awkward lock ordering problems.
>
> OK, let me ask different
On 11.11.20 11:01, Juergen Gross wrote:
A guest with memory < maxmem often can't be dumped via xl dump-core
without an error message today:
xc: info: exceeded nr_pages (262144) losing pages
In case the last page of the guest isn't allocated the loop in
xc_domain_dumpcore_via_callback() will alw
Hi Juergen,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v5.10-rc4]
[also build test WARNING on next-20201120]
[cannot apply to tip/x86/core xen-tip/linux-next tip/x86/asm]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Fri, Nov 20, 2020 at 04:32:53PM +0100, Christoph Hellwig wrote:
> On Fri, Nov 20, 2020 at 12:21:21PM +0100, Jan Kara wrote:
> > > > AFAICT bd_size_lock is pointless after these changes so we can just
> > > > remove
> > > > it?
> > >
> > > I don't think it is, as reuqiring bd_mutex for size upd
On Fri, Nov 20, 2020 at 03:59:56PM +, Matthew Wilcox wrote:
> > Exactly. In theory we could skip it for 64-bit, but as updating the
> > size isn't a fast path, and struct block_device isn't super size critical
> > I'd rather keep the same code for 32 vs 64-bit builds.
>
> Is it better to swit
On 23.10.2020 17:41, Julien Grall wrote:
> From: Julien Grall
>
> The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
> while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
>
> Currently, the former are still containing x86 specific code.
>
> To avoid this rath
Hi Stefano,
On 20/11/2020 01:46, Stefano Stabellini wrote:
On Thu, 19 Nov 2020, Julien Grall wrote:
From: Julien Grall
At the moment, xen_pt_update_entry() only supports mapping at level 3
(i.e 4KB mapping). While this is fine for most of the runtime helper,
the boot code will require to use
flight 156890 qemu-mainline real [real]
flight 156900 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156890/
http://logs.test-lab.xenproject.org/osstest/logs/156900/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Fri, Nov 20, 2020 at 12:46:26PM +0100, Juergen Gross wrote:
> PVOP_VCALL4() is only used for Xen PV, while PVOP_CALL4() isn't used
> at all. Keep PVOP_CALL4() for 64 bits due to symmetry reasons.
>
> This allows to remove the 32-bit definitions of those macros leading
> to a substantial simplif
Hi Jan,
On 20/11/2020 16:03, Jan Beulich wrote:
On 23.10.2020 17:41, Julien Grall wrote:
From: Julien Grall
The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
Currently, the former are still containing x8
On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto
The pull request you sent on Fri, 20 Nov 2020 06:59:47 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.10b-rc5-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4ccf7a01e805f04defd423fb410f47a13af76399
Thank you!
--
Deet-doot-dot,
On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough
Hi,
On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Cla
On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallt
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva
---
drivers/xen/manage.c | 1 +
1 file chan
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva
---
drivers/block/xen-blkfront.c | 1 +
1 f
1 - 100 of 112 matches
Mail list logo
