It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.
Signed-off-by: Stewart Hildebrand <stewart.hildebr...@dornerworks.com>
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions
A user may choose to set his/her own PKG_CONFIG_PATH, which is useful in the
case of cross-compiling. We don't want to completely override the
PKG_CONFIG_PATH, just add to it.
Signed-off-by: Stewart Hildebrand <stewart.hildebr...@dornerworks.com>
---
tools/Makefile | 2 +-
1 file chan
> From: Ian Jackson
> Sent: Thursday, April 26, 2018 1:44 PM
> Subject: Re: [PATCH] tools: prepend to PKG_CONFIG_PATH when
> configuring qemu
>
> Stewart Hildebrand writes ("[PATCH] tools: prepend to PKG_CONFIG_PATH
> when configuring qemu"):
> >
08641a9e8870d3b174d95aaa55ecba43387563b5 would be nice to have included.
Stew
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
Jan Beulich
Sent: Wednesday, July 4, 2018 6:42 AM
To: xen-devel
Cc: anthony.per...@citrix.com; Ian Jackson ;
0cc1d905fc6ed4c7e10d8d35e
Thanks,
Stewart Hildebrand
DornerWorks, Ltd.
>
> Thanks and regards,
> George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 11/09/2018 17:48, Amit Singh Tomar wrote:
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index d63734f..ef87b5c 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -120,8 +127,8 @@ efi_head:
> add x13, x18, #0x16
> b
On Monday, October 8, 2018 9:06 AM, Jan Beulich wrote:
> All,
>
> both releases are due in about a month's time. Please point out
> backports you find missing from their respective staging branches,
> but which you consider relevant. On top of what I've just pushed
> there I have
>
> 2fb57e4bee
On Wednesday, November 7, 2018 10:42 AM, Ian Jackson wrote:
> Are these commitids from xen.git#master and the corresponding
> qemu-xen.git branch ?
Sorry, no, a few of those were from xen.git#staging-4.9 and
qemu-xen.git#staging-4.9.
Here's the same list, but with commit ids for the same
On Monday, January 14, 2019 10:53 AM, Jan Beulich wrote:
> > Hi Jan,
> >
> > On 14/01/2019 10:11, Jan Beulich wrote:
> > On 11.01.19 at 19:04, wrote:
> >>> On Fri, 11 Jan 2019, Jan Beulich wrote:
> >>> On 11.01.19 at 03:14, wrote:
> > Hi Juergen, Jan,
> >
> > I spoke with
On Tuesday, January 15, 2019 3:21 AM, Jan Beulich wrote:
> >>> On 14.01.19 at 22:18, wrote:
> > Hi Jan,
> >
> > One question below to make a decision on the way forward.
> >
> > On Mon, 14 Jan 2019, Jan Beulich wrote:
> >> >>> On 14.01.19 at 04:45, wrote:
> >> > The difference would be whether
On Friday, January 18, 2019 6:05 PM, Stefano Stabellini wrote:
> On Fri, 18 Jan 2019, Jan Beulich wrote:
> > >>> On 18.01.19 at 02:24, wrote:
> > > On Thu, 17 Jan 2019, Jan Beulich wrote:
> > >> >>> On 17.01.19 at 01:37, wrote:
> > >> > On Wed, 16 Jan 2019, Jan Beulich wrote:
> > >> >> In any
On Thursday, January 10, 2019 12:30 PM, Stefano Stabellini wrote:
> On Thu, 10 Jan 2019, Jan Beulich wrote:
> > >>> On 10.01.19 at 03:40, wrote:
> > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
> > > wrote:
> > >
> > >> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> >
On Friday, January 11, 2019 1:04 PM, Stefano Stabellini wrote:
> On Fri, 11 Jan 2019, Jan Beulich wrote:
> > >>> On 11.01.19 at 03:14, wrote:
> > > Hi Juergen, Jan,
> > >
> > > I spoke with Julien: we are both convinced that the unsigned long
> > > solution is best. But Julien also did some
On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
> On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
> >
> > Why don't we change the type of _start so it's not a pointer type?
>
> Can you suggest a type that would be suitable?
>
> Cheers,
Yes. My opinion is
On Friday, January 11, 2019 4:38 PM, Stefano Stabellini wrote:
> On Fri, 11 Jan 2019, Stewart Hildebrand wrote:
> > On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
> > > On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
> > > >
> > > > Why
On Wednesday, July 31, 2019 8:32 AM, Andre Przywara
wrote:
>On Mon, 29 Jul 2019 09:19:18 -0400
>Stewart Hildebrand wrote:
>
>Hi,
>
>> This is a series to enable UART console for Raspberry Pi 4. Note that I'm
>> relying on the firmware to initialize t
On Wednesday, July 31, 2019 8:04 AM, Julien Grall wrote:
>Hi Stewart,
Hi Julien
>On 29/07/2019 14:19, Stewart Hildebrand wrote:
>> The aux peripherals (uart1, spi1, and spi2) share an IRQ and a page of
>> memory. For debugging, it is helpful to use the aux UART in Xen. In
Upstream Linux kernel will use "brcm,bcm2711" as the compatible string
for Raspberry Pi 4 [1]. Add this string to our platform compatible list
for compatibility with the upstream kernel.
[1] https://patchwork.kernel.org/patch/11092621/
Signed-off-by: Stewart Hildebrand
---
xe
On Friday, September 13, 2019 5:42 PM, Julien Grall
wrote:
>Hi,
>
>On 9/13/19 8:11 PM, Stewart Hildebrand wrote:
>> Upstream Linux kernel will use "brcm,bcm2711" as the compatible string
>> for Raspberry Pi 4 [1]. Add this string to our platform compa
O. This will result to cache incoherency.
Thanks for the info. There is also a 1GB slot shared with GPU [1].
Stewart Hildebrand
DornerWorks, Ltd
[1] https://github.com/raspberrypi/linux/issues/3093#issuecomment-515438627
___
Xen-devel mailing l
other than the UART to prevent mapping the shared
IRQ and memory range to dom0.
Signed-off-by: Stewart Hildebrand
---
xen/arch/arm/platforms/Makefile| 1 +
xen/arch/arm/platforms/brcm-raspberry-pi.c | 55 ++
2 files changed, 56 insertions(+)
create mode 100644
-width in the Xen driver
* Blacklist other aux peripherals in platform settings (spi1, spi2, and a
couple of base aux registers)
Thanks,
Stewart Hildebrand
DornerWorks, Ltd
[1] https://github.com/dornerworks/xen-rpi4-builder
Stewart Hildebrand (2):
ns16550: Add compatible string for Raspberry Pi 4
tty/serial/8250/8250_bcm2835aux.c
[3]
https://www.kernel.org/doc/Documentation/devicetree/bindings/serial/brcm,bcm2835-aux-uart.txt
Signed-off-by: Stewart Hildebrand
---
xen/drivers/char/ns16550.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/drivers/char/ns16550.c b/xen/dr
ermine whether to skip over a zone.
With this behavior, it is possible for free pages to collect in a zone
with the avail counter smaller than the actual page count, resulting
in free pages that are not allocable.
This commit adds a check to compare the adjacent block's zone with the
current zone befor
On Friday, August 9, 2019 2:24 PM, Stefano Stabellini
>On Fri, 9 Aug 2019, Stewart Hildebrand wrote:
>> Here is Jeff's initial patch for the issue.
>
>I committed Julien's patch for now,
Great! Thanks!
>but if we need to make any changes
>or decide for a better alternative,
Signed-off-by: Stewart Hildebrand
---
docs/misc/arm/early-printk.txt | 1 +
xen/arch/arm/Rules.mk | 1 +
2 files changed, 2 insertions(+)
diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index 89e081e51e..8af5a90695 100644
--- a/docs/misc/arm/early-printk.txt
independently came up with a printk
configuration [2]. With this series, you'd no longer need to remember the base
address, just do CONFIG_EARLY_PRINTK=rpi4.
Thanks,
Stewart Hildebrand
DornerWorks, Ltd
[1] https://github.com/dornerworks/xen-rpi4-builder
[2] https://lists.xenproject.org/archives
Signed-off-by: Stewart Hildebrand
---
xen/drivers/char/ns16550.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index e518f2d790..c8d7c9b710 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1611,6 +1611,7
On Wednesday, July 24, 2019 10:47 AM, Julien Grall wrote:
>Hi,
>
>Thank you for your series. Please use git-send-email so your series is threaded
>correctly and sent in plain text (not HTML!).
My apologies. I will do this next time I have something to send.
>I guess you are not using Andre's
CC'ing Julien's new email address
On Thursday, November 14, 2019 2:33 PM, Jeff Kubascik wrote:
>Hello,
>
>I'm working on a port of a RTOS (RTEMS) to Xen on ARM, and came across an
>interesting finding in how Xen emulates the physical timer on ARM.
>
>In testing different configurations of the
On Friday, November 15, 2019 3:11 PM, Stewart Hildebrand wrote:
>diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>index 75921724dd..982afaadbd 100644
>--- a/xen/arch/arm/gic.c
>+++ b/xen/arch/arm/gic.c
>@@ -92,8 +92,7 @@ void gic_save_state(struct vcpu *v)
> void gic_s
On Friday, November 15, 2019 3:11 PM, Stewart Hildebrand write:
[...]
>diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>index 113655a789..75921724dd 100644
>--- a/xen/arch/arm/gic.c
>+++ b/xen/arch/arm/gic.c
[...]
>@@ -78,6 +89,25 @@ void gic_save_state(struct vcp
it is taken by the caller). I don't think this is an
issue (and avoiding this would make things more complex)
Signed-off-by: Ian Campbell
Signed-off-by: Stewart Hildebrand
---
v2: New patch (maybe, it's been a while...)
v3: Rebase + trivial fixups
---
Note: I have not given much thought regarding
From: Ian Campbell
s/it/if/ makes more sense.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall [1]
Acked-by: Stefano Stabellini [2]
[1] https://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00986.html
[2]
r PPI state.
HACK: Force virt timer to PPI0 (IRQ16)
Stewart Hildebrand (4):
xen: arm: remove is_assignable_irq
Add NR_SGIS and NR_PPIS definitions to irq.h
xen: arm: vgic: allow delivery of PPIs to guests
xen: arm: vgic: don't fail if IRQ is already connected
xen/arch/arm/gic-v2
-off-by: Stewart Hildebrand
---
v3: Address feedback from v2 [1]:
* Add a comment to explain that PPI are always below 31.
* Use uint32_t for pendingr, activer, enabler
* Fixup register names in gic-v3.c
* Add newlines for clarity
* Make gicv3_irq_enable/disable declarations static
lt;0 123 4>;
In this case it seems that we are invoking vgic_connect_hw_irq multiple
times for the same IRQ.
Rework the checks to allow booting in this scenario.
I have not seen any cases where the pre-existing p->desc is any different from
the new desc, so BUG() out if they're different for now.
Sign
Allow vgic_get_hw_irq_desc to be called with a vcpu argument.
Use vcpu argument in vgic_connect_hw_irq.
vgic_connect_hw_irq is called for PPIs and SPIs, not SGIs. Enforce with
ASSERTs.
Signed-off-by: Stewart Hildebrand
---
v3: new patch
---
Note: I have only modified the old vgic to allow
These will be used in a follow-up patch.
Signed-off-by: Stewart Hildebrand
---
v3: new patch
---
xen/include/asm-arm/irq.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 3b37a21c06..367fe6269c 100644
--- a/xen
It only had 1 caller.
Reverse the condition for readability.
Signed-off-by: Stewart Hildebrand
---
v3: new patch
---
xen/arch/arm/irq.c| 9 ++---
xen/include/asm-arm/irq.h | 2 --
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm
From: Ian Campbell
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall [1]
Acked-by: Stefano Stabellini [2]
[1] https://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00985.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02646.html
---
v3:
* Rebase (no
registers to save and restore the active
state of the interrupt, which prevents the nested invocations which
the current masking works around.
Signed-off-by: Ian Campbell
Signed-off-by: Stewart Hildebrand
---
v2: Rebased, in particular over Julien's passthrough stuff which
reworked a bunch
functionality to save and restore the PPI state.
The vtimer driver will do so shortly.
Signed-off-by: Ian Campbell
Signed-off-by: Stewart Hildebrand
---
v3:
* Change calls to gic_set_irq_properties() to gic_set_irq_type() and
gic_set_irq_priority() due to following commits:
16580cde5a
From: Ian Campbell
Just for testing so the guest vtimer ppi it isn't the same as the
physical virt timer PPI on my platform, and therefore allows to
exercise the non-1:1 bits of the code.
---
xen/include/public/arch-arm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tuesday, November 5, 2019 10:09 AM, Wei Liu wrote:
>On Tue, Nov 05, 2019 at 08:51:52AM -0500, Stewart Hildebrand wrote:
>> Add DornerWorks internal list. This will forward to relevant people
>> within DornerWorks.
>>
>> Add myself to MAINTAINERS for ARINC653 schedule
VanVossen
+M: Stewart Hildebrand
S: Supported
+L: DornerWorks Xen-Devel
F: xen/common/sched_arinc653.c
F: tools/libxc/xc_arinc653.c
--
2.23.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
aspberrypi/linux/commit/53fdd7b8c8cb9c87190caab4fd459f89e1b4a7f8
Signed-off-by: Stewart Hildebrand
---
v2:
* Remove abandoned bcm2838 convention
* Rename variables within file with rpi4_* prefix
v3:
* Add note to commit message
* CC Juergen
---
xen/arch/arm/platforms/brcm-raspberry
On Tuesday, October 15, 2019 7:02 AM, Julien Grall wrote:
>Hi,
Hi!
>
>On 10/9/19 5:59 PM, Stewart Hildebrand wrote:
>> However, even with Xen looking for bcm2838, you wouldn't be able to
>> grab one of those releases and boot without running into other issues.
>>
On Thursday, October 24, 2019 9:37 AM, Julien Grall wrote:
>Hi,
>
>Jumping into the conversation.
>
>On 24/10/2019 14:06, Jeff Kubascik wrote:
>> We would like to remove our current two developers who are listed as M: for
>> the
>> ARINC653 scheduler code. Since M: is just a "Mail patches to"
On Wednesday, October 9, 2019 11:30 AM, Julien Grall
wrote:
>On 04/10/2019 01:47, Stewart Hildebrand wrote:
>> Both upstream [1] and downstream [2] Linux kernels use "brcm,bcm2711"
>> as the compatible string for Raspberry Pi 4. Add this string to our
>> platform
e
is meant to cover the Raspberry Pi 4 platform.
[1] https://patchwork.kernel.org/patch/11165407/
[2]
https://github.com/raspberrypi/linux/commit/53fdd7b8c8cb9c87190caab4fd459f89e1b4a7f8
Signed-off-by: Stewart Hildebrand
---
xen/arch/arm/platforms/brcm-raspberry-pi.c | 12 ++--
1 file
On Tuesday, September 17, 2019 7:05 AM, Julien Grall
wrote:
>Hi Stewart,
>
>On 9/14/19 2:22 AM, Stewart Hildebrand wrote:
>> On Friday, September 13, 2019 5:42 PM, Julien Grall
>> wrote:
>>> 2) Is the patch [1] merged? If so, which version?
>>
>>
On Wednesday, February 26, 2020 6:34 AM, Anthony PERARD wrote:
>Patch series available in this git branch:
>https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
>br.build-system-xen-v3
>
>v3:
>- new patches that do some cleanup or fix issues
>- have rework most patches, to have better
On Tuesday, February 4, 2020 10:22 AM, Jan Beulich wrote:
>On 04.02.2020 16:14, Stewart Hildebrand wrote:
>> From: Jeff Kubascik
>>
>> The Xen heap is split up into nodes and zones. Each node + zone is
>> managed as a separate pool of memory.
>>
&g
On Tuesday, February 4, 2020 9:30 AM, Stewart Hildebrand wrote:
>diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
>index 97902d42c1..7d39dd5be0 100644
>--- a/xen/common/page_alloc.c
>+++ b/xen/common/page_alloc.c
>@@ -1462,6 +1462,7 @@ static void
Kubascik
Signed-off-by: Stewart Hildebrand
---
v2: s/pg-mask/predecessor/
---
xen/common/page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 97902d42c1..735049fe3e 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common
Do not apply this patch - it is intended as a test case to show how the
problem presents itself. This was tested on a Xiling Zynq UltraScale+
MPSoC with CONFIG_DEBUG=y.
Add an assert for merging pages across zones
Revert "Check zone before merging adjacent blocks in heap"
Revert
From: Jeff Kubascik
The Xen heap is split up into nodes and zones. Each node + zone is
managed as a separate pool of memory.
When returning pages to the heap, free_heap_pages will check adjacent
blocks to see if they can be combined into a larger block. However, the
zone of the adjacent block
/to/xen/xen'
tools/kconfig/Makefile:95: recipe for target 'custom.config' failed
Signed-off-by: Stewart Hildebrand
---
It's possible there are other places where the Makefile path will need
to be changed. This just happened to be the one that failed for me.
---
xen/tools/kconfig/Makefile | 2
This series fixes a couple of kconfig errors that I observed while
invoking a build with a defconfig and config fragment.
I invoked the build as follows:
cat > xen/arch/arm/configs/custom.config <
This resolves the following observed error:
/bin/sh: /path/to/xen/xen/../xen/scripts/kconfig/merge_config.sh: No such file
or directory
Signed-off-by: Stewart Hildebrand
---
xen/tools/kconfig/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/tools/kconfig
This resolves the following observed error during config merge:
/bin/sh /path/to/xen/xen/../xen/tools/kconfig/merge_config.sh -m .config
/path/to/xen/xen/../xen/arch/arm/configs/custom.config
Using .config as base
Merging /path/to/xen/xen/../xen/arch/arm/configs/custom.config
#
# merged
Friday, May 15, 2020 2:25 PM, Stewart Hildebrand wrote:
>Signed-off-by: Stewart Hildebrand
I forgot to include Anthony's Reviewed-by from v1
https://lists.xenproject.org/archives/html/xen-devel/2020-05/msg00848.html
On Thursday, September 17, 2020 12:19 PM, Andrew Cooper wrote:
>On 17/09/2020 15:57, Stewart Hildebrand wrote:
>> On Thursday, September 17, 2020 10:43 AM, Andrew Cooper wrote:
>>> On 16/09/2020 19:18, Jeff Kubascik wrote:
>>>> +/*
>>>> + * A handle wit
On Thursday, September 17, 2020 11:20 AM, Dario Faggioli wrote:
>On Thu, 2020-09-17 at 15:10 +0000, Stewart Hildebrand wrote:
>> On Thursday, September 17, 2020 5:04 AM, Jürgen Groß wrote:
>> > On 16.09.20 20:18, Jeff Kubascik wrote:
>> > > This change is an over
On Thursday, September 17, 2020 5:04 AM, Jürgen Groß wrote:
>On 16.09.20 20:18, Jeff Kubascik wrote:
>> This change is an overhaul of the ARINC653 scheduler to enable CAST-32A
>> multicore scheduling. CAST-32A specifies that only one partition
>> (domain) can run during a minor frame, but that
On Thursday, September 17, 2020 10:43 AM, Andrew Cooper wrote:
>On 16/09/2020 19:18, Jeff Kubascik wrote:
>> +/*
>> + * A handle with all zeros represents domain 0 if present, otherwise idle
>> UNIT
>> + */
>> +#define DOM0_HANDLE ((const xen_domain_handle_t){0})
>
>This isn't accurate.
>
>There
On Friday, December 17, 2021 9:20 AM, Andrew Cooper wrote:
> On 22/11/2021 14:54, Stewart Hildebrand wrote:
> > On Monday, November 22, 2021 9:39 AM, From: Jan Beulich wrote:
> >> On 22.11.2021 15:17, Stewart Hildebrand wrote:
> >>> Josh works at another company now
Josh works at another company now
Signed-off-by: Stewart Hildebrand
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4956db1011..fc8b2c1169 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -221,7 +221,6 @@ F: xen/include/xen/argo.h
F: xen
On Monday, November 22, 2021 9:39 AM, From: Jan Beulich wrote:
>On 22.11.2021 15:17, Stewart Hildebrand wrote:
>> Josh works at another company now
>
>You don't happen to know his email there, do you? Else if would have been
>good to Cc him so he could confirm.
>
>Jan
On 9/11/23 07:10, Jan Beulich wrote:
> On 09.09.2023 04:16, Stewart Hildebrand wrote:
>> @@ -544,6 +545,18 @@ static int cf_check init_bars(struct pci_dev *pdev)
>> if ( rc )
>> return rc;
>>
>> +/*
>> + * If mask_cap_list is true,
On 8/22/23 09:54, Jan Beulich wrote:
> On 22.08.2023 03:29, Stewart Hildebrand wrote:
>> Introduce a handler for the PCI status register, with ability to mask the
>> capabilities bit. The status register is write-1-to-clear, so introduce
>> handling
>> for th
On 8/30/23 10:05, Jan Beulich wrote:
> On 28.08.2023 19:56, Stewart Hildebrand wrote:
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -413,6 +413,18 @@ static void cf_check cmd_write(
>> pci_conf_write16(pdev->sbdf, reg, cmd)
Convert pci_find_*cap* functions and call sites to pci_sbdf_t, and remove some
now unused local variables. Also change to more appropriate types on lines that
are already being modified as a result of the pci_sbdf_t conversion.
Signed-off-by: Stewart Hildebrand
---
I built
Introduce a handler for the PCI status register, with ability to mask the
capabilities bit. The status register is write-1-to-clear, so introduce handling
for this type of register in vPCI.
The mask_cap_list flag will be set in a follow-on patch.
Signed-off-by: Stewart Hildebrand
---
v3->
Use pdev->sbdf instead of the PCI_SBDF macro in calls to pci_* functions
where appropriate. Move NULL check earlier.
Suggested-by: Jan Beulich
Signed-off-by: Stewart Hildebrand
---
v3->v4:
* new patch
Suggested-by tag added based on conversation at [1]
[1] https://lists.xenproje
for RAZ registers, or
registers whose value doesn't change.
Introduce pci_find_next_cap_ttl() helper while adapting the logic from
pci_find_next_cap() to suit our needs, and implement the existing
pci_find_next_cap() in terms of the new helper.
Signed-off-by: Stewart Hildebrand
---
v3->v4:
* m
Add support for a read-only bit mask for vPCI register handlers.
Signed-off-by: Stewart Hildebrand
---
v3->v4:
* new patch
RFC: It seemed like a low-hanging fruit to add support for ro mask. Let me know
what you think, and I could squash it into the status handler patch for the
n
used to avoid transient
dead code situation
* add new RFC patch, possibly throwaway, to get an idea of what it would look
like to get rid of the (void *)(uintptr_t) cast by introducing a new memory
allocation
[1] https://lists.xenproject.org/archives/html/xen-devel/2023-07/msg01281.html
St
These were left over after a previous pci_sbdf_t conversion.
Fixes: 0c38c61aad21 ("pci: switch pci_conf_write32 to use pci_sbdf_t")
Signed-off-by: Stewart Hildebrand
---
v3->v4:
* new patch: this change was split from
("xen/pci: convert pci_find_*cap* to pci_sbdf_t&qu
for RAZ registers, or
registers whose value doesn't change.
Introduce pci_find_next_cap_ttl() helper while adapting the logic from
pci_find_next_cap() to suit our needs, and implement the existing
pci_find_next_cap() in terms of the new helper.
Signed-off-by: Stewart Hildebrand
Reviewed-by: Jan
On 8/29/23 19:19, Volodymyr Babchuk wrote:
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index 1e82217200..e351db4620 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -523,6 +546,14 @@ static void cf_check cmd_write(
>
Interrupt status introduced in PCI 2.3
Immediate readiness introduced in PCIe 4.0
Signed-off-by: Stewart Hildebrand
---
v4->v5:
* new patch
---
xen/include/xen/pci_regs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/xen/pci_regs.h b/xen/include/xen/pci_regs.h
in
Use pdev->sbdf instead of the PCI_SBDF macro in calls to pci_* functions
where appropriate. Move NULL check earlier.
Suggested-by: Jan Beulich
Signed-off-by: Stewart Hildebrand
Reviewed-by: Jan Beulich
---
v4->v5:
* add Jan's R-b
v3->v4:
* new patch
Suggested-by tag ad
On 8/31/23 08:11, Jan Beulich wrote:
> On 28.08.2023 19:56, Stewart Hildebrand wrote:
>> Currently, Xen vPCI only supports virtualizing the MSI and MSI-X
>> capabilities.
>> Hide all other PCI capabilities (including extended capabilities) from domUs
>> for
&g
would look
like to get rid of the (void *)(uintptr_t) cast by introducing a new memory
allocation
[1] https://lists.xenproject.org/archives/html/xen-devel/2023-07/msg01281.html
Stewart Hildebrand (5):
xen/pci: convert pci_find_*cap* to pci_sbdf_t
x86/msi: rearrange read_pci_mem_bar sli
Convert pci_find_*cap* functions and call sites to pci_sbdf_t, and remove some
now unused local variables. Also change to more appropriate types on lines that
are already being modified as a result of the pci_sbdf_t conversion.
Signed-off-by: Stewart Hildebrand
Reviewed-by: Jan Beulich
---
I
On 8/29/23 19:19, Volodymyr Babchuk wrote:
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index e58bbdf68d..e96d7b2b37 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -477,6 +477,72 @@ static void cf_check bar_write(
>
:
res_mask: read as zero, write ignore
ro_mask: read normal, write ignore
rw1c_mask: read normal, write 1 to clear
The mask_cap_list flag will be set in a follow-on patch.
Signed-off-by: Stewart Hildebrand
---
v4->v5:
* add support for res_mask
* add support for ro_mask (squash ro_mask pa
the header. Use the effective image size for calculating the
next load address and for populating the size in the /chosen/dom*/reg property.
Signed-off-by: Stewart Hildebrand
---
v1->v2:
* add in-code comments
* use variables more
---
scripts/uboot-script-gen | 17 -
1 file changed,
the header. Use the effective image size for calculating the
next load address and for populating the size in the /chosen/dom*/reg property.
Signed-off-by: Stewart Hildebrand
Reviewed-by: Michal Orzel
---
v2->v3:
* simplify awk parsing
* add R-b
v1->v2:
* add in-code comments
* use variable
on write to hardware, discarding the
guests write value.
The mask_cap_list flag will be set in a follow-on patch.
Signed-off-by: Stewart Hildebrand
---
v6->v7:
* re-work args passed to vpci_add_register_mask() (called in init_bars())
* also check for overlap of (rsvdz_mask &
possibly throwaway, to get an idea of what it would look
like to get rid of the (void *)(uintptr_t) cast by introducing a new memory
allocation
[1] https://lists.xenproject.org/archives/html/xen-devel/2023-08/msg02361.html
Stewart Hildebrand (2):
xen/vpci: header: status register ha
for RAZ registers, or
registers whose value doesn't change.
Introduce pci_find_next_cap_ttl() helper while adapting the logic from
pci_find_next_cap() to suit our needs, and implement the existing
pci_find_next_cap() in terms of the new helper.
Signed-off-by: Stewart Hildebrand
Reviewed-by: Jan
On 9/13/23 03:27, Michal Orzel wrote:
> Hi Stewart,
>
> On 12/09/2023 22:43, Stewart Hildebrand wrote:
>> There is a corner case where the filesizes of the xen and Linux kernel images
>> are not sufficient. These binaries likely contain NOLOAD sections (e.g. bss),
>&
On 9/6/23 04:22, Jan Beulich wrote:
> On 01.09.2023 06:57, Stewart Hildebrand wrote:
>> Introduce a handler for the PCI status register, with ability to mask the
>> capabilities bit. The status register contains reserved bits, read-only bits,
>> and write-1-to-clear bits,
Convert pci_find_*cap* functions and call sites to pci_sbdf_t, and remove some
now unused local variables. Also change to more appropriate types on lines that
are already being modified as a result of the pci_sbdf_t conversion.
Signed-off-by: Stewart Hildebrand
Reviewed-by: Jan Beulich
---
I
transient
dead code situation
* add new RFC patch, possibly throwaway, to get an idea of what it would look
like to get rid of the (void *)(uintptr_t) cast by introducing a new memory
allocation
[1] https://lists.xenproject.org/archives/html/xen-devel/2023-08/msg02361.html
Stewart Hildeb
on write to hardware, discarding the
guests write value.
The mask_cap_list flag will be set in a follow-on patch.
Signed-off-by: Stewart Hildebrand
---
v5->v6:
* remove duplicate PCI_STATUS_CAP_LIST in constant definition
* style fixup in constant definitions
* s/res_mask/rsvdz_mask/
* comb
for RAZ registers, or
registers whose value doesn't change.
Introduce pci_find_next_cap_ttl() helper while adapting the logic from
pci_find_next_cap() to suit our needs, and implement the existing
pci_find_next_cap() in terms of the new helper.
Signed-off-by: Stewart Hildebrand
Reviewed-by: Jan
1 - 100 of 460 matches
Mail list logo
