On 13.07.2023 19:49, Oleksii wrote:
> On Thu, 2023-07-13 at 16:26 +0200, Jan Beulich wrote:
>> On 13.07.2023 15:36, Oleksii wrote:
>>> On Thu, 2023-07-13 at 15:27 +0200, Jan Beulich wrote:
I don't understand. My earlier comment was affecting all checks
of
uart->irq alike, as I'm unco
On 13.07.2023 18:47, Elliott Mitchell wrote:
> On Thu, Jul 13, 2023 at 03:12:55PM +0200, Jan Beulich wrote:
>> On 17.03.2023 20:53, Elliott Mitchell wrote:
>>> --- a/xen/arch/x86/apic.c
>>> +++ b/xen/arch/x86/apic.c
>>> @@ -1419,12 +1420,13 @@ static void cf_check error_interrupt(struct
>>> cpu_us
On Sat, Jul 8, 2023 at 11:47 AM Stefano Stabellini
wrote:
> On Sat, 1 Jul 2023, Christopher Clark wrote:
> > To convert the x86 boot logic from multiboot to boot module structures,
> > change the bootstrap map function to accept a boot module parameter.
> >
> > To allow incremental change from mu
flight 181780 xen-unstable real [real]
flight 181787 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181780/
http://logs.test-lab.xenproject.org/osstest/logs/181787/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On Fri, Jul 14, 2023 at 03:24:59AM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Jul 13, 2023 at 05:16:40PM -0700, Elliott Mitchell wrote:
> > The better to encourage moving to setting via string mode names.
>
> The numeric values needs to remain documented, otherwise interpreting
> pre-exist
On Thu, Jul 13, 2023 at 05:16:40PM -0700, Elliott Mitchell wrote:
> The better to encourage moving to setting via string mode names.
The numeric values needs to remain documented, otherwise interpreting
pre-existing configs (that may use them) will be tricky.
--
Best Regards,
Marek Marczykowski-
flight 181788 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181788/
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
The better to encourage moving to setting via string mode names.
Signed-off-by: Elliott Mitchell
---
I'm not actually sure what tsc_mode==0 does. I didn't find other
references, so I'm unsure how that should be modified.
---
docs/man/xen-tscmode.7.pod | 17 +
1 file changed, 9 i
Normal behavior is to be silent. Generating a message for the preferred
input can be mistaken for an error. As such remove this message to match
other conditions.
Signed-off-by: Elliott Mitchell
---
tools/xl/xl_parse.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/xl/xl_parse.c b/to
The pull request you sent on Thu, 13 Jul 2023 14:15:42 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.5-rc2-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/15999328946bd778b7bbf57179ee871dd5279b04
Thank you!
--
Deet-doot-dot, I
flight 181786 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181786/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ff3382a51ca726a90f49623a2b2d2e8ad8459ce2
baseline version:
ovmf 8dab4eebe435fc28cae32
On Thu, Jul 13, 2023 at 08:34:52AM -0700, Elliott Mitchell wrote:
> On Thu, Jul 13, 2023 at 10:38:37AM +0200, Jan Beulich wrote:
> > On 12.07.2023 21:59, Elliott Mitchell wrote:
> > > This series has been seen previously. The issue is pretty simple, if
> > > ACPI errors occur there is a high proba
Hi,
On 12/07/2023 20:58, Stefano Stabellini wrote:
On Wed, 12 Jul 2023, Luca Fancellu wrote:
On 12 Jul 2023, at 14:04, Michal Orzel wrote:
Hi Luca,
On 12/07/2023 14:04, Luca Fancellu wrote:
Fix the right border of the silicon-errata.txt table
Fixes: 1814a626fb58 ("xen/arm: Update silicon
On 13/07/2023 19:18, Julien Grall wrote:
On 12/07/2023 18:04, Rahul Singh wrote:
Hi Stewart,
On 12 Jul 2023, at 2:52 pm, Stewart Hildebrand
wrote:
When mapping BARs for vPCI, it's valid for a BAR mfn_t start to equal
the BAR
mfn_t end (i.e. start == end) since end is inclusive. Howeve
Hi Stewart,
On 07/07/2023 02:47, Stewart Hildebrand wrote:
From: Rahul Singh
Setting CONFIG_PCI_PASSTHROUGH=y will enable PCI passthrough on ARM, even though
the feature is not yet complete in the current upstream codebase. The purpose of
this is to make it easier to enable the necessary confi
On 12/07/2023 18:04, Rahul Singh wrote:
Hi Stewart,
On 12 Jul 2023, at 2:52 pm, Stewart Hildebrand
wrote:
When mapping BARs for vPCI, it's valid for a BAR mfn_t start to equal the BAR
mfn_t end (i.e. start == end) since end is inclusive. However, pci_check_bar()
currently returns false in
On 12/07/2023 08:01, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 11/07/2023 18:07, Julien Grall wrote:
Hi Michal,
On 11/07/2023 09:29, Michal Orzel wrote:
At the moment, we limit the allocation size when creating a domU dtb to
4KB, which is not enough when using a passthrough dtb wit
flight 181784 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181784/
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, 13 Jul 2023 17:23:14 +0200
Petr Tesarik wrote:
> From: Petr Tesarik
>
> Carve out memory pool specific fields from struct io_tlb_mem. The original
> struct now contains shared data for the whole allocator, while the new
> struct io_tlb_pool contains data that is specific to one memory p
On Thu, 2023-07-13 at 16:26 +0200, Jan Beulich wrote:
> On 13.07.2023 15:36, Oleksii wrote:
> > On Thu, 2023-07-13 at 15:27 +0200, Jan Beulich wrote:
> > > I don't understand. My earlier comment was affecting all checks
> > > of
> > > uart->irq alike, as I'm unconvinced IRQ0 may not possibly be
> >
On Thu, Jul 13, 2023 at 03:12:55PM +0200, Jan Beulich wrote:
> On 17.03.2023 20:53, Elliott Mitchell wrote:
> > --- a/xen/arch/x86/apic.c
> > +++ b/xen/arch/x86/apic.c
> > @@ -1419,12 +1420,13 @@ static void cf_check error_interrupt(struct
> > cpu_user_regs *regs)
> > v1 = apic_read(APIC_ESR)
On Thu, Jul 13, 2023 at 03:08:56PM +0200, Jan Beulich wrote:
> On 17.03.2023 20:45, Elliott Mitchell wrote:
> > Rather than adding ", " with each printf(), simply include them in the
> > string initially. This allows converting to strlcat() or other methods
> > which strictly concatenate, rather t
On Thu, Jul 13, 2023 at 9:02 AM Jan Beulich wrote:
>
> On 06.07.2023 20:54, Jason Andryuk wrote:
> > @@ -531,6 +535,103 @@ int get_hwp_para(unsigned int cpu,
> > return 0;
> > }
> >
> > +int set_hwp_para(struct cpufreq_policy *policy,
> > + struct xen_set_cppc_para *set_cppc)
On Thu, Jul 13, 2023 at 8:37 AM Jan Beulich wrote:
>
> With the adjustments (provided you agree)
> Acked-by: Jan Beulich
Yes, they all sound good. Thank you.
-Jason
On Thu, Jul 13, 2023 at 10:41:45AM -0400, Sean Paul wrote:
> On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
> > But even with the one-patch-per-rename approach I'd consider the
> > renaming a net win, because ease of understanding code has a big value.
> > It's value is not so easy measurable as
On Thu, Jul 13, 2023 at 10:38:37AM +0200, Jan Beulich wrote:
> On 12.07.2023 21:59, Elliott Mitchell wrote:
> > This series has been seen previously. The issue is pretty simple, if
> > ACPI errors occur there is a high probability they will occur on multiple
> > cores at once.
>
> Nit: Both here
On Thu, Jul 13, 2023 at 04:14:55PM +0100, Tvrtko Ursulin wrote:
>
> On 13/07/2023 16:09, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 13.07.23 um 16:41 schrieb Sean Paul:
> > > On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
> > > wrote:
> > > >
> > > > hello Sean,
> > > >
> > > > On Wed, Jul 1
From: Petr Tesarik
Skip searching the software IO TLB if a device has never used it, making
sure these devices are not affected by the introduction of multiple IO TLB
memory pools.
Additional memory barrier is required to ensure that the new value of the
flag is visible to other CPUs after mappi
From: Petr Tesarik
When swiotlb_find_slots() cannot find suitable slots, schedule the
allocation of a new memory pool. It is not possible to allocate the pool
immediately, because this code may run in interrupt context, which is not
suitable for large memory allocations. This means that the memor
From: Petr Tesarik
The value returned by default_swiotlb_limit() should be constant, because
it is used to decide whether DMA can be used. To allow allocating memory
pools on the fly, use the maximum possible physical address rather than the
highest address used by the default pool.
For swiotlb_
From: Petr Tesarik
Try to allocate a transient memory pool if no suitable slots can be found
and the respective SWIOTLB is allowed to grow. The transient pool is just
enough big for this one bounce buffer. It is inserted into a per-device
list of transient memory pools, and it is freed again when
From: Petr Tesarik
Mark the default SWIOTLB as able to grow and restricted DMA pools as
unable.
However, if the address of the default memory pool is explicitly queried,
make the default SWIOTLB also unable to grow. This is currently used to set
up PCI BAR movable regions on some Octeon MIPS boa
From: Petr Tesarik
Carve out memory pool specific fields from struct io_tlb_mem. The original
struct now contains shared data for the whole allocator, while the new
struct io_tlb_pool contains data that is specific to one memory pool of
(potentially) many.
Allocate both structures together for r
From: Petr Tesarik
Add some kernel-doc comments and move the existing documentation of struct
io_tlb_slot to its correct location. The latter was forgotten in commit
942a8186eb445 ("swiotlb: move struct io_tlb_slot to swiotlb.c").
Use the opportunity to give swiotlb_do_find_slots() a more descri
From: Petr Tesarik
SWIOTLB implementation details should not be exposed to the rest of the
kernel. This will allow to make changes to the implementation without
modifying non-swiotlb code.
To avoid breaking existing users, provide helper functions for the few
required fields.
As a bonus, using
From: Petr Tesarik
Motivation
==
The software IO TLB was designed with these assumptions:
1) It would not be used much. Small systems (little RAM) don't need it, and
big systems (lots of RAM) would have modern DMA controllers and an IOMMU
chip to handle legacy devices.
2) A small
Hi
Am 13.07.23 um 16:41 schrieb Sean Paul:
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
wrote:
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
I'd really prefer this patch (series or single) is not accepted. This
will cause problems for everyone cherry-picking pat
On 13/07/2023 16:09, Thomas Zimmermann wrote:
Hi
Am 13.07.23 um 16:41 schrieb Sean Paul:
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
wrote:
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
I'd really prefer this patch (series or single) is not accepted. This
wi
On 11/07/2023 10:22 am, Roger Pau Monne wrote:
> diff --git a/tools/libs/guest/xg_cpuid_x86.c b/tools/libs/guest/xg_cpuid_x86.c
> index 5b035223f4f5..5e5c8124dd74 100644
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -423,10 +423,169 @@ static int xc_cpuid_xend
On 07.07.2023 18:07, Alejandro Vallejo wrote:
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -31,6 +31,17 @@
> * (i.e. all devices assigned to) a guest share a single DMA address space
> * and, by default, Xen will ensure dfn == pfn.
> *
> + * pdx: Page InDeX
> + * Indic
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
wrote:
>
> hello Sean,
>
> On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
> > I'd really prefer this patch (series or single) is not accepted. This
> > will cause problems for everyone cherry-picking patches to a
> > downstream kernel (L
On 13.07.23 10:44, Juergen Gross wrote:
Hello all.
> On 12.07.23 10:48, Viresh Kumar wrote:
>> Xen provides support for injecting interrupts to the guests via the
>> HYPERVISOR_dm_op() hypercall. The same is used by the Virtio based
>> device backend implementations, in an inefficient manner c
On 13.07.2023 15:43, Federico Serafini wrote:
>
>
> On 04/07/23 16:51, Jan Beulich wrote:
>> On top of my earlier remark (when this was part of a series):
>>
>>> --- a/xen/arch/x86/cpu/mcheck/x86_mca.h
>>> +++ b/xen/arch/x86/cpu/mcheck/x86_mca.h
>>> @@ -113,7 +113,7 @@ static inline int mcabanks_
On 13.07.2023 15:36, Oleksii wrote:
> On Thu, 2023-07-13 at 15:27 +0200, Jan Beulich wrote:
>> I don't understand. My earlier comment was affecting all checks of
>> uart->irq alike, as I'm unconvinced IRQ0 may not possibly be usable
>> on some architecture / platform. IOW I don't see why the check
flight 181781 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181781/
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 181778 linux-linus real [real]
flight 181782 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181778/
http://logs.test-lab.xenproject.org/osstest/logs/181782/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On 04/07/23 16:51, Jan Beulich wrote:
On top of my earlier remark (when this was part of a series):
--- a/xen/arch/x86/cpu/mcheck/x86_mca.h
+++ b/xen/arch/x86/cpu/mcheck/x86_mca.h
@@ -113,7 +113,7 @@ static inline int mcabanks_test(int bit, struct mca_banks*
banks)
return test_bit(bit
On Thu, 2023-07-13 at 15:27 +0200, Jan Beulich wrote:
> I don't understand. My earlier comment was affecting all checks of
> uart->irq alike, as I'm unconvinced IRQ0 may not possibly be usable
> on some architecture / platform. IOW I don't see why the check in
> ns16550_init_postirq() would allow u
On 13.07.2023 15:19, Oleksii wrote:
> On Thu, 2023-07-13 at 12:08 +0200, Jan Beulich wrote:
>> On 13.07.2023 11:30, Oleksii Kurochko wrote:
>>> --- a/xen/drivers/char/ns16550.c
>>> +++ b/xen/drivers/char/ns16550.c
>>> @@ -1791,8 +1791,16 @@ static int __init
>>> ns16550_uart_dt_init(struct dt_devic
On Thu, 2023-07-13 at 12:08 +0200, Jan Beulich wrote:
> On 13.07.2023 11:30, Oleksii Kurochko wrote:
> > --- a/xen/drivers/char/ns16550.c
> > +++ b/xen/drivers/char/ns16550.c
> > @@ -1791,8 +1791,16 @@ static int __init
> > ns16550_uart_dt_init(struct dt_device_node *dev,
> > }
> >
> >
On 17.03.2023 20:53, Elliott Mitchell wrote:
> ARRAY_SIZE() makes future maintainance easier and thus less likely for
> bugs to occur.
>
> Signed-off-by: Elliott Mitchell
Acked-by: Jan Beulich
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
> I'd really prefer this patch (series or single) is not accepted. This
> will cause problems for everyone cherry-picking patches to a
> downstream kernel (LTS or distro tree). I usually wouldn't expect
> sympathy here, but the
On 17.03.2023 20:53, Elliott Mitchell wrote:
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -1410,6 +1410,7 @@ static void cf_check error_interrupt(struct
> cpu_user_regs *regs)
> ", Received illegal vector",
> ", Illegal register address",
> };
> +const ch
On 17.03.2023 20:45, Elliott Mitchell wrote:
> Rather than adding ", " with each printf(), simply include them in the
> string initially. This allows converting to strlcat() or other methods
> which strictly concatenate, rather than formatting.
>
> Signed-off-by: Elliott Mitchell
Acked-by: Jan
On 06.07.2023 20:54, Jason Andryuk wrote:
> @@ -531,6 +535,103 @@ int get_hwp_para(unsigned int cpu,
> return 0;
> }
>
> +int set_hwp_para(struct cpufreq_policy *policy,
> + struct xen_set_cppc_para *set_cppc)
> +{
> +unsigned int cpu = policy->cpu;
> +struct hwp_drv
On 06.07.2023 20:54, Jason Andryuk wrote:
> Extend xen_get_cpufreq_para to return hwp parameters. HWP is an
> implementation of ACPI CPPC (Collaborative Processor Performance
> Control). Use the CPPC name since that might be useful in the future
> for AMD P-state.
>
> We need the features bitmas
On 13.07.2023 13:55, Oleksii wrote:
> On Thu, 2023-07-13 at 11:13 +0100, Julien Grall wrote:
>> Hi Jan,
>>
>> On 13/07/2023 11:08, Jan Beulich wrote:
>>> On 13.07.2023 11:30, Oleksii Kurochko wrote:
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1791,8 +1791,16
On 13.07.2023 13:29, Roger Pau Monné wrote:
> On Thu, Jul 13, 2023 at 09:49:14AM +0200, Jan Beulich wrote:
>> One other thing I finally figured was confusing me in the
>> description of the patch; re-quoting that paragraph here:
>>
>> "Fix this by moving the masking of IO-APIC pins ahead of the ena
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.5-rc2-tag
xen: branch for v6.5-rc2
It contains the following patches:
- a cleanup of the Xe related ELF-notes
- a fix for virtio handling in Xen dom0 when running Xen in a VM
Tha
Hi,
On 13/07/2023 12:55, Oleksii wrote:
On Thu, 2023-07-13 at 11:13 +0100, Julien Grall wrote:
Hi Jan,
On 13/07/2023 11:08, Jan Beulich wrote:
On 13.07.2023 11:30, Oleksii Kurochko wrote:
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1791,8 +1791,16 @@ static int __in
On Thu, 2023-07-13 at 11:13 +0100, Julien Grall wrote:
> Hi Jan,
>
> On 13/07/2023 11:08, Jan Beulich wrote:
> > On 13.07.2023 11:30, Oleksii Kurochko wrote:
> > > --- a/xen/drivers/char/ns16550.c
> > > +++ b/xen/drivers/char/ns16550.c
> > > @@ -1791,8 +1791,16 @@ static int __init
> > > ns16550_u
Hi,
On 13/07/2023 12:36, Oleksii wrote:
On Thu, 2023-07-13 at 10:43 +0100, Julien Grall wrote:
Hi Oleksii,
Title: IMO, Your patch doesn't do any refactor. Instead, it add
support
for polling when using the DT.
Agree. It would be better to rephrase the title.
On 13/07/2023 10:30, Oleksii Ku
Hi Julien,
On Thu, 2023-07-13 at 10:43 +0100, Julien Grall wrote:
> Hi Oleksii,
>
> Title: IMO, Your patch doesn't do any refactor. Instead, it add
> support
> for polling when using the DT.
Agree. It would be better to rephrase the title.
>
> On 13/07/2023 10:30, Oleksii Kurochko wrote:
> > I
On Thu, Jul 13, 2023 at 09:49:14AM +0200, Jan Beulich wrote:
> On 12.07.2023 17:41, Roger Pau Monné wrote:
> > On Wed, Jul 12, 2023 at 04:50:34PM +0200, Jan Beulich wrote:
> >> Hmm. The question really is which of the changes we want to backport.
> >> That one should be first. While it's largely gu
Currently, resuming an S3 suspended guest results in the following
assertion failure:
ASSERT
MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.c(41):
MemoryLength > 0
This happens because some parts of the S3 suspend and resume paths
are missing in order for S3 to work. For insta
On Thu, Jul 13, 2023 at 08:52:12AM +0200, Geert Uytterhoeven wrote:
> Hi Uwe,
>
> Let's add some fuel to keep the thread alive ;-)
>
> On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König
> wrote:
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> > > I think this is an unnecessary c
On Tue, Jul 11, 2023 at 11:22:30AM +0200, Roger Pau Monne wrote:
> diff --git a/tools/libs/light/libxl_cpuid.c b/tools/libs/light/libxl_cpuid.c
> index b1c4f8f2f45b..86a08f29a19c 100644
> --- a/tools/libs/light/libxl_cpuid.c
> +++ b/tools/libs/light/libxl_cpuid.c
> @@ -158,6 +158,57 @@ static int c
Hi Jan,
On 13/07/2023 11:08, Jan Beulich wrote:
On 13.07.2023 11:30, Oleksii Kurochko wrote:
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1791,8 +1791,16 @@ static int __init ns16550_uart_dt_init(struct
dt_device_node *dev,
}
res = platform_get_irq(dev,
On 13.07.2023 11:30, Oleksii Kurochko wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -1791,8 +1791,16 @@ static int __init ns16550_uart_dt_init(struct
> dt_device_node *dev,
> }
>
> res = platform_get_irq(dev, 0);
> -if ( ! res )
> -return
On Thu, Jul 13, 2023 at 12:03:05PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello Jani,
> >
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Jul 2023, Uwe Kleine-König
> >> wrote:
> >> > Hello,
> >> >
> >> > while I debugged an
Hi Oleksii,
Title: IMO, Your patch doesn't do any refactor. Instead, it add support
for polling when using the DT.
On 13/07/2023 10:30, Oleksii Kurochko wrote:
In ns16550_init_postirq() there is the following check:
if ( uart->irq > 0 )
{
uart->irqaction.handler = ns16550_i
Hi Jani,
On Thu, Jul 13, 2023 at 11:03 AM Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Jul 2023, Uwe Kleine-König
> >> wrote:
> >> > while I debugged an issue in the imx-lcdc driver I was cons
Hi,
On 13/07/2023 08:02, Jens Wiklander wrote:
+}
+
static uint64_t regpair_to_uint64(register_t reg0, register_t reg1)
{
return ((uint64_t)reg0 << 32) | (uint32_t)reg1;
@@ -1732,6 +1737,7 @@ static const struct tee_mediator_ops optee_ops =
{
.probe = optee_probe,
.
In ns16550_init_postirq() there is the following check:
if ( uart->irq > 0 )
{
uart->irqaction.handler = ns16550_interrupt;
uart->irqaction.name= "ns16550";
uart->irqaction.dev_id = port;
if ( (rc = setup_irq(uart->irq, 0, &uart->irqaction)) != 0 )
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> Hello Jani,
>
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
>> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
>> > Hello,
>> >
>> > while I debugged an issue in the imx-lcdc driver I was constantly
>> > irritated about struct drm_devic
flight 181777 xen-unstable real [real]
flight 181779 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181777/
http://logs.test-lab.xenproject.org/osstest/logs/181779/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 13/07/2023 08:37, Bertrand Marquis wrote:
On 13 Jul 2023, at 09:12, Jens Wiklander wrote:
It makes it easier for reviewers if you put the changelog per patch
instead of having all of them in the cover letter.
OK. When I post the next version is it enough to document the v9->v10
changes
> On 13 Jul 2023, at 09:30, Edwin Török wrote:
>
> From: Edwin Török
>
> `Tag_cons` is `0` and is meant to be used as the tag argument for
> `caml_alloc`/`caml_alloc_small`
> when constructing a non-empty list.
> The empty list is `Val_emptylist` instead (which is really just `Val_int(0)`).
On 12.07.2023 21:59, Elliott Mitchell wrote:
> This series has been seen previously. The issue is pretty simple, if
> ACPI errors occur there is a high probability they will occur on multiple
> cores at once.
Nit: Both here and in the title s/ACPI/APIC/, to not misguide people about
the area the
On 12.07.2023 12:32, Simone Ballarin wrote:
> Changes to macros 'X86_CR0_PG' and 'MSR_EFER' in files
> "xen/arch/x86/include/asm/x86-defns.h" and
> "xen/arch/x86/include/asm/msr-index.h"
> are not made since they are used also in assembly files.
Following on from yesterday's remark here: Both fil
From: Edwin Török
`Tag_cons` is `0` and is meant to be used as the tag argument for
`caml_alloc`/`caml_alloc_small`
when constructing a non-empty list.
The empty list is `Val_emptylist` instead (which is really just `Val_int(0)`).
Assigning `0` to a list value like this is equivalent to assigni
Hi
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
Rather than renaming dev in all the
Hi
Am 12.07.23 um 20:31 schrieb Sean Paul:
On Wed, Jul 12, 2023 at 10:52 AM Jani Nikula wrote:
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because
On 12.07.2023 17:41, Roger Pau Monné wrote:
> On Wed, Jul 12, 2023 at 04:50:34PM +0200, Jan Beulich wrote:
>> Hmm. The question really is which of the changes we want to backport.
>> That one should be first. While it's largely guesswork, I'd be more
>> inclined to take the change that has less of
Hi
Am 12.07.23 um 18:10 schrieb Uwe Kleine-König:
Hello Jani,
On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variable
On 12.07.23 10:48, Viresh Kumar wrote:
Xen provides support for injecting interrupts to the guests via the
HYPERVISOR_dm_op() hypercall. The same is used by the Virtio based
device backend implementations, in an inefficient manner currently.
Generally, the Virtio backends are implemented to work
Hi Jens,
> On 13 Jul 2023, at 09:12, Jens Wiklander wrote:
>
> Hi Bertrand,
>
> On Wed, Jul 12, 2023 at 11:39 AM Bertrand Marquis
> wrote:
>>
>> Hi Jens,
>>
>>> On 5 Jul 2023, at 11:34, Jens Wiklander wrote:
>>>
>>> Hi,
>>>
>>> This patch sets add an FF-A [1] mediator to the TEE mediator
Hi Uwe,
Let's add some fuel to keep the thread alive ;-)
On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König
wrote:
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> > On Wed, 12 Jul 2023, Uwe Kleine-König
> > wrote:
> > > Hello,
> > >
> > > while I debugged an issue in the imx-lcd
Hi, Ayan
On 2023/7/5 23:35, Ayan Kumar Halder wrote:
Hi Penny,
On 26/06/2023 04:34, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and caution when opening attachments, clicking
links, or responding to this email.
We inherit p2m_
Hi,
On 2023/7/5 21:52, Julien Grall wrote:
Hi,
On 05/07/2023 10:53, Penny Zheng wrote:
Since if not and when anyone wants to update map_pages_to_xen(),
destroy_xen_mappings() and modify_xen_mappings() in the future, it
is possible for them to leave changes in only one file.
The helpers are
Hi Ayan
On 2023/7/5 22:21, Ayan Kumar Halder wrote:
On 26/06/2023 04:34, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and caution when opening attachments, clicking
links, or responding to this email.
VSTCR_EL2, Virtualization
Hi Bertrand,
On Wed, Jul 12, 2023 at 11:39 AM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 5 Jul 2023, at 11:34, Jens Wiklander wrote:
> >
> > Hi,
> >
> > This patch sets add an FF-A [1] mediator to the TEE mediator framework
> > already present in Xen. The FF-A mediator implements the subset
Hi Ayan
On 2023/7/5 22:01, Ayan Kumar Halder wrote:
Hi Penny,
On 26/06/2023 04:34, Penny Zheng wrote:
CAUTION: This message has originated from an External Source. Please
use proper judgment and caution when opening attachments, clicking
links, or responding to this email.
A set of functio
Hi Julien,
On Wed, Jul 12, 2023 at 11:53 AM Julien Grall wrote:
>
> Hi Jens,
>
> On 05/07/2023 10:34, Jens Wiklander wrote:
> > Adds a progress state for tee_domain_teardown() to be called from
> > arch_domain_teardown(). tee_domain_teardown() calls the new callback
> > domain_teardown() in struc
94 matches
Mail list logo
