On 11/16/20 3:58 PM, Christoph Hellwig wrote:
Call disk_part_iter_exit in disk_part_iter_next instead of duplicating
the functionality.
Signed-off-by: Christoph Hellwig
---
block/genhd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index
On 11/16/20 3:58 PM, Christoph Hellwig wrote:
Add a little helper to find the kobject for a struct block_device.
Signed-off-by: Christoph Hellwig
---
drivers/md/bcache/super.c | 7 ++-
drivers/md/md.c | 4 +---
fs/btrfs/sysfs.c | 15 +++
include/linux/b
On 11/16/20 3:58 PM, Christoph Hellwig wrote:
bd_mutex is primarily used for synchronizing the block device open and
release path, which recurses from partitions to the whole disk device.
The fact that we have two locks makes life unnecessarily complex due
to lock order constrains. Replace the t
On 11/16/20 3:58 PM, Christoph Hellwig wrote:
Now that the hd_struct always has a block device attached to it, there is
no need for having two size field that just get out of sync.
Additional the field in hd_struct did not use proper serializiation,
possibly allowing for torn writes. By only us
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Now that each gendisk has a reference to the block_device referencing
it, we can just use that everywhere and get rid of ->bd_contain.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsicam.c| 2 +-
fs/block_dev.c| 50
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Stop passing the whole device as a separate argument given that it
can be trivially deducted.
Signed-off-by: Christoph Hellwig
---
drivers/block/loop.c | 12 +++-
fs/block_dev.c | 69 +++---
incl
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
To simplify block device lookup and a few other upcomdin areas, make sure
that we always have a struct block_device available for each disk and
each partition. The only downside of this is that each device and
partition uses a little more memories.
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Get rid of the long-lasting struct block_device reference in
struct mapped_device. The only remaining user is the freeze code,
where we can trivially look up the block device at freeze time
and release the reference at thaw time.
Signed-off-by: Chri
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
We don't really need the struct block_device to initialize a bio. So
switch from using bio_set_dev to manually setting up bi_disk (bi_partno
will always be zero and has been cleared by bio_init already).
Signed-off-by: Christoph Hellwig
---
drive
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
set_blocksize is used by file systems to use their preferred buffer cache
block size. Block drivers should not set it.
Signed-off-by: Christoph Hellwig
---
drivers/block/loop.c | 3 ---
1 file changed, 3 deletions(-)
Reviewed-by: Hannes Reinec
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
set_blocksize is used by file systems to use their preferred buffer cache
block size. Block drivers should not set it.
Signed-off-by: Christoph Hellwig
---
drivers/block/zram/zram_drv.c | 11 +--
drivers/block/zram/zram_drv.h | 1 -
2
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
The zram claim mechanism was added to ensure no new opens come in
during teardown. But the proper way to archive that is to call
del_gendisk first, which takes care of all that. Once del_gendisk
is called in the right place, the reset side can also
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
del_gendisk already calls fsync_bdev for every partition, no need
to do this twice.
Signed-off-by: Christoph Hellwig
---
drivers/block/mtip32xx/mtip32xx.c | 15 ---
drivers/block/mtip32xx/mtip32xx.h | 2 --
2 files changed, 17 delet
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Avoid a totally pointless goto label, and use the same style of
comparism for both helpers.
Signed-off-by: Christoph Hellwig
---
init/do_mounts.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
Reviewed-by: Hannes Rein
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
The code in devt_from_partuuid is very convoluted. Refactor a bit by
sanitizing the goto and variable name usage.
Signed-off-by: Christoph Hellwig
---
init/do_mounts.c | 68 ++--
1 file changed, 31 ins
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Split each case into a self-contained helper.
Signed-off-by: Christoph Hellwig
---
include/linux/genhd.h | 7 +-
init/do_mounts.c | 183 +-
2 files changed, 91 insertions(+), 99 deletions(-)
Revie
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Adding the minor to the major creates tons of pointless conflicts. Just
use the dev_t itself, which is 32-bits and thus is guaranteed to fit
into ino_t.
Signed-off-by: Christoph Hellwig
---
fs/block_dev.c | 26 ++
1 file c
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
---
include/linux/genhd.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 46553d6d602563..22f5b9fd96f8bf 100644
--- a/include/linux/genhd.h
+++ b/include/linux
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
disk_get_part needs to be paired with a disk_put_part.
Fixes: ef45fe470e1 ("blk-cgroup: show global disk stats in root cgroup io.stat")
Signed-off-by: Christoph Hellwig
---
block/blk-cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/bl
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
When setting the whole device read-only (or clearing the read-only
state), also update the policy for all partitions. The s390 dasd
driver has awlways been doing this and it makes a lot of sense.
Signed-off-by: Christoph Hellwig
---
block/ioctl.c
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Just open code it in the few callers.
Signed-off-by: Christoph Hellwig
---
block/ioctl.c | 25 +
drivers/block/pktcdvd.c | 6 --
drivers/md/bcache/request.c | 5 +++--
drivers/md/dm.c
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Fold set_device_ro into its only remaining caller.
Signed-off-by: Christoph Hellwig
---
block/genhd.c | 7 ---
block/ioctl.c | 2 +-
include/linux/genhd.h | 1 -
3 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Use set_disk_ro instead of set_device_ro to match all other block
drivers and to ensure all partitions mirror the read-only flag.
Signed-off-by: Christoph Hellwig
---
drivers/block/loop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
On 11/16/20 3:57 PM, Christoph Hellwig wrote:
Now that all drivers that want to hook into setting or clearing the
read-only flag use the set_read_only method, this code can be removed.
Signed-off-by: Christoph Hellwig
---
block/ioctl.c | 23 ---
1 file changed, 23 deletio
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.10b-rc5-tag
xen: branch for v5.10-rc5
It contains a single fix for avoiding WARN splats when booting a Xen
guest with nosmt.
Thanks.
Juergen
arch/x86/xen/spinlock.c | 12 +++
flight 156882 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156882/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 156867
test-amd64-amd64-xl-qemuu-win7-amd64
flight 156889 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156889/
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
On Thu, 19 Nov 2020, Julien Grall wrote:
> From: Julien Grall
>
> Now that map_pages_to_xen() has been extended to support 2MB mappings,
> we can replace the create_mappings() calls by map_pages_to_xen() calls.
>
> The mapping can also be marked read-only as Xen as no business to modify
> the ho
On Thu, 19 Nov 2020, Julien Grall wrote:
> From: Julien Grall
>
> Now that xen_pt_update_entry() is able to deal with different mapping
> size, we can replace the open-coding of the page-tables update by a call
> to modify_xen_mappings().
>
> As the function is not meant to fail, a BUG_ON is add
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 superpage mapping.
>
> We don't want to allow superp
flight 156878 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156878/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631
test-amd64-amd64
On Thu, 19 Nov 2020, Julien Grall wrote:
> From: Julien Grall
>
> The ; at the end of mm_printk() means the following code will not build
> correctly:
>
> if ( ... )
> mm_printk(...);
> else
> ...
>
> As we treat the macro as a function, we want to remove the ; at the end
> of it.
>
>
On Thu, 19 Nov 2020, Bertrand Marquis wrote:
> Hi Julien,
>
> > On 19 Nov 2020, at 17:08, Julien Grall wrote:
> >
> > From: Julien Grall
> >
> > gic_make_hwdom_madt() and gic_get_hwdom_madt_size() are ACPI specific.
> >
> > While they build fine today, this will change in a follow-up patch.
>
On Thu, 19 Nov 2020, Julien Grall wrote:
> On Thu, 19 Nov 2020, 23:38 Stefano Stabellini, wrote:
> On Thu, 19 Nov 2020, Rahul Singh wrote:
> > > On 19/11/2020 09:53, Jan Beulich wrote:
> > >> On 19.11.2020 10:21, Julien Grall wrote:
> > >>> Hi Jan,
> > >>>
> > >
On Thu, 19 Nov 2020, 23:38 Stefano Stabellini,
wrote:
> On Thu, 19 Nov 2020, Rahul Singh wrote:
> > > On 19/11/2020 09:53, Jan Beulich wrote:
> > >> On 19.11.2020 10:21, Julien Grall wrote:
> > >>> Hi Jan,
> > >>>
> > >>> On 19/11/2020 09:05, Jan Beulich wrote:
> > On 18.11.2020 16:50, Julie
On Thu, 19 Nov 2020, Julien Grall wrote:
> On 19/11/2020 15:22, Bertrand Marquis wrote:
> > Hi Julien,
>
> Hi Bertrand,
>
> >
> > > On 19 Nov 2020, at 12:13, Julien Grall wrote:
> > >
> > > From: Julien Grall
> > >
> > > The length of the GICC structure in the MADT ACPI table differs between
On Thu, 19 Nov 2020, Julien Grall wrote:
> From: Julien Grall
>
> init_one_desc_irq() can return an error if it is unable to allocate
> memory. While this is unlikely to happen during boot (called from
> init_irq_data()), it is better to harden the code by propagting the
> return value.
>
> Spot
On Thu, 19 Nov 2020, Rahul Singh wrote:
> > On 19/11/2020 09:53, Jan Beulich wrote:
> >> On 19.11.2020 10:21, Julien Grall wrote:
> >>> Hi Jan,
> >>>
> >>> On 19/11/2020 09:05, Jan Beulich wrote:
> On 18.11.2020 16:50, Julien Grall wrote:
> > On 16/11/2020 12:25, Rahul Singh 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 (expert
> >>> users)" is actually the famous EXPE
flight 156879 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156879/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6c8dd15c4ae42501438a525ec41299f365f223cb
baseline version:
ovmf 6c4efc050974812d6ebee
flight 156874 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156874/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 156722
Tests which did not succeed, b
From: Julien Grall
discard_init_modules() is an init function, if the path contains a
BUG() or WARN() we still want to get the full stack trace.
The init virtual region is now kept after the last init function has
been called.
Signed-off-by: Julien Grall
---
xen/arch/arm/setup.c | 3 ++-
1 fi
From: Julien Grall
Now that xen_pt_update_entry() is able to deal with different mapping
size, we can replace the open-coding of the page-tables update by a call
to modify_xen_mappings().
As the function is not meant to fail, a BUG_ON is added to check the
return.
Signed-off-by: Julien Grall
S
From: Stefano Stabellini
There is no need to have a special case for CPU0 when converting the
page-table virtual address into a physical address. The helper
virt_to_maddr() is able to translate any address as long as the root
page-tables is mapped in the virtual address. This is the case for all
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() calls by map_pages_to_xen() calls.
The mapping can also be marked read-only as Xen as no business to modify
the host Device Tree.
Signed-off-by: Julien Grall
---
xen/
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 superpage mapping.
We don't want to allow superpage mapping by default as some of the
callers may expec
From: Julien Grall
The ; at the end of mm_printk() means the following code will not build
correctly:
if ( ... )
mm_printk(...);
else
...
As we treat the macro as a function, we want to remove the ; at the end
of it.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 2 +-
1 file ch
From: Julien Grall
Hi all,
This is a first attempt to add superpage mapping in
xen_pt_update_entry(). The end goal if to remove open-coding mappings
which will help to:
1) get better compliance with the Arm memory model
2) pave the way for other page size (64KB, 16KB).
For now, only the ope
flight 156871 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156871/
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
Hi,
> On 19 Nov 2020, at 17:08, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment Xen requires the FADT ACPI table to be at least version
> 6.0, apparently because of some reliance on other ACPI v6.0 features.
>
> But actually this is overzealous, and Xen works now fine with ACPI v
Hi,
> On 19 Nov 2020, at 17:08, Julien Grall wrote:
>
> From: Julien Grall
>
> The length of the GICC structure in the MADT ACPI table differs between
> version 5.1 and 6.0, although there are no other relevant differences.
>
> Use the BAD_MADT_GICC_ENTRY macro, which was specifically designe
Hi Julien,
> On 19 Nov 2020, at 17:08, Julien Grall wrote:
>
> From: Julien Grall
>
> gic_make_hwdom_madt() and gic_get_hwdom_madt_size() are ACPI specific.
>
> While they build fine today, this will change in a follow-up patch.
> Rather than trying to fix the build on ACPI, it is best to avo
On Thu, Nov 19, 2020 at 05:57:34PM +0100, Manuel Bouyer wrote:
> On Thu, Nov 19, 2020 at 04:57:18PM +0100, Manuel Bouyer wrote:
> > On Thu, Nov 19, 2020 at 03:19:15PM +0100, Roger Pau Monné wrote:
> > > I've got two different debug patches for you to try. I'm attaching both
> > > to this email but
To avoid going down ratholes (especially for jobs which reuse outputs
from their previous selves), the primary flight/job finder in
sg-report-flight does not recurse indefinitely through build jobs.
Instead, it restricts the build jobs investigated to those within the
same flight as the job which m
The existing approach does not find retest flights. This is because
it starts by looking for flights whose runvars say they built the
version in question, and then looks to see if they contain the
relevant job.
Retest flights don't contain build jobs; they reuse the builds from
the primary flight
No functional change. We're going to add another WITH...
Signed-off-by: Ian Jackson
---
sg-report-flight | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sg-report-flight b/sg-report-flight
index fd266586..40a3cc92 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@
On 19/11/2020 17:10, Andrew Cooper wrote:
> On 19/11/2020 16:37, Jan Beulich wrote:
>> On 19.11.2020 17:10, Andrew Cooper wrote:
>>> On 19/11/2020 15:57, Jan Beulich wrote:
Found by looking for patterns similar to the one Julien did spot in
pci_vtd_quirks().
Signed-off-by: Jan B
On 19/11/2020 16:37, Jan Beulich wrote:
> On 19.11.2020 17:10, Andrew Cooper wrote:
>> On 19/11/2020 15:57, Jan Beulich wrote:
>>> Found by looking for patterns similar to the one Julien did spot in
>>> pci_vtd_quirks().
>>>
>>> Signed-off-by: Jan Beulich
>> Subject is wonky. Is it P4 (Intel), or
From: Julien Grall
At the moment Xen requires the FADT ACPI table to be at least version
6.0, apparently because of some reliance on other ACPI v6.0 features.
But actually this is overzealous, and Xen works now fine with ACPI v5.1.
Let's relax the version check for the FADT table to allow QEMU
From: Julien Grall
The length of the GICC structure in the MADT ACPI table differs between
version 5.1 and 6.0, although there are no other relevant differences.
Use the BAD_MADT_GICC_ENTRY macro, which was specifically designed to
overcome this issue.
Signed-off-by: Julien Grall
Signed-off-by
From: Julien Grall
gic_make_hwdom_madt() and gic_get_hwdom_madt_size() are ACPI specific.
While they build fine today, this will change in a follow-up patch.
Rather than trying to fix the build on ACPI, it is best to avoid
compiling the helpers and the associated callbacks when CONFIG_ACPI=n.
S
From: Julien Grall
Hi all,
This series was originally called "xen/arm: Unbreak ACPI". It was
renamed because only the part to allow boot with ACPI 5.1 is not
merged.
After this series, it is possible to boot Xen on QEMU with ACPI 5.1.
Cheers,
Julien Grall (3):
xen/arm: gic: acpi: Guard help
On Thu, Nov 19, 2020 at 04:57:18PM +0100, Manuel Bouyer wrote:
> On Thu, Nov 19, 2020 at 03:19:15PM +0100, Roger Pau Monné wrote:
> > I've got two different debug patches for you to try. I'm attaching both
> > to this email but I think we should start with Jan's suggestion
> > (conditional_print.pa
> -Original Message-
> From: Jan Beulich
> Sent: 19 November 2020 16:45
> To: p...@xen.org
> Cc: 'Paul Durrant' ; 'Wei Liu' ; 'Andrew
> Cooper'
> ; 'Roger Pau Monné' ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 06/10] viridian: add ExProcessorMasks variants of the
> flush hy
On 19.11.2020 17:44, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 19 November 2020 16:41
>> To: p...@xen.org
>> Cc: Durrant, Paul ; 'Wei Liu' ; 'Andrew
>> Cooper'
>> ; 'Roger Pau Monné' ;
>> xen-devel@lists.xenproject.org
>> Subject: RE: [EXTERNAL] [PATCH 03/1
On 19.11.2020 17:11, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 12 November 2020 09:19
>>
>> On 11.11.2020 21:07, Paul Durrant wrote:
>>> --- a/xen/arch/x86/hvm/viridian/viridian.c
>>> +++ b/xen/arch/x86/hvm/viridian/viridian.c
>>> @@ -553,6 +553,83 @@ static unsigned int vpmask_next(struct
> -Original Message-
> From: Jan Beulich
> Sent: 19 November 2020 16:41
> To: p...@xen.org
> Cc: Durrant, Paul ; 'Wei Liu' ; 'Andrew
> Cooper'
> ; 'Roger Pau Monné' ;
> xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] [PATCH 03/10] viridian: introduce a per-cpu
> hypercall_vpmas
On 19/11/2020 16:40, Julien Grall wrote:
>
>
> On 19/11/2020 16:38, Andrew Cooper wrote:
>> On 19/11/2020 14:52, Julien Grall wrote:
>>> Note that splat is from 4.11.4 and not staging. Although, the
>>> problem is
>>> still present.
>>>
>>> This can be solved by making the first operand unsigned in
On 19.11.2020 17:02, Paul Durrant wrote:
>> From: Jan Beulich > Sent: 12 November 2020 08:46
>>
>> On 11.11.2020 21:07, Paul Durrant wrote:
>>> --- a/xen/arch/x86/hvm/viridian/viridian.c
>>> +++ b/xen/arch/x86/hvm/viridian/viridian.c
>>> @@ -507,15 +507,41 @@ void viridian_domain_deinit(struct doma
On 19/11/2020 16:38, Andrew Cooper wrote:
On 19/11/2020 14:52, Julien Grall wrote:
Note that splat is from 4.11.4 and not staging. Although, the problem is
still present.
This can be solved by making the first operand unsigned int.
Signed-off-by: Julien Grall
CR: https://code.amazon.com/r
On 19/11/2020 14:52, Julien Grall wrote:
> Note that splat is from 4.11.4 and not staging. Although, the problem is
> still present.
>
> This can be solved by making the first operand unsigned int.
>
> Signed-off-by: Julien Grall
>
> CR: https://code.amazon.com/reviews/CR-38873112
IIRC, this is a
On 19.11.2020 17:10, Andrew Cooper wrote:
> On 19/11/2020 15:57, Jan Beulich wrote:
>> Found by looking for patterns similar to the one Julien did spot in
>> pci_vtd_quirks().
>>
>> Signed-off-by: Jan Beulich
>
> Subject is wonky. Is it P4 (Intel), or Fam15 (AMD) ? I'd be tempted to
> have the
On 19.11.2020 16:54, Rahul Singh wrote:
>> On 19 Nov 2020, at 10:16 am, Julien Grall wrote:
>> On 19/11/2020 09:53, Jan Beulich wrote:
>>> Well, see my patch suppressing building of quite a part of it.
>>
>> I will let Rahul figuring out whether your patch series is sufficient to fix
>> compilati
On 19/11/2020 15:58, Jan Beulich wrote:
> Found by looking for patterns similar to the one Julien did spot in
> pci_vtd_quirks(). (Not that it matters much here, considering the code
> is dead right now.)
>
> Fixes: 3a7947b69011 ("amd-iommu: use a bitfield for DTE")
> Signed-off-by: Jan Beulich
A
On 19/11/2020 15:57, Jan Beulich wrote:
> Found by looking for patterns similar to the one Julien did spot in
> pci_vtd_quirks().
>
> Signed-off-by: Jan Beulich
Subject is wonky. Is it P4 (Intel), or Fam15 (AMD) ? I'd be tempted to
have the prefix as x86/nmi: either way.
With that suitably adj
> -Original Message-
> From: Jan Beulich
> Sent: 12 November 2020 09:23
> To: Paul Durrant
> Cc: Paul Durrant ; Wei Liu ; Andrew Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 08/10] viridian: log initial invocation of each type of
> hypercall
>
> O
> -Original Message-
> From: Jan Beulich
> Sent: 12 November 2020 09:19
> To: Paul Durrant
> Cc: Paul Durrant ; Wei Liu ; Andrew Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 06/10] viridian: add ExProcessorMasks variants of the
> flush hypercalls
>
On 19/11/2020 15:57, Jan Beulich wrote:
> Found by looking for patterns similar to the one Julien did spot in
> pci_vtd_quirks().
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
> -Original Message-
> From: Jan Beulich
> Sent: 12 November 2020 08:53
> To: Paul Durrant
> Cc: Paul Durrant ; Wei Liu ; Andrew Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 05/10] viridian: use softirq batching in hvcall_ipi()
>
> On 11.11.2020 21
> -Original Message-
> From: Jan Beulich
> Sent: 12 November 2020 08:50
> To: Paul Durrant
> Cc: Paul Durrant ; Wei Liu ; Andrew Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 04/10] viridian: use hypercall_vpmask in hvcall_ipi()
>
> On 11.11.2020 21
> -Original Message-
> From: Jan Beulich Sent: 12 November 2020 08:46
> To: Paul Durrant
> Cc: Paul Durrant ; Wei Liu ; Andrew Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PATCH 03/10] viridian: introduce a per-cpu hypercall_vpmask and
> accessor functio
Found by looking for patterns similar to the one Julien did spot in
pci_vtd_quirks(). (Not that it matters much here, considering the code
is dead right now.)
Fixes: 3a7947b69011 ("amd-iommu: use a bitfield for DTE")
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++
Found by looking for patterns similar to the one Julien did spot in
pci_vtd_quirks().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -132,7 +132,7 @@ int nmi_active;
#define P4_ESCR_EVENT_SELECT(N)((N)<<25)
#define P4_CCCR_OVF_PMI0 (1<<26)
#defin
On Thu, Nov 19, 2020 at 03:19:15PM +0100, Roger Pau Monné wrote:
> I've got two different debug patches for you to try. I'm attaching both
> to this email but I think we should start with Jan's suggestion
> (conditional_print.patch). That patch will only print extra messages
> between the ioregsel
Found by looking for patterns similar to the one Julien did spot in
pci_vtd_quirks().
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -55,7 +55,7 @@ enum GenericIntercept1bits
GENERAL1_INTERCEPT_MSR_PROT = 1 << 28,
GE
Hello,
> On 19 Nov 2020, at 10:16 am, Julien Grall wrote:
>
>
>
> On 19/11/2020 09:53, Jan Beulich wrote:
>> On 19.11.2020 10:21, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 19/11/2020 09:05, Jan Beulich wrote:
On 18.11.2020 16:50, Julien Grall wrote:
> On 16/11/2020 12:25, Rahul Sing
Hi Jorge,
> On 19 Nov 2020, at 13:16, Jorge Pereira wrote:
>
> Hi All,
>
> I’m having some smmu-related issues, I need help.
>
> So, in my use-case scenario I have two linux guests running in parallel –
> dom0 and domU-. I have to enable the smmu because I want to passthough
> devices to
On 19/11/2020 15:22, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 19 Nov 2020, at 12:13, Julien Grall wrote:
From: Julien Grall
The length of the GICC structure in the MADT ACPI table differs between
version 5.1 and 6.0, although there are no other relevant differences.
Use th
Hi Julien,
> On 19 Nov 2020, at 12:13, Julien Grall wrote:
>
> From: Julien Grall
>
> The length of the GICC structure in the MADT ACPI table differs between
> version 5.1 and 6.0, although there are no other relevant differences.
>
> Use the BAD_MADT_GICC_ENTRY macro, which was specifically
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;
> - struct inode *inode = file_inode(vmf->vma->vm_file);
> + st
On Thu, Nov 19, 2020 at 02:54:34PM +, Julien Grall wrote:
> From: Julien Grall
>
> init_one_desc_irq() can return an error if it is unable to allocate
> memory. While this is unlikely to happen during boot (called from
> init_irq_data()), it is better to harden the code by propagting the
> re
Hi,
> On 19 Nov 2020, at 14:54, Julien Grall wrote:
>
> From: Julien Grall
>
> init_one_desc_irq() can return an error if it is unable to allocate
> memory. While this is unlikely to happen during boot (called from
> init_irq_data()), it is better to harden the code by propagting the
> return
Hi Jan,
On 19/11/2020 15:02, Jan Beulich wrote:
On 19.11.2020 15:52, Julien Grall wrote:
From: Julien Grall
When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will throw
the following splat:
(XEN)
(XEN
flight 156867 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156867/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 156857
Tests which did not succeed
On 19.11.2020 15:52, Julien Grall wrote:
> From: Julien Grall
>
> When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will throw
> the following splat:
>
> (XEN)
>
> (XEN) UBSAN: Undefined behaviour in quir
On Wed 18-11-20 09:47:58, Christoph Hellwig wrote:
> Just open code the wait in the only caller of both functions.
>
> Signed-off-by: Christoph Hellwig
As far as I remember, Al (added to CC) generally objected against exporting
bits from fs/super.c (like put_super(), __get_super()) in the past.
From: Julien Grall
init_one_desc_irq() can return an error if it is unable to allocate
memory. While this is unlikely to happen during boot (called from
init_irq_data()), it is better to harden the code by propagting the
return value.
Spotted by coverity.
CID: 106529
Signed-off-by: Julien Gral
On Wed 18-11-20 09:47:57, Christoph Hellwig wrote:
> Use file->f_mapping in all remaining places that have a struct file
> available to properly handle the case where inode->i_mapping !=
> file_inode(file)->i_mapping.
>
> Signed-off-by: Christoph Hellwig
Looks good. You can add:
Reviewed-by: Ja
From: Julien Grall
When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will throw
the following splat:
(XEN)
(XEN) UBSAN: Undefined behaviour in quirks.c:449:63
(XEN) left shift of 1 by 31 places cannot be
On Wed 18-11-20 09:47:56, Christoph Hellwig wrote:
> We can just dereference the point in struct gendisk instead. Also
> remove the now unused export.
>
> Signed-off-by: Christoph Hellwig
Looks good to me. You can add:
Reviewed-by: Jan Kara
1 - 100 of 144 matches
Mail list logo
