flight 157442 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157442/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
flight 157449 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157449/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 157345
test-amd64-amd64-xl-qemuu
flight 157453 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157453/
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-i386-libvirt
flight 157438 qemu-mainline real [real]
flight 157454 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157438/
http://logs.test-lab.xenproject.org/osstest/logs/157454/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Mon, Dec 7, 2020 at 10:15 AM Philippe Mathieu-Daudé
wrote:
>
> Document what this job cover (build X86 targets with
> KVM being the single accelerator available).
>
> Reviewed-by: Thomas Huth
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> .gitlab-ci.yml | 5 +
> 1 file changed, 5 insert
Hi,
On 12/7/20 10:14 AM, Philippe Mathieu-Daudé wrote:
Document what this job cover (build X86 targets with
KVM being the single accelerator available).
Reviewed-by: Thomas Huth
Signed-off-by: Philippe Mathieu-Daudé
---
.gitlab-ci.yml | 5 +
1 file changed, 5 insertions(+)
Reviewed-b
flight 157433 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157433/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 157365
test-amd64-amd64-xl-qemuu-win7-amd64
On Thu, Dec 10, 2020 at 8:42 PM Thomas Gleixner wrote:
> Let the core code do the fiddling with irq_desc.
>
> Signed-off-by: Thomas Gleixner
> Cc: Linus Walleij
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-g...@vger.kernel.org
Reviewed-by: Linus Walleij
I suppose you will funnel th
flight 157437 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 157345
test-amd64-amd64-xl-qemuu
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xen
Andrew,
On Fri, Dec 11 2020 at 22:21, Andrew Cooper wrote:
> On 11/12/2020 21:27, Thomas Gleixner wrote:
>> It's not any different from the hardware example at least not as far as
>> I understood the code.
>
> Xen's event channels do have a couple of quirks.
Why am I not surprised?
> Binding an
On 11/12/2020 21:27, Thomas Gleixner wrote:
> On Fri, Dec 11 2020 at 09:29, boris ostrovsky wrote:
>
>> 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 Gleixn
The function will be moved to common QOM code, as it is not
specific to TYPE_DEVICE anymore.
Reviewed-by: Stefan Berger
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Rename to object_field_prop_ptr() instead of object_static_prop_ptr()
---
Cc: Stefan Berger
Cc: Stefano Stabellini
Cc:
On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote:
> On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote:
>
>> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote:
>>>
>>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
>>> be exported. Move it into the core code w
Every single qdev property setter function manually checks
dev->realized. We can just check dev->realized inside
qdev_property_set() instead.
The check is being added as a separate function
(qdev_prop_allow_set()) because it will become a callback later.
Reviewed-by: Stefan Berger
Signed-off-by
From: Thomas Gleixner
> Sent: 11 December 2020 21:11
>
> On Fri, Dec 11 2020 at 14:19, David Laight wrote:
> > From: Thomas Gleixner
> >> You can't catch that. If this really becomes an issue you need a
> >> sequence counter around it.
> >
> > Or just two copies of the high word.
> > Provided the
Make the code more generic and not specific to TYPE_DEVICE.
Reviewed-by: Marc-André Lureau
Reviewed-by: Cornelia Huck #s390 parts
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
- Fix build error with CONFIG_XEN
I took the liberty of keeping the Reviewed-by line from
Marc-André as the
On Fri, Dec 11 2020 at 09:29, boris ostrovsky wrote:
> 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:
> Change the implementation so that t
On Fri, Dec 11 2020 at 14:19, David Laight wrote:
> From: Thomas Gleixner
>> You can't catch that. If this really becomes an issue you need a
>> sequence counter around it.
>
> Or just two copies of the high word.
> Provided the accesses are sequenced:
> writer:
> load high:low
> add sm
On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote:
> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote:
>>
>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
>> be exported. Move it into the core code which lifts another requirement for
>> the export.
>
> ...
>
>
* marcandre.lur...@redhat.com (marcandre.lur...@redhat.com) wrote:
> From: Marc-André Lureau
>
> This allows to get rid of a check for older GCC version (which was a bit
> bogus too since it was falling back on c++ version..)
>
> Signed-off-by: Marc-André Lureau
Yes I think that's OK; this i
Hello Stefano,
Thanks for reviewing the code.
> On 11 Dec 2020, at 1:28 am, Stefano Stabellini wrote:
>
> On Thu, 10 Dec 2020, Rahul Singh wrote:
>> Add support for ARM architected SMMUv3 implementation. It is based on
>> the Linux SMMUv3 driver.
>>
>> Driver is currently supported as Tech Pre
On 11/12/2020 19:07, Stefano Stabellini wrote:
On Fri, 11 Dec 2020, Oleksandr wrote:
On 11.12.20 03:28, Stefano Stabellini wrote:
On Thu, 10 Dec 2020, Julien Grall wrote:
On 10/12/2020 02:30, Stefano Stabellini wrote:
On Mon, 30 Nov 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshch
Hi Stefano,
On 11/12/2020 01:28, Stefano Stabellini wrote:
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Please note, this is a split/cleanup/hardening of Julien's PoC:
"Add support for Guest IO forwarding to a device emulator"
Changes V1 -> V2:
- new patch, some changes were
On Fri, 11 Dec 2020, Oleksandr wrote:
> On 11.12.20 03:28, Stefano Stabellini wrote:
> > On Thu, 10 Dec 2020, Julien Grall wrote:
> > > On 10/12/2020 02:30, Stefano Stabellini wrote:
> > > > On Mon, 30 Nov 2020, Oleksandr Tyshchenko wrote:
> > > > > From: Oleksandr Tyshchenko
> > > > >
> > > > >
flight 157431 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157431/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 157303
test-amd64-i386-xl-qemut-win7-amd64 19
On Fri, 11 Dec 2020, Bertrand Marquis wrote:
> Hi Stefano,
>
> > On 10 Dec 2020, at 22:29, Stefano Stabellini wrote:
> >
> > On Thu, 10 Dec 2020, Bertrand Marquis wrote:
> >> Hi Stefano,
> >>
> >>> On 9 Dec 2020, at 19:38, Stefano Stabellini
> >>> wrote:
> >>>
> >>> On Wed, 9 Dec 2020, Bertr
On Thu, Dec 10, 2020 at 9:57 PM Thomas Gleixner wrote:
>
> First of all drivers have absolutely no business to dig into the internals
> of an irq descriptor. That's core code and subject to change. All of this
> information is readily available to /proc/interrupts in a safe and race
> free way.
>
On Thu, 10 Dec 2020 19:25:45 +,
Thomas Gleixner wrote:
>
> The irq descriptor is already there, no need to look it up again.
>
> Signed-off-by: Thomas Gleixner
> Cc: Marc Zyngier
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> arch/arm/kernel/smp.c |2 +-
> 1 fi
On Thu, 10 Dec 2020 19:25:46 +,
Thomas Gleixner wrote:
>
> The irq descriptor is already there, no need to look it up again.
>
> Signed-off-by: Thomas Gleixner
> Cc: Mark Rutland
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Marc Zyngier
> Cc: linux-arm-ker...@lists.infradead.org
> ---
On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote:
>
> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
> be exported. Move it into the core code which lifts another requirement for
> the export.
...
> + if (IS_ENABLED(CONFIG_LOCKDEP))
> + __irq
flight 157414 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157414/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
Hi Stefano,
> On 10 Dec 2020, at 22:29, Stefano Stabellini wrote:
>
> On Thu, 10 Dec 2020, Bertrand Marquis wrote:
>> Hi Stefano,
>>
>>> On 9 Dec 2020, at 19:38, Stefano Stabellini wrote:
>>>
>>> On Wed, 9 Dec 2020, Bertrand Marquis wrote:
Add vsysreg emulation for registers trapped when
On Fri, Dec 11, 2020 at 11:00:19AM +0100, Jan Beulich wrote:
> On 10.12.2020 15:47, Anthony PERARD wrote:
> > On Mon, Nov 23, 2020 at 04:21:19PM +0100, Jan Beulich wrote:
> >> --- a/xen/Rules.mk
> >> +++ b/xen/Rules.mk
> >> @@ -60,7 +64,14 @@ include Makefile
> >> #
> >> -
flight 157411 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157411/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 152631
build-amd64-xsm
flight 157416 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 157345
test-amd64-amd64-xl-qemuu
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 interru
Hi Rahul,
On 10/12/2020 16:56, Rahul Singh wrote:
This patch series is v3 of the work to add support for the SMMUv3 driver.
Approach taken is to first merge the Linux copy of the SMMUv3 driver
(tag v5.8.18) and then modify the driver to build on XEN.
MSI and PCI ATS functionality are not suppo
Hi Rahul,
On 10/12/2020 16:57, Rahul Singh wrote:
struct arm_smmu_strtab_cfg {
@@ -613,8 +847,13 @@ struct arm_smmu_device {
u64 padding;
};
- /* IOMMU core code handle */
- struct iommu_device iommu;
+ /* Need to keep a l
From: Thomas Gleixner
> Sent: 11 December 2020 12:58
..
> > After my failed hasty sketch from last night I had a different one which
> > was kind of heuristics based (re-reading the upper dword and retrying if
> > it changed on 32-bit).
>
> The problem is that there will be two seperate modificati
This reverts commit 9ff9705647646aa937b5f5c1426a64c69a62b3bd.
The change is only correct in the original context of XSA-286, where Xen's use
of the linear pagetables were dropped. However, performance problems
interfered with that plan, and XSA-286 was fixed differently.
This broke Xen's lazy fa
Hi Rahul,
On 10/12/2020 16:57, Rahul Singh wrote:
Replace all Linux compatible device tree handling function with the XEN
functions.
Right, but they were introduced in the previous patch. I dislike the
idea to add code for removing afterwards (in some cases you actually do
the renaming direc
On 11/12/2020 11:15, Manuel Bouyer wrote:
> On Fri, Dec 11, 2020 at 09:58:54AM +0100, Jan Beulich wrote:
>> Could you please revert 9ff970564764 ("x86/mm: drop guest_get_eff_l1e()")?
>> I think there was a thinko there in that the change can't be split from
>> the bigger one which was part of the o
Hi,
> On 10 Dec 2020, at 16:57, Rahul Singh wrote:
>
> Remove code that is related to below functionality :
> 1. struct io_pgtable_ops
> 2. struct io_pgtable_cfg
> 3. struct iommu_flush_ops,
> 4. struct iommu_ops
> 5. module_param_named, MODULE_PARM_DESC, module_platform_driver,
>MODULE_*
>
Hi Rahul,
> On 10 Dec 2020, at 16:57, Rahul Singh wrote:
>
> Replace all Linux compatible device tree handling function with the XEN
> functions.
>
> Replace all Linux ktime function with the XEN time functions.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
>
Hi,
> On 10 Dec 2020, at 16:57, Rahul Singh wrote:
>
> Import the Linux helper of_property_match_string. This function searches
> a string list property and returns the index of a specific string value.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Bertrand Marquis
Thanks
Bertrand
> ---
> Cha
flight 157421 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157421/
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 Fri, Dec 11 2020 at 10:13, Tvrtko Ursulin wrote:
> On 10/12/2020 19:25, Thomas Gleixner wrote:
>>
>> Aside of that the count is per interrupt line and therefore takes
>> interrupts from other devices into account which share the interrupt line
>> and are not handled by the graphics driver.
>>
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 interrupts and overwrite the affinity mask with the cor
On 12/11/20 10:35 AM, Bin Meng wrote:
> From: Bin Meng
>
> At present net_checksum_calculate() blindly calculates all types of
> checksums (IP, TCP, UDP). Some NICs may have a per type setting in
> their BDs to control what checksum should be offloaded. To support
> such hardware behavior, introd
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 interrupts and overwrite the affinity mask with the corresponding
cpumask. That does not make sense.
The XEN impleme
A HVM domain flushes cache on all the cpus using
`flush_all` macro which uses cpu_online_map, during
i) creation of a new domain
ii) when device-model op is performed
iii) when domain is destructed.
This triggers IPI on all the cpus, thus affecting other
domains that are pinned to different pcpus.
On 11.12.20 03:28, Stefano Stabellini wrote:
Hi Julien, Stefano
On Thu, 10 Dec 2020, Julien Grall wrote:
On 10/12/2020 02:30, Stefano Stabellini wrote:
On Mon, 30 Nov 2020, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to send mapcache invalidation request to qemu/demu e
flight 157404 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157404/
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-xsm
On Fri, Dec 11, 2020 at 09:58:54AM +0100, Jan Beulich wrote:
> Could you please revert 9ff970564764 ("x86/mm: drop guest_get_eff_l1e()")?
> I think there was a thinko there in that the change can't be split from
> the bigger one which was part of the originally planned set for XSA-286.
> We mustn't
Hi Jan,
On 11/12/2020 10:32, Jan Beulich wrote:
On 09.12.2020 12:54, Julien Grall wrote:
On 23/11/2020 13:29, Jan Beulich wrote:
@@ -620,7 +620,7 @@ int evtchn_close(struct domain *d1, int
long rc = 0;
again:
-spin_lock(&d1->event_lock);
+write_lock(&d1->event
On 11.12.20 11:49, Julien Grall wrote:
On 11/12/2020 10:38, Jürgen Groß wrote:
On 11.12.20 11:22, Julien Grall wrote:
Hi,
On 11/12/2020 07:24, Jan Beulich wrote:
On 11.12.2020 08:02, Jürgen Groß wrote:
On 10.12.20 21:51, Julien Grall wrote:
Hi Jan,
On 09/12/2020 14:29, Jan Beulich wrote:
On 11/12/2020 10:38, Jürgen Groß wrote:
On 11.12.20 11:22, Julien Grall wrote:
Hi,
On 11/12/2020 07:24, Jan Beulich wrote:
On 11.12.2020 08:02, Jürgen Groß wrote:
On 10.12.20 21:51, Julien Grall wrote:
Hi Jan,
On 09/12/2020 14:29, Jan Beulich wrote:
On 09.12.2020 13:11, Julien Grall wro
Hello Stefano,
> On 11 Dec 2020, at 1:28 am, Stefano Stabellini wrote:
>
> On Thu, 10 Dec 2020, Rahul Singh wrote:
>> @@ -2087,29 +1693,8 @@ static int arm_smmu_domain_finalise(struct
>> iommu_domain *domain,
>> }
>>
>> /* Restrict the stage to what we can actually support */
>> -
On Thu, Dec 10, 2020 at 09:01:12PM +, Andrew Cooper wrote:
> I've repro'd the problem.
>
> When I modify Xen to explicitly demand-map the LDT in the MMUEXT_SET_LDT
> hypercall, everything works fine.
>
> Specifically, this delta:
>
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index
On 11.12.2020 11:22, Julien Grall wrote:
> Hi,
>
> On 11/12/2020 07:24, Jan Beulich wrote:
>> On 11.12.2020 08:02, Jürgen Groß wrote:
>>> On 10.12.20 21:51, Julien Grall wrote:
Hi Jan,
On 09/12/2020 14:29, Jan Beulich wrote:
> On 09.12.2020 13:11, Julien Grall wrote:
>> On 2
On 11.12.20 11:22, Julien Grall wrote:
Hi,
On 11/12/2020 07:24, Jan Beulich wrote:
On 11.12.2020 08:02, Jürgen Groß wrote:
On 10.12.20 21:51, Julien Grall wrote:
Hi Jan,
On 09/12/2020 14:29, Jan Beulich wrote:
On 09.12.2020 13:11, Julien Grall wrote:
On 26/11/2020 11:20, Jan Beulich wrote:
On 09.12.2020 12:54, Julien Grall wrote:
> On 23/11/2020 13:29, Jan Beulich wrote:
>> @@ -620,7 +620,7 @@ int evtchn_close(struct domain *d1, int
>> long rc = 0;
>>
>>again:
>> -spin_lock(&d1->event_lock);
>> +write_lock(&d1->event_lock);
>>
>> if ( !port_is_
On 11.12.20 11:13, Thomas Gleixner wrote:
On Fri, Dec 11 2020 at 07:17, 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 interrupts and overwrite
Hi,
On 11/12/2020 07:24, Jan Beulich wrote:
On 11.12.2020 08:02, Jürgen Groß wrote:
On 10.12.20 21:51, Julien Grall wrote:
Hi Jan,
On 09/12/2020 14:29, Jan Beulich wrote:
On 09.12.2020 13:11, Julien Grall wrote:
On 26/11/2020 11:20, Jan Beulich wrote:
On 26.11.2020 09:03, Juergen Gross wro
On 10/12/2020 19:25, Thomas Gleixner wrote:
Driver code has no business with the internals of the irq descriptor.
Aside of that the count is per interrupt line and therefore takes
interrupts from other devices into account which share the interrupt line
and are not handled by the graphics driv
On Fri, Dec 11 2020 at 07:17, 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 interrupts and overwrite the affinity mask with the cor
On Thu, 10 Dec 2020, Thomas Gleixner wrote:
> First of all drivers have absolutely no business to dig into the internals
> of an irq descriptor. That's core code and subject to change. All of this
> information is readily available to /proc/interrupts in a safe and race
> free way.
>
> Remove the
On 10.12.2020 15:47, Anthony PERARD wrote:
> On Mon, Nov 23, 2020 at 04:21:19PM +0100, Jan Beulich wrote:
>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -60,7 +64,14 @@ include Makefile
>> #
>> ---
>>
>> quiet_cmd_ld =
flight 157398 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157398/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 157365
build-i386
On Thu, 10 Dec 2020, Thomas Gleixner wrote:
> Driver code has no business with the internals of the irq descriptor.
>
> Aside of that the count is per interrupt line and therefore takes
> interrupts from other devices into account which share the interrupt line
> and are not handled by the graphic
On Thu, 10 Dec 2020, Ville Syrjälä wrote:
> On Thu, Dec 10, 2020 at 08:25:49PM +0100, Thomas Gleixner wrote:
>> Nothing uses the result and nothing should ever use it in driver code.
>>
>> Signed-off-by: Thomas Gleixner
>> Cc: Jani Nikula
>> Cc: Joonas Lahtinen
>> Cc: Rodrigo Vivi
>> Cc: Davi
On 10.12.2020 16:55, Hongyan Xia wrote:
> On Thu, 2020-12-10 at 14:37 +0100, Jan Beulich wrote:
>> On 10.12.2020 14:09, Hongyan Xia wrote:
>>> On Mon, 2020-09-28 at 12:44 +0200, Jan Beulich wrote:
Plus finally there's no point sending the request for the local
domain
when the domain
From: Bin Meng
At present net_checksum_calculate() blindly calculates all types of
checksums (IP, TCP, UDP). Some NICs may have a per type setting in
their BDs to control what checksum should be offloaded. To support
such hardware behavior, introduce a 'csum_flag' parameter to the
net_checksum_ca
On 10.12.2020 10:51, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 07:08:41PM +, Andrew Cooper wrote:
>> Oh of course - we don't follow the exit-to-guest path on the way out here.
>>
>> As a gross hack to check that we've at least diagnosed the issue
>> appropriately, could you modify NetBSD t
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.10c-rc8-tag
xen: branch for v5.10-rc8
It contains a short series fixing a regression introduced in 5.9 for
running as Xen dom0 on a system with NVMe backed storage.
Thanks.
Juerge
flight 157412 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 157345
test-amd64-amd64-xl-qemuu
On Thu, Dec 10, 2020 at 8:42 PM Thomas Gleixner wrote:
> First of all drivers have absolutely no business to dig into the internals
> of an irq descriptor. That's core code and subject to change. All of this
> information is readily available to /proc/interrupts in a safe and race
> free way.
>
>
flight 157395 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157395/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
79 matches
Mail list logo
