From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs
From: Oleksandr Andrushchenko
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
MSI-X registers we need to explicitly tell that we have additional IO
handlers, so those are accounted.
Signed-off
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus
From: Oleksandr Andrushchenko
Reset the command register when passing through a PCI device:
it is possible that when passing through a PCI device its memory
decoding bits in the command register are already set. Thus, a
guest OS may not write to the command register to update memory
decoding, so
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value as set
up by the PCI bus driver in the hardware domain.
This way hardware domain sees physical BAR values and guest sees
emulated
From: Oleksandr Andrushchenko
Add basic emulation support for guests. At the moment only emulate
PCI_COMMAND_INTX_DISABLE bit, the rest is not emulated yet and left
as TODO.
Signed-off-by: Oleksandr Andrushchenko
---
Since v3:
- gate more code on CONFIG_HAS_MSI
- removed logic for the case
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
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
As the range sets are now created when a PCI device is added and destroyed
when it is removed so make them named and accounted.
Note
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 v4:
- de-assign vPCI from the previous domain on device
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
was dropped prior to freeing pdev->vpci.
Signed-off-by: Roger Pau Monné
Signed-off-by: Oleksandr Andrushchenko
---
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
---
New in v5 of this series: this is an updated version of the patch published at
ht
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
There are range sets which should not be printed, so introduce a flag
which allows marking those as such. Implement relevant logic to skip
such entries while printing.
While at it also simplify the definition of the flags by directly
defining those without helpers
From: Oleksandr Andrushchenko
Hi, all!
1. 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
On 24.11.21 14:36, Roger Pau Monné wrote:
> On Wed, Nov 24, 2021 at 11:28:18AM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Jan!
>>
>> On 18.11.21 18:45, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>>> --- a/xen/include/xe
On 24.11.21 14:32, Roger Pau Monné wrote:
> On Tue, Nov 23, 2021 at 03:14:27PM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 19.11.21 15:02, Jan Beulich wrote:
>>> On 19.11.2021 13:54, Oleksandr Andrushchenko wrote:
>>>> On 19.11.21 14:49,
On 08.11.21 17:28, Oleksandr Andrushchenko wrote:
>
> On 08.11.21 16:23, Roger Pau Monné wrote:
>> On Mon, Nov 08, 2021 at 11:16:42AM +0000, Oleksandr Andrushchenko wrote:
>>> On 08.11.21 13:10, Jan Beulich wrote:
>>>> On 05.11.2021 07:56, Oleksandr Andrushchenk
Hi, Jan!
On 18.11.21 18:45, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> Since v3:
>> - make use of VPCI_INIT
>> - moved all new code to vpci.c which belongs to it
>> - changed open-coded 31 to PCI_SLOT(~0)
>> - revisited l
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
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
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding an IO trap handler for the emulated
PCI host bridge we are not breaking anything, but we have a latent bug
as the maximum number of IOs may be exceeded.
Fix
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.
Suggested-by: Julien Grall
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Julien Grall
---
New in v6
---
xen/arch
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
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 23.11.21 18:42, Julien Grall wrote:
> Hi Oleksandr,
>
> On 05/11/2021 06:33, 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 23.11.21 18:58, Julien Grall wrote:
> Hi,
>
> On 23/11/2021 16:41, Oleksandr Andrushchenko wrote:
>> On 23.11.21 18:12, Julien Grall wrote:
>>> On 23/11/2021 06:58, Oleksandr Andrushchenko wrote:
>>>> unsigned int domain_vpci_ge
Hi, Julien!
On 23.11.21 19:15, Julien Grall wrote:
> Hi,
>
> On 23/11/2021 16:44, Oleksandr Andrushchenko wrote:
>> On 23.11.21 18:05, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 23/11/2021 06:31, Oleksandr Andrushchenko wrote:
>>>>
>
Hi, Julien!
On 23.11.21 18:05, Julien Grall wrote:
> Hi Oleksandr,
>
> On 23/11/2021 06:31, Oleksandr Andrushchenko wrote:
>>
>>
>> On 22.11.21 19:17, Julien Grall wrote:
>>> Hi,
>>>
>>> On 22/11/2021 16:23, Oleksandr Andrushchenko wrote:
>
Hi, Julien!
On 23.11.21 18:12, Julien Grall wrote:
>
>
> On 23/11/2021 06:58, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>
> Hi Oleksandr,
>
>> On 22.11.21 19:36, Julien Grall wrote:
>>> On 18/11/2021 10:46, Oleksandr Andrushchenko wrote:
>>>&g
Hi, Roger!
On 19.11.21 15:02, Jan Beulich wrote:
> On 19.11.2021 13:54, Oleksandr Andrushchenko wrote:
>> On 19.11.21 14:49, Jan Beulich wrote:
>>> On 19.11.2021 13:46, Oleksandr Andrushchenko wrote:
>>>> On 19.11.21 14:37, Jan Beulich wrote:
>>>>>
Hi, Roger, Jan!
I think the below work will help with solving issues brought up by [1].
So, after thinking a bit more I concluded that indeed we do not actually
need a per-domain vPCI lock, but instead we just want to protect pdev->vpci
which is done in this patch.
At the moment I see four
On 23.11.21 10:01, Jan Beulich wrote:
> On 23.11.2021 08:49, Oleksandr Andrushchenko wrote:
>>
>> On 23.11.21 09:38, Jan Beulich wrote:
>>> On 22.11.2021 10:28, Oleksandr Andrushchenko wrote:
>>>> --- a/xen/include/xen/rangeset.h
>>>> +++ b/xen/in
On 23.11.21 09:38, Jan Beulich wrote:
> On 22.11.2021 10:28, Oleksandr Andrushchenko wrote:
>> --- a/xen/include/xen/rangeset.h
>> +++ b/xen/include/xen/rangeset.h
>> @@ -51,6 +51,9 @@ void rangeset_limit(
>>/* Pretty-print range limits in h
Hi, Julien!
On 22.11.21 21:31, Julien Grall wrote:
> Hi Oleksandr,
>
> On 18/11/2021 06:59, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>>
>> On 16.11.21 21:22, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 05/11/2021 06:33, Oleksandr A
Hi, Julien!
On 22.11.21 19:36, Julien Grall wrote:
> Hi,
>
> On 18/11/2021 10:46, Oleksandr Andrushchenko wrote:
>> On 18.11.21 09:27, Oleksandr Andrushchenko wrote:
>>> Hi, Julien!
>>>
>>> On 16.11.21 21:12, Julien Grall wrote:
>>>>
On 22.11.21 19:17, Julien Grall wrote:
> Hi,
>
> On 22/11/2021 16:23, Oleksandr Andrushchenko wrote:
>> On 22.11.21 17:29, Julien Grall wrote:
>>> I would prefer to go with my way. This can be refined in the future if we
>>> find Device-Tree that matches what
On 22.11.21 17:29, Julien Grall wrote:
>
>
> On 18/11/2021 07:13, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>
> Hi Oleksandr,
>
>> On 17.11.21 23:33, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 17/11/2021 06:56, Oleksandr Andrushc
On 22.11.21 16:57, Jan Beulich wrote:
> On 22.11.2021 15:45, Oleksandr Andrushchenko wrote:
>>
>> On 22.11.21 16:37, Jan Beulich wrote:
>>> On 22.11.2021 15:21, Oleksandr Andrushchenko wrote:
>>>> On 19.11.21 15:34, Oleksandr Andrushchenko wrote:
>&g
On 22.11.21 16:37, Jan Beulich wrote:
> On 22.11.2021 15:21, Oleksandr Andrushchenko wrote:
>> On 19.11.21 15:34, Oleksandr Andrushchenko wrote:
>>> On 19.11.21 15:25, Jan Beulich wrote:
>>>> On 19.11.2021 14:16, Oleksandr Andrushchenko wrote:
>>>
On 19.11.21 15:34, Oleksandr Andrushchenko wrote:
>
> On 19.11.21 15:25, Jan Beulich wrote:
>> On 19.11.2021 14:16, Oleksandr Andrushchenko wrote:
>>> On 19.11.21 15:00, Jan Beulich wrote:
>>>> On 19.11.2021 13:34, Oleksandr Andrushchenko wrote:
>>>
On 22.11.21 11:28, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> There are range sets which should not be printed, so introduce a flag
> which allows marking those as such. Implement relevant logic to skip
> such entries while printing.
>
> Sugg
On 22.11.21 13:08, Jan Beulich wrote:
> On 22.11.2021 11:59, Oleksandr Andrushchenko wrote:
>> On 22.11.21 12:54, Jan Beulich wrote:
>>> On 22.11.2021 11:50, Oleksandr Andrushchenko wrote:
>>>> On 22.11.21 12:43, Jan Beulich wrote:
>>>>> On 22.11.202
On 22.11.21 12:54, Jan Beulich wrote:
> On 22.11.2021 11:50, Oleksandr Andrushchenko wrote:
>>
>> On 22.11.21 12:43, Jan Beulich wrote:
>>> On 22.11.2021 11:27, Roger Pau Monné wrote:
>>>> On Mon, Nov 22, 2021 at 11:28:25AM +0200, Oleksandr Andrushchenko
On 22.11.21 12:43, Jan Beulich wrote:
> On 22.11.2021 11:27, Roger Pau Monné wrote:
>> On Mon, Nov 22, 2021 at 11:28:25AM +0200, Oleksandr Andrushchenko wrote:
>>> --- a/xen/drivers/vpci/header.c
>>> +++ b/xen/drivers/vpci/header.c
>>> @@ -206,12 +206,16 @@ st
From: Oleksandr Andrushchenko
There are range sets which should not be printed, so introduce a flag
which allows marking those as such. Implement relevant logic to skip
such entries while printing.
Suggested-by: Jan Beulich
Signed-off-by: Oleksandr Andrushchenko
---
xen/common/rangeset.c
From: Oleksandr Andrushchenko
Use a named range set instead of an anonymous one, but do not print it
while dumping range sets for a domain.
Suggested-by: Jan Beulich
Signed-off-by: Oleksandr Andrushchenko
---
xen/drivers/vpci/header.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion
On 22.11.21 10:22, Jan Beulich wrote:
> On 19.11.2021 15:23, Roger Pau Monné wrote:
>> On Fri, Nov 19, 2021 at 02:56:12PM +0100, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>>>>
On 22.11.21 10:24, Jan Beulich wrote:
> On 19.11.2021 15:09, Oleksandr Andrushchenko wrote:
>> On 19.11.21 15:57, Jan Beulich wrote:
>>> On 19.11.2021 14:41, Oleksandr Andrushchenko wrote:
>>>> On 19.11.21 15:16, Jan Beulich wrote:
>>>>> On 05
On 19.11.21 16:23, Roger Pau Monné wrote:
> On Fri, Nov 19, 2021 at 02:56:12PM +0100, Jan Beulich wrote:
>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Hi, all!
>>>
>>> This patch series
On 19.11.21 15:57, Jan Beulich wrote:
> On 19.11.2021 14:41, Oleksandr Andrushchenko wrote:
>>
>> On 19.11.21 15:16, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>>> @@ -95,10 +102,25 @@ int vpci_add_handlers(struct pci_dev *pd
On 19.11.21 15:56, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Hi, all!
>>
>> This patch series is focusing on vPCI and adds support for non-identity
>> PCI BAR mappings which is requ
On 19.11.21 15:16, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> @@ -95,10 +102,25 @@ int vpci_add_handlers(struct pci_dev *pdev)
>> INIT_LIST_HEAD(>vpci->handlers);
>> spin_lock_init(>vpci->lock);
>>
>>
On 19.11.21 15:29, Jan Beulich wrote:
> On 19.11.2021 14:19, Oleksandr Andrushchenko wrote:
>>
>> On 19.11.21 15:06, Jan Beulich wrote:
>>> On 19.11.2021 13:50, Oleksandr Andrushchenko wrote:
>>>> On 19.11.21 14:45, Jan Beulich wrote:
>>>>>
On 19.11.21 15:25, Jan Beulich wrote:
> On 19.11.2021 14:16, Oleksandr Andrushchenko wrote:
>> On 19.11.21 15:00, Jan Beulich wrote:
>>> On 19.11.2021 13:34, Oleksandr Andrushchenko wrote:
>>>> Possible locking and other work needed:
>>>> =
On 19.11.21 15:06, Jan Beulich wrote:
> On 19.11.2021 13:50, Oleksandr Andrushchenko wrote:
>> On 19.11.21 14:45, Jan Beulich wrote:
>>> On 19.11.2021 13:13, Oleksandr Andrushchenko wrote:
>>>> On 19.11.21 14:05, Jan Beulich wrote:
>>>>> On 05
On 19.11.21 15:00, Jan Beulich wrote:
> On 19.11.2021 13:34, Oleksandr Andrushchenko wrote:
>> Possible locking and other work needed:
>> ===
>>
>> 1. pcidevs_{lock|unlock} is too heavy and is per-host
>> 2. pdev->vpci-&
On 19.11.21 15:02, Jan Beulich wrote:
> On 19.11.2021 13:54, Oleksandr Andrushchenko wrote:
>> On 19.11.21 14:49, Jan Beulich wrote:
>>> On 19.11.2021 13:46, Oleksandr Andrushchenko wrote:
>>>> On 19.11.21 14:37, Jan Beulich wrote:
>>>>> On 19
On 19.11.21 14:49, Jan Beulich wrote:
> On 19.11.2021 13:46, Oleksandr Andrushchenko wrote:
>> On 19.11.21 14:37, Jan Beulich wrote:
>>> On 19.11.2021 13:10, Oleksandr Andrushchenko wrote:
>>>> On 19.11.21 13:58, Jan Beulich wrote:
>>>>> On 05
On 19.11.21 14:45, Jan Beulich wrote:
> On 19.11.2021 13:13, Oleksandr Andrushchenko wrote:
>> On 19.11.21 14:05, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>>>>
>>>> Ins
On 19.11.21 14:37, Jan Beulich wrote:
> On 19.11.2021 13:10, Oleksandr Andrushchenko wrote:
>> On 19.11.21 13:58, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>>>>
>>>> Add rel
On 19.11.21 14:33, Jan Beulich wrote:
> On 05.11.2021 07:56, 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 and mfn is the physical BAR val
Hi, Roger, Jan!
On 18.11.21 17:53, Jan Beulich wrote:
> On 18.11.2021 16:46, Oleksandr Andrushchenko wrote:
>> On 18.11.21 17:41, Jan Beulich wrote:
>>> On 18.11.2021 16:21, Oleksandr Andrushchenko wrote:
>>>> On 18.11.21 17:16, Jan Beulich wrote:
>>>>
On 19.11.21 14:05, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> 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.
> Iir
On 19.11.21 13:58, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add relevant vpci register handlers when assigning PCI device to a domain
>> and remove those when de-assigning. This allows h
On 18.11.21 17:41, Jan Beulich wrote:
> On 18.11.2021 16:21, Oleksandr Andrushchenko wrote:
>> On 18.11.21 17:16, Jan Beulich wrote:
>>> On 18.11.2021 16:11, Oleksandr Andrushchenko wrote:
>>>> On 18.11.21 16:35, Jan Beulich wrote:
>>>>> On 18
On 18.11.21 17:16, Jan Beulich wrote:
> On 18.11.2021 16:11, Oleksandr Andrushchenko wrote:
>>
>> On 18.11.21 16:35, Jan Beulich wrote:
>>> On 18.11.2021 15:14, Oleksandr Andrushchenko wrote:
>>>> On 18.11.21 16:04, Roger Pau Monné wrote:
>>>>&g
On 18.11.21 16:35, Jan Beulich wrote:
> On 18.11.2021 15:14, Oleksandr Andrushchenko wrote:
>> On 18.11.21 16:04, Roger Pau Monné wrote:
>>> Indeed. In the physdevop failure case this comes from an hypercall
>>> context, so maybe you could do the mappi
On 18.11.21 16:04, Roger Pau Monné wrote:
> Sorry, I've been quite busy with other staff.
>
> On Thu, Nov 18, 2021 at 01:48:06PM +, Oleksandr Andrushchenko wrote:
>>
>> On 18.11.21 15:25, Jan Beulich wrote:
>>> On 18.11.2021 10:32, Oleksandr Andrushchenko wrot
On 18.11.21 15:25, Jan Beulich wrote:
> On 18.11.2021 10:32, Oleksandr Andrushchenko wrote:
>>
>> On 18.11.21 11:15, Jan Beulich wrote:
>>> On 18.11.2021 09:54, Oleksandr Andrushchenko wrote:
>>>> On 18.11.21 10:36, Jan Beulich wrote:
>>>>>
Hi, Julien!
On 16.11.21 20:02, Julien Grall wrote:
> Hi Oleksandr,
>
> On 16/11/2021 14:24, Oleksandr Andrushchenko wrote:
>>
>>
>> On 16.11.21 16:12, Jan Beulich wrote:
>>> On 16.11.2021 14:41, Oleksandr Andrushchenko wrote:
>>>>
>&
On 18.11.21 09:27, Oleksandr Andrushchenko wrote:
> Hi, Julien!
>
> On 16.11.21 21:12, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> In order fo
On 18.11.21 11:15, Jan Beulich wrote:
> On 18.11.2021 09:54, Oleksandr Andrushchenko wrote:
>> On 18.11.21 10:36, Jan Beulich wrote:
>>> On 18.11.2021 08:49, Oleksandr Andrushchenko wrote:
>>>> On 17.11.21 10:28, Jan Beulich wrote:
>>>>> On 05
On 18.11.21 10:36, Jan Beulich wrote:
> On 18.11.2021 08:49, Oleksandr Andrushchenko wrote:
>>
>> On 17.11.21 10:28, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>>>>
>>>
On 17.11.21 10:28, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> 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
Hi, Julien!
On 17.11.21 23:45, Julien Grall wrote:
> Hi Oleksandr,
>
> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> There is no reason to use void pointer while passing ECAM ops to the
>> pci_host_common_prob
Hi, Julien!
On 16.11.21 21:12, Julien Grall wrote:
> Hi Oleksandr,
>
> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> In order for vPCI to work it needs to maintain guest and hardware
>> domain's views of the confi
Hi, Julien!
On 17.11.21 23:33, Julien Grall wrote:
> Hi Oleksandr,
>
> On 17/11/2021 06:56, Oleksandr Andrushchenko wrote:
>> Hi, Julien!
>>
>> On 16.11.21 20:48, Julien Grall wrote:
>>> Hi Oleksander,
>>>
>>> On 05/11/2021 06:33, Oleksandr A
Hi, Julien!
On 16.11.21 21:22, Julien Grall wrote:
> Hi Oleksandr,
>
> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Currently Xen maps all IRQs and memory ranges for all devices except
>> those marked for passthrou
Hi, Julien!
On 16.11.21 20:48, Julien Grall wrote:
> Hi Oleksander,
>
> On 05/11/2021 06:33, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> If a PCI host bridge device is present in the device tree, but is
>> disabled, then its PCI host b
On 16.11.21 16:24, Oleksandr Andrushchenko wrote:
>
> On 16.11.21 16:12, Jan Beulich wrote:
>> On 16.11.2021 14:41, Oleksandr Andrushchenko wrote:
>>> On 16.11.21 10:23, Oleksandr Andrushchenko wrote:
>>>> On 16.11.21 10:01, Jan Beulich wrote:
>>>>&
On 16.11.21 16:12, Jan Beulich wrote:
> On 16.11.2021 14:41, Oleksandr Andrushchenko wrote:
>>
>> On 16.11.21 10:23, Oleksandr Andrushchenko wrote:
>>> On 16.11.21 10:01, Jan Beulich wrote:
>>>> On 16.11.2021 08:32, Oleksandr Andrushchenko wrote:
>&g
On 16.11.21 10:23, Oleksandr Andrushchenko wrote:
>
> On 16.11.21 10:01, Jan Beulich wrote:
>> On 16.11.2021 08:32, Oleksandr Andrushchenko wrote:
>>> On 15.11.21 18:56, Jan Beulich wrote:
>>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
&g
On 16.11.21 13:38, Jan Beulich wrote:
> On 16.11.2021 09:23, Oleksandr Andrushchenko wrote:
>>
>> On 16.11.21 10:01, Jan Beulich wrote:
>>> On 16.11.2021 08:32, Oleksandr Andrushchenko wrote:
>>>> On 15.11.21 18:56, Jan Beulich wrote:
>>>>>
Hi, Geert!
On 16.11.21 11:36, Geert Uytterhoeven wrote:
> Hi Oleksandr,
>
> On Thu, Oct 28, 2021 at 8:15 AM Oleksandr Andrushchenko
> wrote:
>> From: Oleksandr Andrushchenko
>>
>> Xen-pciback driver was designed to be built for x86 only. But it
>> can also
On 15.11.21 19:06, Jan Beulich wrote:
> On 05.11.2021 07:56, 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. Introduce a pair
On 16.11.21 10:01, Jan Beulich wrote:
> On 16.11.2021 08:32, Oleksandr Andrushchenko wrote:
>> On 15.11.21 18:56, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>>>>
>>>>
On 15.11.21 18:57, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> This is in preparation for dynamic assignment of the vpci register
>> handlers depending on the domain: hwdom or guest.
>>
>>
On 15.11.21 18:56, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> 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
Hi, Bernard!
On 15.11.21 05:45, Bernard Zhao wrote:
> In function xen_drm_front_gem_import_sg_table, if in error branch,
> there maybe potential memleak if not call gem_free_pages_array.
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 8 ++--
> 1 file
On 05.11.21 08:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> [snip]
> +int pci_host_iterate_bridges(struct domain *d,
> + int (*cb)(struct domain *d,
> + struct pci_h
On 08.11.21 16:23, Roger Pau Monné wrote:
> On Mon, Nov 08, 2021 at 11:16:42AM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 08.11.21 13:10, Jan Beulich wrote:
>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>>>> --- a/xen/arch/arm/vpci.c
>>
On 08.11.21 13:10, Jan Beulich wrote:
> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote:
>> --- a/xen/arch/arm/vpci.c
>> +++ b/xen/arch/arm/vpci.c
>> @@ -41,6 +41,15 @@ static int vpci_mmio_read(struct vcpu *v, mmio_info_t
>> *info,
>> /* data is
w being created by the helper macro
> DEFINE_DRM_GEM_FOPS().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/xen_drm_front.c | 16 +---
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 108 +---
> drivers/g
From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus
From: Oleksandr Andrushchenko
Reset the command register when passing through a PCI device:
it is possible that when passing through a PCI device its memory
decoding bits in the command register are already set. Thus, a
guest OS may not write to the command register to update memory
decoding, so
From: Oleksandr Andrushchenko
Add basic emulation support for guests. At the moment only emulate
PCI_COMMAND_INTX_DISABLE bit, the rest is not emulated yet and left
as TODO.
Signed-off-by: Oleksandr Andrushchenko
---
Since v3:
- gate more code on CONFIG_HAS_MSI
- removed logic for the case
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value as set
up by the host bridge in the hardware domain.
This way hardware doamin sees physical BAR values and guest sees
emulated ones
201 - 300 of 1401 matches
Mail list logo
