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 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
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 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
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 o
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 to
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
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
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 valid.
&g
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 ca
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 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 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 02:16:19P
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 11.1
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
>>> “PHYSDEVOP_pci_device_
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 t
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
>>>
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:
>>>>
D_PFN is unused, and with x86'es paging_mark_pfn_dirty()
> being the only user of pfn_t it also doesn't seem likely that new uses
> would appear, remove that one at this same occasion.
>
> Signed-off-by: Jan Beulich
With the above nit fixed:
Reviewed-by: Oleksandr Andrushc
From: Oleksandr Andrushchenko
vchan server creates XenStore entries to advertise its event channel and
ring, but those are not removed after the server quits.
Add additional cleanup step, so those are removed, so clients do not try
to connect to a non-existing server.
Signed-off-by: Oleksandr
Hi, Jan!
On 10.12.21 11:40, Jan Beulich wrote:
> Determining that behavior is correct (i.e. results in failure) for a
> passed in GFN equaling INVALID_GFN is non-trivial. Make this quite a bit
> more obvious by checking input in generic code - both for singular
> requests to not match the value an
Hi, Julien!
On 10.12.21 19:52, Julien Grall wrote:
> Hi Oleksandr,
>
> On 09/12/2021 07:29, Oleksandr Andrushchenko wrote:
>> +unsigned int domain_vpci_get_num_mmio_handlers(struct domain *d)
>> +{
>> + if ( !has_vpci(d) )
>> + return 0;
>&
Hi, Roger!
On 11.12.21 10:20, Roger Pau Monné wrote:
> On Fri, Dec 10, 2021 at 05:55:03PM +, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 25/11/2021 11:02, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> vpci_process_p
Hi, Volodymyr!
On 15.12.21 05:20, Volodymyr Babchuk wrote:
> Hi Oleksandr,
>
> Sorry for jumping in amid v5, but...
>
> Oleksandr Andrushchenko writes:
>
>> From: Oleksandr Andrushchenko
>>
>> There are range sets which should not be printed, so introduce a f
Hi, Oleksii!
On 14.12.21 11:34, Oleksii Moisieiev wrote:
> Implementation includes platform-specific smc handler for rcar3 platform.
>
> Signed-off-by: Oleksii Moisieiev
Reviewed-by: Oleksandr Andrushchenko
> ---
> xen/arch/arm/platforms/Makefile | 1 +
> xen/arch/arm
Dear rest maintainers!
Could you please review this series which seems to get stuck?
Thank you in advance,
Oleksandr
On 25.11.21 13:02, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Hi, all!
>
> 1. This patch series is focusing on vPCI and adds support f
Hi, Jan!
On 15.12.21 14:07, Jan Beulich wrote:
> On 15.12.2021 12:56, Oleksandr Andrushchenko wrote:
>> Dear rest maintainers!
>>
>> Could you please review this series which seems to get stuck?
> I don't seem to have any record of you having pinged Roger as the vP
Hi, Roger!
On 15.12.21 16:51, Roger Pau Monné wrote:
> On Wed, Dec 15, 2021 at 12:22:32PM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Jan!
>>
>> On 15.12.21 14:07, Jan Beulich wrote:
>>> On 15.12.2021 12:56, Oleksandr Andrushchenko wrote:
>>>> Dear re
Hi, Julien!
On 15.12.21 19:48, Julien Grall wrote:
> On 09/12/2021 07:29, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Hi, all!
>
> Hi Oleksandr,
>
>> This is an assorted series of patches which aim is to make some further
>> bas
id inline function.
>
> Signed-off-by: Christopher Clark
> Signed-off-by: Daniel P. Smith
> Acked-by: Dario Faggioli
Reviewed-by: Oleksandr Andrushchenko
> ---
> xen/arch/x86/cpu/mcheck/mce.c | 2 +-
> xen/arch/x86/cpu/vpmu.c | 2 +-
> xen/common/domain.
Hi, Roger!
On 11.12.21 10:57, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 11.12.21 10:20, Roger Pau Monné wrote:
>> On Fri, Dec 10, 2021 at 05:55:03PM +, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 25/11/2021 11:02, Oleksandr Andrushchenko
Hello, Roger, Jan!
On 12.01.22 16:42, Jan Beulich wrote:
> On 11.01.2022 16:17, Roger Pau Monné wrote:
>> On Thu, Nov 25, 2021 at 01:02:40PM +0200, Oleksandr Andrushchenko wrote:
>>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
>>> index 657697
On 12.01.22 17:27, Jan Beulich wrote:
> On 25.11.2021 12:02, 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 that
Hello, Roger, Jan!
On 13.01.22 15:38, Jan Beulich wrote:
> On 13.01.2022 14:27, Roger Pau Monné wrote:
>> On Thu, Nov 25, 2021 at 12:17:32PM +0100, Jan Beulich wrote:
>>> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>
Hi, Roger, Jan!
On 13.01.22 10:58, Roger Pau Monné wrote:
> On Wed, Jan 12, 2022 at 04:52:51PM +0100, Jan Beulich wrote:
>> On 12.01.2022 16:42, Roger Pau Monné wrote:
>>> On Wed, Jan 12, 2022 at 03:57:36PM +0100, Jan Beulich wrote:
>>>> On 25.11.2021 12:02,
Hi, Jan!
On 12.01.22 16:57, Jan Beulich wrote:
> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
>> @@ -68,12 +84,13 @@ int vpci_add_handlers(struct pci_dev *pdev)
>> /* We should not get here twice for the same device. */
>> ASSERT(!pdev->vpci);
>>
Hi, Jan, Roger!
On 26.01.22 13:13, Roger Pau Monné wrote:
> On Wed, Jan 26, 2022 at 08:40:09AM +0000, Oleksandr Andrushchenko wrote:
>> Hello, Roger, Jan!
>>
>> On 12.01.22 16:42, Jan Beulich wrote:
>>> On 11.01.2022 16:17, Roger Pau Monné wrote:
>>>>
I am going to postpone this patch as it does need major re-thinking
on the approach to take. This is possible as it fixes a really rare
use-case seen during development phase, so shouldn't hurt the run-time
Thank you,
Oleksandr
On 25.11.21 13:02, Oleksandr Andrushchenko wrote:
> From: O
Hi, Roger!
On 12.01.22 14:12, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:42PM +0200, 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
Hi, Roger!
On 13.01.22 13:40, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:42PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>> +#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
>> +/* Notify vPCI that device is assigned to guest. */
>> +in
Hi, Roger!
On 31.01.22 10:56, Roger Pau Monné wrote:
> On Fri, Jan 28, 2022 at 02:15:08PM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Roger, Jan!
>>
>> On 13.01.22 10:58, Roger Pau Monné wrote:
>>> On Wed, Jan 12, 2022 at 04:52:51PM +0100, Jan Beulich wrote:
>&
Hi, Roger!
On 12.01.22 14:35, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:43PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add relevant vpci register handlers when assigning PCI device to a domain
>> and remove those whe
Hi, Roger!
On 12.01.22 19:34, Roger Pau Monné wrote:
> A couple more comments I realized while walking the dog.
>
> On Thu, Nov 25, 2021 at 01:02:43PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add relevant vpci register handlers whe
On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 12.01.22 14:35, Roger Pau Monné wrote:
>>
>>> +static void guest_rom_write(const struct pci_dev *pdev, unsigned int reg,
>>> +uint32_t val, void *data)
>>
Hi, Jan!
On 31.01.22 12:54, Jan Beulich wrote:
> On 31.01.2022 11:40, Oleksandr Andrushchenko wrote:
>> On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
>>> Hi, Roger!
>>>
>>> On 12.01.22 14:35, Roger Pau Monné wrote:
>>>>> +static void guest
On 31.01.22 13:10, Roger Pau Monné wrote:
> On Mon, Jan 31, 2022 at 10:40:47AM +0000, Oleksandr Andrushchenko wrote:
>> On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
>>> Hi, Roger!
>>>
>>> On 12.01.22 14:35, Roger Pau Monné wrote:
>>>>> +sta
On 31.01.22 13:27, Roger Pau Monné wrote:
> On Mon, Jan 31, 2022 at 11:04:29AM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Jan!
>>
>> On 31.01.22 12:54, Jan Beulich wrote:
>>> On 31.01.2022 11:40, Oleksandr Andrushchenko wrote:
>>>> On 31.01.22 11:4
On 31.01.22 13:39, Jan Beulich wrote:
> On 31.01.2022 12:23, Oleksandr Andrushchenko wrote:
>> On 31.01.22 13:10, Roger Pau Monné wrote:
>>> Right (see my previous reply to this comment). I think it would be
>>> easier (and cleaner) if you switched the default behav
On 31.01.22 15:36, Jan Beulich wrote:
> On 31.01.2022 14:30, Oleksandr Andrushchenko wrote:
>>
>> On 31.01.22 13:39, Jan Beulich wrote:
>>> On 31.01.2022 12:23, Oleksandr Andrushchenko wrote:
>>>> On 31.01.22 13:10, Roger Pau Monné wrote:
>>>>&g
On 31.01.22 15:51, Jan Beulich wrote:
> On 31.01.2022 14:41, Oleksandr Andrushchenko wrote:
>> On 31.01.22 15:36, Jan Beulich wrote:
>>> On 31.01.2022 14:30, Oleksandr Andrushchenko wrote:
>>>> On 31.01.22 13:39, Jan Beulich wrote:
>>>>> On 31
>>> I wonder whether we need to protect the added code with
>>> CONFIG_HAS_VPCI_GUEST_SUPPORT, this would effectively be dead code
>>> otherwise. Long term I don't think we wish to differentiate between
>>> dom0 and domU vPCI support at build time, so I'm unsure whether it's
>>> helpful to pollute
Hi, Roger!
>> rom->type = VPCI_BAR_EMPTY;
>> }
>> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
>> index ed127a08a953..0a73b14a92dc 100644
>> --- a/xen/include/xen/vpci.h
>> +++ b/xen/include/xen/vpci.h
>> @@ -68,7 +68,10 @@ struct vpci {
>> struct vpci_head
On 31.01.22 17:50, Jan Beulich wrote:
> On 31.01.2022 16:06, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>>>rom->type = VPCI_BAR_EMPTY;
>>>>}
>>>> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
>>>
Hi, Roger!
On 31.01.22 10:45, Oleksandr Andrushchenko wrote:
> Hi, Roger!
>
> On 13.01.22 13:40, Roger Pau Monné wrote:
>> On Thu, Nov 25, 2021 at 01:02:42PM +0200, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>> +#ifdef CONFIG_HAS_VPCI_GUEST
Hi, Roger!
On 01.02.22 12:10, Roger Pau Monné wrote:
> On Tue, Feb 01, 2022 at 07:31:31AM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 31.01.22 17:50, Jan Beulich wrote:
>>> On 31.01.2022 16:06, Oleksandr Andrushchenko wrote:
>>>> Hi, Roger!
>>>&
From: Oleksandr Andrushchenko
This helper destroys all the ranges of the rangeset given.
Please note, that it uses rangeset_remove_range which returns an error
code on failure. This error code can be ignored as while destroying all
the ranges no memory allocation is expected, so in this case it
From: Oleksandr Andrushchenko
Hi, all!
While working on vPCI series [1] I have created number of patches that
either add some useful helpers or serve as the ground for the upcoming
vPCI changes or both.
To ease the task of reviewing the bigger vPCI series I am sending these
now with the hope
From: Oleksandr Andrushchenko
Shrink critical section in vpci_{read/write} as racing calls to
vpci_{read,write}_hw() shouldn't be a problem. Those are just wrappers
around pci_conf_{read,write} functions, and the required locking (in
case of using the IO ports) is already taken care in pci_
dropped prior to freeing pdev->vpci.
Signed-off-by: Roger Pau Monné
Signed-off-by: Oleksandr Andrushchenko
---
Cc: Andrew Cooper
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
https://lore.kernel.
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
Hi, Julien!
On 01.02.22 19:05, Julien Grall wrote:
> Hi,
>
> On 01/02/2022 16:25, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> This helper destroys all the ranges of the rangeset given.
>> Please note, that it uses rangeset_remove_range
On 01.02.22 19:33, Julien Grall wrote:
>
>
> On 01/02/2022 17:14, Oleksandr Andrushchenko wrote:
>> On 01.02.22 19:05, Julien Grall wrote:
>>> On 01/02/2022 16:25, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>>>>
>>
Hi, Roger!
On 12.01.22 17:15, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:44PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Instead of handling a single range set, that contains all the memory
>> regions of all the BARs and RO
Hi, Roger!
On 13.01.22 12:22, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:45PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Take into account guest's BAR view and program its p2m accordingly:
>> gfn is guest's view o
Hi, Jan!
On 02.02.22 10:48, Jan Beulich wrote:
> On 01.02.2022 17:25, Oleksandr Andrushchenko wrote:
>> Oleksandr Andrushchenko (3):
>>rangeset: add RANGESETF_no_print flag
>>rangeset: add rangeset_reset helper function
>>vpci: shrink critical section in vp
Hi, Jan!
On 02.02.22 11:05, Jan Beulich wrote:
> On 02.02.2022 09:44, Roger Pau Monné wrote:
>> On Tue, Feb 01, 2022 at 06:25:07PM +0200, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
> Oleksandr, can you please clarify authorship here? The rule of
>>> +gdprintk(XENLOG_G_DEBUG,
>>> + "%smap [%lx, %lx] -> %#"PRI_gfn" for %pd\n",
>>> + map->map ? "" : "un", s, e, gfn_x(start_gfn),
>>> + map->d);
>> That's too chatty IMO, I could be fine with printing something along
>> this lines from mod
On 02.02.22 11:45, Jan Beulich wrote:
> On 02.02.2022 10:38, Oleksandr Andrushchenko wrote:
>> On 02.02.22 11:05, Jan Beulich wrote:
>>> On 02.02.2022 09:44, Roger Pau Monné wrote:
>>>> On Tue, Feb 01, 2022 at 06:25:07PM +0200, Oleksandr Andrushchenko wrote:
>&
Hi, Roger!
On 02.02.22 11:56, Roger Pau Monné wrote:
> On Wed, Feb 02, 2022 at 06:44:41AM +0000, Oleksandr Andrushchenko wrote:
>> Hi, Roger!
>>
>> On 12.01.22 17:15, Roger Pau Monné wrote:
>>> On Thu, Nov 25, 2021 at 01:02:44PM +0200, Oleksandr Andrushchenko wrote:
Hi, Roger!
On 02.02.22 11:45, Roger Pau Monné wrote:
> On Tue, Feb 01, 2022 at 06:25:08PM +0200, Oleksandr Andrushchenko wrote:
>> From: Roger Pau Monne
>>
>> This way the lock can be used to check whether vpci is present, and
>> removal can be performed while holding
On 02.02.22 12:34, Roger Pau Monné wrote:
> On Wed, Feb 02, 2022 at 09:46:21AM +0000, Oleksandr Andrushchenko wrote:
>>>>> +gdprintk(XENLOG_G_DEBUG,
>>>>> + "%smap [%lx, %lx] -> %#"PRI_gfn" for %pd\n",
>>>
Hi, Jan!
On 02.02.22 11:22, Jan Beulich wrote:
> On 01.02.2022 17:25, Oleksandr Andrushchenko wrote:
>> From: Roger Pau Monne
>>
>> This way the lock can be used to check whether vpci is present, and
>> removal can be performed while holding the lock, in order t
On 02.02.22 13:11, Jan Beulich wrote:
> On 02.02.2022 11:44, Oleksandr Andrushchenko wrote:
>> Again, IMO, adding such a big piece of DEBUG code instead of
>> printing a single DEBUG message could be a bit expansive.
>> I still hear your concerns on *when* it is printed, b
On 02.02.22 13:14, Jan Beulich wrote:
> On 02.02.2022 12:03, Oleksandr Andrushchenko wrote:
>> On 02.02.22 11:22, Jan Beulich wrote:
>>> On 01.02.2022 17:25, Oleksandr Andrushchenko wrote:
>>>> From: Roger Pau Monne
>>>>
>>>> This way the
Hi, Roger!
On 13.01.22 12:50, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:46PM +0200, 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 13.01.22 13:07, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:47PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Reset the command register when passing through a PCI device:
>> it is possible that when passing thro
Hi, Jan!
On 12.01.22 17:39, Jan Beulich wrote:
> On 25.11.2021 12:02, Oleksandr Andrushchenko wrote:
>> @@ -145,6 +148,53 @@ int vpci_add_handlers(struct pci_dev *pdev)
>> }
>>
>> #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
>> +int vpci_add_vi
Hi, Roger!
On 13.01.22 13:35, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:48PM +0200, 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.02.22 15:32, Jan Beulich wrote:
> On 02.02.2022 13:49, Oleksandr Andrushchenko wrote:
>> On 13.01.22 12:50, Roger Pau Monné wrote:
>>> On Thu, Nov 25, 2021 at 01:02:46PM +0200, Oleksandr Andrushchenko wrote:
>>>> --- a/xen/drivers/vpci/header.c
>&g
Hi, Roger!
On 13.01.22 14:18, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:49PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> There are three originators for the PCI configuration space access:
>> 1. The domain that owns
Hi, Roger!
On 13.01.22 15:23, Roger Pau Monné wrote:
> On Thu, Nov 25, 2021 at 01:02:50PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> At the moment, we always allocate an extra 16 slots for IO handlers
>> (see MAX_IO_HANDLER). So while
On 02.02.22 16:18, Jan Beulich wrote:
> On 02.02.2022 14:47, Oleksandr Andrushchenko wrote:
>>> On 02.02.2022 13:49, Oleksandr Andrushchenko wrote:
>>>> On 13.01.22 12:50, Roger Pau Monné wrote:
>>>>> On Thu, Nov 25, 2021 at 01:02:46PM +0200, Oleksand
On 02.02.22 16:31, Jan Beulich wrote:
> On 02.02.2022 15:26, Oleksandr Andrushchenko wrote:
>>
>> On 02.02.22 16:18, Jan Beulich wrote:
>>> On 02.02.2022 14:47, Oleksandr Andrushchenko wrote:
>>>>> On 02.02.2022 13:49, Oleksandr Andrushchenko wrote:
&g
On 02.02.22 17:08, Jan Beulich wrote:
> On 02.02.2022 16:04, Oleksandr Andrushchenko wrote:
>>
>> On 02.02.22 16:31, Jan Beulich wrote:
>>> On 02.02.2022 15:26, Oleksandr Andrushchenko wrote:
>>>> On 02.02.22 16:18, Jan Beulich wrote:
>>>>>
Hi, Bertrand!
On 26.11.21 14:19, Oleksandr Andrushchenko wrote:
> Hi, Bertrand!
>
> On 25.11.21 18:28, Bertrand Marquis wrote:
>> Hi Oleksandr,
>>
>>> On 25 Nov 2021, at 11:02, Oleksandr Andrushchenko
>>> wrote:
>>>
>>> From: Oleksandr A
Hi, Roger!
>> Also memory decoding needs to be initially disabled when used by
>> guests, in order to prevent the BAR being placed on top of a RAM
>> region. The guest physmap will be different from the host one, so it's
>> possible for BARs to end up placed on top of RAM regions initially
>> until
Hi, Jan!
On 03.02.22 14:44, Jan Beulich wrote:
> On 03.02.2022 13:36, Oleksandr Andrushchenko wrote:
>> Hi, Bertrand!
>>
>> On 26.11.21 14:19, Oleksandr Andrushchenko wrote:
>>> Hi, Bertrand!
>>>
>>> On 25.11.21 18:28, Bertrand Marquis wrote:
>&g
On 03.02.22 14:50, Jan Beulich wrote:
> On 03.02.2022 13:48, Oleksandr Andrushchenko wrote:
>> Hi, Jan!
>>
>> On 03.02.22 14:44, Jan Beulich wrote:
>>> On 03.02.2022 13:36, Oleksandr Andrushchenko wrote:
>>>> Hi, Bertrand!
>>>>
>>&
On 03.02.22 14:54, Jan Beulich wrote:
> On 03.02.2022 13:45, Oleksandr Andrushchenko wrote:
>>>> Also memory decoding needs to be initially disabled when used by
>>>> guests, in order to prevent the BAR being placed on top of a RAM
>>>> region. The guest
On 03.02.22 16:04, Jan Beulich wrote:
> On 03.02.2022 14:30, Oleksandr Andrushchenko wrote:
>>
>> On 03.02.22 14:54, Jan Beulich wrote:
>>> On 03.02.2022 13:45, Oleksandr Andrushchenko wrote:
>>>>>> Also memory decoding needs to be initially disabl
On 03.02.22 16:05, Roger Pau Monné wrote:
> On Thu, Feb 03, 2022 at 01:30:26PM +0000, Oleksandr Andrushchenko wrote:
>>
>> On 03.02.22 14:54, Jan Beulich wrote:
>>> On 03.02.2022 13:45, Oleksandr Andrushchenko wrote:
>>>>>> Also memory decoding n
vpci_read for example, since the
lock was dropped prior to freeing pdev->vpci.
Signed-off-by: Roger Pau Monné
Signed-off-by: Oleksandr Andrushchenko
---
Cc: Andrew Cooper
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
---
New in v5 of this series: this is an updated version of
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
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 v5:
- do not split code into run_vpci_init
- do not check for
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
From: Oleksandr Andrushchenko
A guest can read and write those registers which are not emulated and
have no respective vPCI handlers, so it can access the HW directly.
In order to prevent a guest from reads and writes from/to the unhandled
registers make sure only hardware domain can access HW
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 that
From: Oleksandr Andrushchenko
Add a stub for is_memory_hole which is required for PCI passthrough
on Arm.
Signed-off-by: Oleksandr Andrushchenko
---
Cc: Julien Grall
Cc: Stefano Stabellini
---
New in v6
---
xen/arch/arm/mm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen
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 see
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
201 - 300 of 1139 matches
Mail list logo
