From: Oleksandr Andrushchenko
vpci_process_pending is defined with different attributes, e.g.
with __must_check if CONFIG_HAS_VPCI enabled and not otherwise.
Fix this by defining both of the definitions with __must_check.
Fixes: 14583a590783 ("7fbb096bf345 kconfig: don't select VPCI if bui
From: Oleksandr Andrushchenko
Add relevant vpci register handlers when assigning PCI device to a domain
and remove those when de-assigning. This allows having different
handlers for different domains, e.g. hwdom and other guests.
Emulate guest BAR register values: this allows creating a guest
From: Oleksandr Andrushchenko
When a PCI device gets assigned/de-assigned some work on vPCI side needs
to be done for that device. Introduce a pair of hooks so vPCI can handle
that.
Signed-off-by: Oleksandr Andrushchenko
---
Since v3:
- remove toolstack roll-back description from the commit
From: Oleksandr Andrushchenko
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
This is in preparation of making non-identity mappings in p2m for the
MMIOs/ROM.
Signed-off-by: Oleksandr Andrushchenko
---
Since v3:
- re
From: Oleksandr Andrushchenko
This is in preparation for dynamic assignment of the vpci register
handlers depending on the domain: hwdom or guest.
Signed-off-by: Oleksandr Andrushchenko
---
Since v3:
- remove all R-b's due to changes
- s/vpci_remove_device_registers/vpci_remove_device_handlers
From: Oleksandr Andrushchenko
When a vPCI is removed for a PCI device it is possible that we have
scheduled a delayed work for map/unmap operations for that device.
For example, the following scenario can illustrate the problem:
pci_physdev_op
pci_add_device
init_bars -> modify_b
From: Oleksandr Andrushchenko
Hi, all!
This patch series is focusing on vPCI and adds support for non-identity
PCI BAR mappings which is required while passing through a PCI device to
a guest. The highlights are:
- Add relevant vpci register handlers when assigning PCI device to a domain
From: Oleksandr Andrushchenko
vPCI may map and unmap PCI device memory (BARs) being passed through which
may take a lot of time. For this those operations may be deferred to be
performed later, so that they can be safely preempted.
Currently this deferred processing is happening in common IOREQ
From: Oleksandr Andrushchenko
PCI host bridges are special devices in terms of implementing PCI
passthrough. According to [1] the current implementation depends on
Domain-0 to perform the initialization of the relevant PCI host
bridge hardware and perform PCI device enumeration. In order
From: Oleksandr Andrushchenko
Currently Xen maps all IRQs and memory ranges for all devices except
those marked for passthrough, e.g. it doesn't pay attention to the
"status" property of the node.
According to the device tree specification [1]:
- "okay" Indicates the d
From: Oleksandr Andrushchenko
There is no reason to use void pointer while passing ECAM ops to the
pci_host_common_probe function as it is anyway casted to struct pci_ecam_ops
inside. For that reason remove the void pointer and pass struct pci_ecam_ops
pointer as is.
Signed-off-by: Oleksandr
From: Oleksandr Andrushchenko
Hi, all!
This is an assorted series of patches which aim is to make some further
basis for PCI passthrough on Arm support. The series continues the work
published earlier by Arm [1] and adds new helpers and clears the way for
vPCI changes which will follow.
RFC
From: Oleksandr Andrushchenko
To better reflect the nature of the device type and not to make any
confusion rename DEVICE_PCI to DEVICE_PCI_HOSTBRIDGE which it
really is.
Signed-off-by: Oleksandr Andrushchenko
Suggested-by: Julien Grall
---
New in v6
---
xen/arch/arm/pci/pci-host-generic.c
From: Oleksandr Andrushchenko
In order for vPCI to work it needs to maintain guest and hardware
domain's views of the configuration space. For example, BARs and
COMMAND registers require emulation for guests and the guest view
of the registers needs to be in sync with the real contents
From: Oleksandr Andrushchenko
If a PCI host bridge device is present in the device tree, but is
disabled, then its PCI host bridge driver was not instantiated.
This results in the failure of the pci_get_host_bridge_segment()
and the following panic during Xen start:
(XEN) Device tree generation
Hi, Julien!
On 03.11.21 20:17, Julien Grall wrote:
> Hi Oleksandr,
>
> On 03/11/2021 12:08, Oleksandr Andrushchenko wrote:
>>
>>
>> On 03.11.21 00:47, Stefano Stabellini wrote:
>>> On Tue, 2 Nov 2021, Oleksandr Andrushchenko wrote:
>>>> From: Oleks
On 03.11.21 00:47, Stefano Stabellini wrote:
> On Tue, 2 Nov 2021, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> While in vPCI MMIO trap handlers for the guest PCI host bridge it is not
>> enough for SBDF translation to simply call VPCI_ECAM_BD
On 03.11.21 13:26, Roger Pau Monné wrote:
> On Wed, Nov 03, 2021 at 11:02:37AM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 03.11.21 13:01, Roger Pau Monné wrote:
>>> On Wed, Nov 03, 2021 at 10:36:36AM +, Oleksandr Andrushchenko wrote:
>>>>
On 03.11.21 13:01, Roger Pau Monné wrote:
> On Wed, Nov 03, 2021 at 10:36:36AM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 03.11.21 12:34, Jan Beulich wrote:
>>> On 03.11.2021 11:24, Oleksandr Andrushchenko wrote:
>>>> On 03.11.21 11:49, Jan Beulich w
On 03.11.21 12:34, Jan Beulich wrote:
> On 03.11.2021 11:24, Oleksandr Andrushchenko wrote:
>> On 03.11.21 11:49, Jan Beulich wrote:
>>> Aiui you want to prevent the guest from clearing the bit if either
>>> MSI or MSI-X are in use. Symmetrically, when the guest en
On 03.11.21 11:49, Jan Beulich wrote:
> On 03.11.2021 10:30, Oleksandr Andrushchenko wrote:
>>
>> On 03.11.21 11:24, Jan Beulich wrote:
>>> On 03.11.2021 10:18, Oleksandr Andrushchenko wrote:
>>>> On 03.11.21 11:11, Jan Beulich wrote:
>>>>>
On 03.11.21 11:39, Roger Pau Monné wrote:
> On Wed, Nov 03, 2021 at 09:18:03AM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 03.11.21 11:11, Jan Beulich wrote:
>>> On 03.11.2021 09:53, Oleksandr Andrushchenko wrote:
>>>> On 02.11.21 16:10, Oleksandr Andrushc
On 03.11.21 11:24, Jan Beulich wrote:
> On 03.11.2021 10:18, Oleksandr Andrushchenko wrote:
>>
>> On 03.11.21 11:11, Jan Beulich wrote:
>>> On 03.11.2021 09:53, Oleksandr Andrushchenko wrote:
>>>> On 02.11.21 16:10, Oleksandr Andrushchenko wrote:
>&g
On 03.11.21 11:11, Jan Beulich wrote:
> On 03.11.2021 09:53, Oleksandr Andrushchenko wrote:
>>
>> On 02.11.21 16:10, Oleksandr Andrushchenko wrote:
>>> On 02.11.21 15:54, Jan Beulich wrote:
>>>> On 02.11.2021 12:50, Roger Pau Monné wrote:
>>>>
On 03.11.21 10:52, Roger Pau Monné wrote:
> On Wed, Nov 03, 2021 at 06:34:16AM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Roger
>>
>> On 26.10.21 14:33, Roger Pau Monné wrote:
>>> On Thu, Sep 30, 2021 at 10:52:22AM +0300, Oleksandr Andrushchenko wrote:
>>>
On 03.11.21 10:41, Jan Beulich wrote:
> On 03.11.2021 07:34, Oleksandr Andrushchenko wrote:
>> Hi, Roger
>>
>> On 26.10.21 14:33, Roger Pau Monné wrote:
>>> On Thu, Sep 30, 2021 at 10:52:22AM +0300, Oleksandr Andrushchenko wrote:
>>>> From: Olek
On 02.11.21 16:10, Oleksandr Andrushchenko wrote:
>
> On 02.11.21 15:54, Jan Beulich wrote:
>> On 02.11.2021 12:50, Roger Pau Monné wrote:
>>> On Tue, Nov 02, 2021 at 12:19:13PM +0100, Jan Beulich wrote:
>>>> On 26.10.2021 12:52, Roger Pau Monné wrote:
>>
Hi, Roger
On 26.10.21 14:33, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:22AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Assign SBDF to the PCI devices being passed through with bus 0.
>> The resulting topology is where PCI
On 02.11.21 15:54, Jan Beulich wrote:
> On 02.11.2021 12:50, Roger Pau Monné wrote:
>> On Tue, Nov 02, 2021 at 12:19:13PM +0100, Jan Beulich wrote:
>>> On 26.10.2021 12:52, Roger Pau Monné wrote:
>>>> On Thu, Sep 30, 2021 at 10:52:20AM +0300, Oleksandr Andrus
On 02.11.21 13:32, Jan Beulich wrote:
> On 25.10.2021 15:38, Oleksandr Andrushchenko wrote:
>> On 25.10.21 16:22, Roger Pau Monné wrote:
>>> On Fri, Oct 08, 2021 at 08:55:32AM +0300, Oleksandr Andrushchenko wrote:
>>>> --- a/tools/libs/light/libxl_pci.c
>>&
On 02.11.21 11:32, Julien Grall wrote:
> Hi Oleksandr,
>
> On 02/11/2021 07:16, Oleksandr Andrushchenko wrote:
>>
>>
>> On 01.11.21 23:06, Stefano Stabellini wrote:
>>> On Mon, 1 Nov 2021, Ian Jackson wrote:
>>>> Julien Grall writes ("Re: [PAT
From: Oleksandr Andrushchenko
While in vPCI MMIO trap handlers for the guest PCI host bridge it is not
enough for SBDF translation to simply call VPCI_ECAM_BDF(info->gpa) as
the base address may not be aligned in the way that the translation
always work. If not adjusted with respect to the b
Hi, Roger!
On 26.10.21 14:00, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:21AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Reset the command register when passing through a PCI device:
>> it is possible that when passing thro
Hi, Roger!
On 26.10.21 13:52, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:20AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add basic emulation support for guests. At the moment only emulate
>> PCI_COMMAND_INTX_DISABLE bit, t
Hi, Roger!
On 26.10.21 13:35, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:19AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Take into account guest's BAR view and program its p2m accordingly:
>> gfn is guest's view of the BAR
Hi, Roger!
On 26.10.21 12:08, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:18AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Instead of handling a single range set, that contains all the memory
>> regions of all the BARs
On 02.11.21 12:03, Roger Pau Monné wrote:
> On Mon, Nov 01, 2021 at 09:18:17AM +0000, Oleksandr Andrushchenko wrote:
>>>> +if ( rc )
>>>> +gdprintk(XENLOG_ERR,
>>>> + "%pp: failed to add BAR handlers for dom%pd
On 02.11.21 10:48, Roger Pau Monné wrote:
> On Mon, Nov 01, 2021 at 06:14:40AM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 29.10.21 10:33, Roger Pau Monné wrote:
>>> On Thu, Oct 28, 2021 at 05:55:25PM +, Oleksandr Andrushchenko wrote:
>>>> On 2
Hi,
On 02.11.21 09:37, Wei Chen wrote:
> Hi Oleksandr,
>
> On 2021/11/1 14:14, Oleksandr Andrushchenko wrote:
>>
>>
>> On 29.10.21 10:33, Roger Pau Monné wrote:
>>> On Thu, Oct 28, 2021 at 05:55:25PM +, Oleksandr Andrushchenko wrote:
>>>&g
On 01.11.21 23:06, Stefano Stabellini wrote:
> On Mon, 1 Nov 2021, Ian Jackson wrote:
>> Julien Grall writes ("Re: [PATCH] xen/arm: fix SBDF calculation for vPCI
>> MMIO handlers"):
>>> On 28/10/2021 16:54, Ian Jackson wrote:
There are a number of patches that I'm getting CC'd on related
>> +if ( rc )
>> +gdprintk(XENLOG_ERR,
>> + "%pp: failed to add BAR handlers for dom%pd: %d\n",
>> + >sbdf, d, rc);
>> +return rc;
>> +}
>> +
>> +int vpci_bar_remove_handlers(const struct domain *d, const struct pci_dev
>> *pdev)
>> +{
>> +/*
On 29.10.21 10:33, Roger Pau Monné wrote:
> On Thu, Oct 28, 2021 at 05:55:25PM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 28.10.21 19:03, Roger Pau Monné wrote:
>>> On Thu, Oct 28, 2021 at 02:23:34PM +, Oleksandr Andrushchenko wrote:
>>>> On 2
On 28.10.21 19:50, Stefano Stabellini wrote:
> On Thu, 28 Oct 2021, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 28/10/2021 00:57, Stefano Stabellini wrote:
>>> On Wed, 27 Oct 2021, Julien Grall wrote:
>>>> Hi Oleksandr,
>>>>
>>>&
On 28.10.21 18:35, Julien Grall wrote:
> Hi,
>
> On 28/10/2021 16:27, Oleksandr Andrushchenko wrote:
>> bridge as private and using info->gpa - GUEST_VPCI_ECAM_BASE...
>> So, I would stay with simpler
>>
>> if ( bridge )
>> {
>>
On 28.10.21 19:03, Roger Pau Monné wrote:
> On Thu, Oct 28, 2021 at 02:23:34PM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 28.10.21 16:36, Roger Pau Monné wrote:
>>> On Thu, Oct 28, 2021 at 12:09:23PM +, Oleksandr Andrushchenko wrote:
>>>> Hi, Julien!
On 28.10.21 17:28, Julien Grall wrote:
> Hi,
>
> On 28/10/2021 15:16, Oleksandr Andrushchenko wrote:
>> On 28.10.21 16:22, Julien Grall wrote:
>>> On 28/10/2021 13:09, Oleksandr Andrushchenko wrote:
>>>> Hi, Julien!
>>>
>>> Hello,
&g
nnot apply to helgaas-pci/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:https://github.com/0day-ci/linux/commits/Oleksandr-Andrushchenko/xen-pci
From: Oleksandr Andrushchenko
Xen-pciback driver was designed to be built for x86 only. But it
can also be used by other architectures, e.g. Arm.
Currently PCI backend implements multiple functionalities at a time,
such as:
1. It is used as a database for assignable PCI devices, e.g. xl
pci
On 28.10.21 16:36, Roger Pau Monné wrote:
> On Thu, Oct 28, 2021 at 12:09:23PM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>>
>> On 27.10.21 20:35, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 27/10/2021 09:25, Oleksandr Andrush
On 28.10.21 16:22, Julien Grall wrote:
> On 28/10/2021 13:09, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>
> Hello,
>
>> On 27.10.21 20:35, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 27/10/2021 09:25, Oleksandr Andrushchenko wrote:
Hi, Julien!
On 27.10.21 20:35, Julien Grall wrote:
> Hi Oleksandr,
>
> On 27/10/2021 09:25, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> While in vPCI MMIO trap handlers for the guest PCI host bridge it is not
>> enough for SBDF transla
Hi, Julien!
On 28.10.21 14:13, Julien Grall wrote:
>
>
> On 25/10/2021 12:37, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>
> Hi Oleksandr,
>
>> On 13.10.21 19:17, Julien Grall wrote:
>>> On 08/10/2021 06:55, Oleksandr Andrushchenko wrote:
>>>>
On 28.10.21 14:03, Julien Grall wrote:
>
>
> On 28/10/2021 12:01, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>>
>> [snip]
>> On 28.10.21 13:48, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> Looking at linux/arch/arm64/boot/dts/, there
Hi, Julien!
[snip]
On 28.10.21 13:48, Julien Grall wrote:
> Hi Stefano,
>
> Looking at linux/arch/arm64/boot/dts/, there are a few Device-Tree that
> contain the property "linux,pci-domain". All of them seems to also add it for
> disabled hostbridges.
>
> However, I am under the impression that
On 28.10.21 13:30, Roger Pau Monné wrote:
> On Thu, Oct 28, 2021 at 10:25:28AM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 28.10.21 13:17, Roger Pau Monné wrote:
>>> On Thu, Oct 28, 2021 at 10:04:20AM +, Oleksandr Andrushchenko wrote:
>>>> Hi,
On 28.10.21 13:17, Roger Pau Monné wrote:
> On Thu, Oct 28, 2021 at 10:04:20AM +0000, Oleksandr Andrushchenko wrote:
>> Hi, all!
>>
>> While working on PCI passthrough on Arm I stepped onto a crash
>> with the following call chain:
>>
>> pci_physdev_op
>
Hi, all!
While working on PCI passthrough on Arm I stepped onto a crash
with the following call chain:
pci_physdev_op
pci_add_device
init_bars -> modify_bars -> defer_map -> raise_softirq(SCHEDULE_SOFTIRQ)
iommu_add_device <- FAILS
vpci_remove_device -> xfree(pdev->vpci)
Then:
From: Oleksandr Andrushchenko
Xen-pciback driver was designed to be built for x86 only. But it
can also be used by other architectures, e.g. Arm.
Currently PCI backend implements multiple functionalities at a time,
such as:
1. It is used as a database for assignable PCI devices, e.g. xl
pci
On 27.10.21 17:46, Boris Ostrovsky wrote:
>
> On 10/27/21 10:08 AM, Oleksandr Andrushchenko wrote:
>> Hi, Boris!
>>
>> On 27.10.21 15:59, Boris Ostrovsky wrote:
>>>
>>> Can you please rebase this on top of 5.15-r
Hi, Boris!
On 27.10.21 15:59, Boris Ostrovsky wrote:
>
> On 9/28/21 3:35 AM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Xen-pciback driver was designed to be built for x86 only. But it
>> can also be used by other architectures, e.g. Ar
On 27.10.21 16:23, Roger Pau Monné wrote:
> On Wed, Oct 27, 2021 at 11:59:47AM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 27.10.21 13:17, Oleksandr Andrushchenko wrote:
>>> Hi, Roger!
>>>
>>> On 13.10.21 16:51, Roger Pau Monn
Hi, Roger!
On 27.10.21 13:17, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 13.10.21 16:51, Roger Pau Monné wrote:
>> On Thu, Sep 30, 2021 at 10:52:15AM +0300, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> This is in prep
Hi, Roger!
On 13.10.21 16:51, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:15AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> This is in preparation for dynamic assignment of the vPCI register
>> handlers depending on
Hi, Roger!
On 13.10.21 14:29, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:14AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When a PCI device gets assigned/de-assigned some work on vPCI side needs
>> to be done for that device
On 27.10.21 12:23, Roger Pau Monné wrote:
> On Wed, Oct 27, 2021 at 09:04:39AM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 27.10.21 11:59, Roger Pau Monné wrote:
>>> On Wed, Oct 27, 2021 at 11:25:33AM +0300, Oleksandr Andrushchenko wrote:
>
On 27.10.21 12:24, Roger Pau Monné wrote:
> On Wed, Oct 27, 2021 at 09:12:14AM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 13.10.21 14:11, Roger Pau Monné wrote:
>>> On Thu, Sep 30, 2021 at 10:52:13AM +0300, Oleksandr Andrushchenko wrote:
>
Hi, Roger!
On 13.10.21 14:11, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:13AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> This is in preparation for dynamic assignment of the vpci register
>> handlers depending on
Hi, Roger!
On 27.10.21 11:59, Roger Pau Monné wrote:
> On Wed, Oct 27, 2021 at 11:25:33AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> While in vPCI MMIO trap handlers for the guest PCI host bridge it is not
>> enough for SBDF
From: Oleksandr Andrushchenko
If a PCI host bridge device is present in the device tree, but is
disabled, then its PCI host bridge driver was not instantiated.
This results in the following panic during Xen start:
(XEN) Device tree generation failed (-22).
(XEN)
(XEN
From: Oleksandr Andrushchenko
While in vPCI MMIO trap handlers for the guest PCI host bridge it is not
enough for SBDF translation to simply call VPCI_ECAM_BDF(info->gpa) as
the base address may not be aligned in the way that the translation
always work. If not adjusted with respect to the b
Hi, Roger!
On 26.10.21 16:30, Roger Pau Monné wrote:
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index fa6fcc5e467c..095671742ad8 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -797,6 +797,7 @@ void arch_domain_destroy(struct domain *d)
>>
On 26.10.21 10:50, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:17AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Emulate guest BAR register values: this allows creating a guest view
>> of the registers and emulate
On 25.10.21 16:40, Roger Pau Monné wrote:
> On Mon, Oct 25, 2021 at 09:38:00AM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 13.10.21 13:11, Roger Pau Monné wrote:
>>> On Fri, Oct 08, 2021 at 08:55:33AM +0300, Oleksandr Andrushchenko wrote:
>
Hi, Roger!
On 25.10.21 16:22, Roger Pau Monné wrote:
> On Fri, Oct 08, 2021 at 08:55:32AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Arm's PCI passthrough implementation doesn't support legacy interrupts,
>> but MSI/MSI-X. Thi
Hi, Roger!
On 25.10.21 16:14, Roger Pau Monné wrote:
> On Fri, Oct 08, 2021 at 08:55:31AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> The PCI device remove path may now be used by PVH on ARM, so the
>> assert is no longer valid.
> I
Hi, Roger!
Could you please take a look at the below?
Jan was questioning the per BAR range set approach, so it
is crucial for the maintainer (you) to answer here.
Thank you in advance,
Oleksandr
On 30.09.21 10:52, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
>
Hi, Julien!
On 13.10.21 19:17, Julien Grall wrote:
> Hi Oleksandr,
>
> On 08/10/2021 06:55, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> PCI host bridges are special devices in terms of implementing PCI
>> passthrough. According to [1] t
Hi, Julien!
On 13.10.21 18:30, Julien Grall wrote:
> Hi Oleksandr,
>
> On 08/10/2021 06:55, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> vPCI may map and unmap PCI device memory (BARs) being passed through which
>> may take a lot of ti
Hi, Roger!
On 13.10.21 13:11, Roger Pau Monné wrote:
> On Fri, Oct 08, 2021 at 08:55:33AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> In order for vPCI to work it needs to maintain guest and hardware
>> domain's views of the configurati
Hi, Juergen!
On 22.10.21 09:48, Juergen Gross wrote:
> The Xen pv sound driver is not essential for booting. Set the respective
> flag.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
> ---
> sound/xen/xen_snd_front.c | 1 +
> 1 file changed, 1
Hi, Juergen!
On 22.10.21 09:47, Juergen Gross wrote:
> Similar to the virtual frame buffer (vfb) the pv display driver is not
> essential for booting the system. Set the respective flag.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
> ---
> d
On 18.10.21 17:19, Jan Beulich wrote:
> On 18.10.2021 16:07, Oleksandr Andrushchenko wrote:
>> On 18.10.21 13:29, Jan Beulich wrote:
>>> On 18.10.2021 12:11, Bertrand Marquis wrote:
>>>>> On 18 Oct 2021, at 08:47, Jan Beulich wrote:
>>>>
On 18.10.21 13:29, Jan Beulich wrote:
> On 18.10.2021 12:11, Bertrand Marquis wrote:
>>> On 18 Oct 2021, at 08:47, Jan Beulich wrote:
>>> On 15.10.2021 18:51, Bertrand Marquis wrote:
--- /dev/null
+++ b/xen/arch/arm/vpci.c
@@ -0,0 +1,77 @@
+/*
+ * xen/arch/arm/vpci.c
Hi, Jan!
On 18.10.21 10:47, Jan Beulich wrote:
> On 15.10.2021 18:51, Bertrand Marquis wrote:
>> --- /dev/null
>> +++ b/xen/arch/arm/vpci.c
>> @@ -0,0 +1,77 @@
>> +/*
>> + * xen/arch/arm/vpci.c
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the
On 13.10.21 16:00, Jan Beulich wrote:
> On 13.10.2021 10:45, Roger Pau Monné wrote:
>> On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
>>> The existing VPCI support available for X86 is adapted for Arm.
>>> When the device is added to XEN via the hyper call
>>>
On 12.10.21 13:01, Jan Beulich wrote:
> On 12.10.2021 11:38, Oleksandr Andrushchenko wrote:
>> On 12.10.21 12:32, Jan Beulich wrote:
>>> On 12.10.2021 10:41, Bertrand Marquis wrote:
>>>>> On 12 Oct 2021, at 09:29, Jan Beulich wrote:
>>>>
On 12.10.21 12:32, Jan Beulich wrote:
> On 12.10.2021 10:41, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 12 Oct 2021, at 09:29, Jan Beulich wrote:
>>>
>>> On 11.10.2021 19:11, Bertrand Marquis wrote:
> On 11 Oct 2021, at 17:32, Roger Pau Monné wrote:
> On Mon, Oct 11, 2021 at
On 11.10.21 22:27, Stefano Stabellini wrote:
> On Mon, 11 Oct 2021, Oleksandr Andrushchenko wrote:
>> On 11.10.21 20:15, Bertrand Marquis wrote:
>>> Hi Roger,
>>>
>>>> On 11 Oct 2021, at 17:43, Roger Pau Monné wrote:
>>>>
>>>> On
On 11.10.21 20:15, Bertrand Marquis wrote:
> Hi Roger,
>
>> On 11 Oct 2021, at 17:43, Roger Pau Monné wrote:
>>
>> On Mon, Oct 11, 2021 at 04:20:14PM +, Oleksandr Andrushchenko wrote:
>>>
>>> On 11.10.21 19:12, Bertrand Marquis wrote:
>>
On 11.10.21 19:12, Bertrand Marquis wrote:
> Hi Roger,
>
>> On 11 Oct 2021, at 11:51, Roger Pau Monné wrote:
>>
>> On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
>>> The existing VPCI support available for X86 is adapted for Arm.
>>> When the device is added to XEN via the hyper
Hi, Anthony!
On 11.10.21 19:11, Anthony PERARD wrote:
> On Fri, Oct 08, 2021 at 08:55:31AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> The PCI device remove path may now be used by PVH on ARM, so the
>> assert is no longer vali
Hi, all
On 11.10.21 16:40, Bertrand Marquis wrote:
> Hi Roger,
>
> + Oleksandr to have a better PCI expert then me.
>
>> On 11 Oct 2021, at 14:20, Roger Pau Monné wrote:
>>
>> On Mon, Oct 11, 2021 at 12:11:04PM +, Bertrand Marquis wrote:
>>> Hi Roger,
>>>
On 11 Oct 2021, at 12:47, Roger
From: Oleksandr Andrushchenko
vPCI may map and unmap PCI device memory (BARs) being passed through which
may take a lot of time. For this those operations may be deferred to be
performed later, so that they can be safely preempted.
Currently this deferred processing is happening in common IOREQ
From: Oleksandr Andrushchenko
PCI host bridges are special devices in terms of implementing PCI
passthrough. According to [1] the current implementation depends on
Domain-0 to perform the initialization of the relevant PCI host
bridge hardware and perform PCI device enumeration. In order
From: Oleksandr Andrushchenko
In order for vPCI to work it needs to maintain guest and hardware
domain's views of the configuration space. For example, BARs and
COMMAND registers require emulation for guests and the guest view
of the registers needs to be in sync with the real contents
From: Oleksandr Andrushchenko
Arm's PCI passthrough implementation doesn't support legacy interrupts,
but MSI/MSI-X. This can be the case for other platforms too.
For that reason introduce a new CONFIG_PCI_SUPP_LEGACY_IRQ and add
it to the CFLAGS and compile the relevant code in the toolstack
From: Oleksandr Andrushchenko
The PCI device remove path may now be used by PVH on ARM, so the
assert is no longer valid.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Stefano Stabellini
Reviewed-by: Rahul Singh
Tested-by: Rahul Singh
---
Cc: Ian Jackson
Cc: Juergen Gross
---
tools
From: Oleksandr Tyshchenko
This is the very same that we already do for DT devices. Moreover, x86
already calls pci_release_devices().
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Stefano Stabellini
Reviewed-by: Rahul Singh
Tested-by: Rahul Singh
From: Oleksandr Andrushchenko
While adding a PCI device mark it as such, so other frameworks
can distinguish it from DT devices.
For that introduce an architecture defined helper which may perform
additional initialization of the newly created PCI device.
Signed-off-by: Oleksandr Andrushchenko
From: Oleksandr Andrushchenko
Make dt_find_node_by_phandle globally visible, so it can be re-used by
other frameworks.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Stefano Stabellini
Reviewed-by: Rahul Singh
Tested-by: Rahul Singh
---
xen/common/device_tree.c | 2 +-
xen
301 - 400 of 1401 matches
Mail list logo
