Hi Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> Can you clarify whether this is intended for the next release cycle?
Well, I don't think that this patch should be committed ASAP if this is
what you are asking about.
> On 29/05/2024 21:43, Volodymyr Babchuk wrote:
>> Al
Allow to provide TEE type for a Dom0less guest via "xen,tee"
property. Create appropriate nodes in the guests' device tree and
initialize tee subsystem for it.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/dom0less-build.c | 69 +++
xen/arch/arm/i
Hi Michal,
Michal Orzel writes:
> Hello,
>
> On 29/03/2024 01:08, Volodymyr Babchuk wrote:
>>
>>
>> Generic Interface (GENI) is a newer interface for low speed interfaces
>> like UART, I2C or SPI. This patch adds the simple driver for the UART
>> ins
I encountered platform, namely Qualcomm SA8155P where SMMU-compatible
IO-MMU advertises more context IQRs than there are context banks. This
should not be an issue, we need to relax the check in the SMMU driver
to allow such configuration.
Signed-off-by: Volodymyr Babchuk
---
xen/drivers
.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/Kconfig.debug | 19 +-
xen/arch/arm/arm64/debug-qcom.inc| 76 +++
xen/arch/arm/include/asm/qcom-uart.h | 48 +
xen/drivers/char/Kconfig | 8 +
xen/drivers/char/Makefile| 1 +
xen/drivers/char/qcom
.
Volodymyr Babchuk (3):
arm: smmu: allow SMMU to have more IRQs than context banks
drivers: serial: add Qualcomm GENI-based serial driver
arm: platform: qcom: add basic support SA8155P SoC
xen/arch/arm/Kconfig.debug | 19 +-
xen/arch/arm/arm64/debug-qcom.inc| 76 +++
xen/arch
right now (with Linux 6.8) even on baremetal setup the driver fails
anyways, because it does not know how to work with this SoC.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/qcom.c | 77 +
2 files changed, 78
omctl - specifically
for allocating vSBDFs. But then there would be two domctls that are
capable of allocating vSBDFs: assign_device and this new call... So
yeah, I am open for suggestions.
[1] https://lore.kernel.org/all/d6a58e73-da51-40f1-a2f7-576274945...@xen.org/
Volodymyr Babchuk (3):
dom
Now, when "assign_device" domctl supports providing a virtual SBDF, we
can leverage "vslot" option from PCI_SPEC_STRING and pass user
requested function number to the hypervisor.
Signed-off-by: Volodymyr Babchuk
---
tools/libs/light/libxl_pci.c | 7 ++-
1 file changed
Now, when "assign_device" domctl supports virtual_sbdf option, make it
available to libxc users. This is an optional parameter, if it is not
provided, xc_assign_device() will ask hypervisor to allocate a free
vSBDF.
Signed-off-by: Volodymyr Babchuk
--
This clearly breaks libxc API. S
desired vSBDF and hypervisor will try to use
it, if it is free and falls into permitted range.
[1] https://lore.kernel.org/all/d6a58e73-da51-40f1-a2f7-576274945...@xen.org/
Signed-off-by: Volodymyr Babchuk
---
tools/libs/ctrl/xc_domain.c | 1 +
xen/drivers/passthrough/pci.c | 17
Hi Stefan,
Stefan Hajnoczi writes:
> On Tue, 12 Dec 2023 at 10:36, Volodymyr Babchuk
> wrote:
>>
>> Hi Anthony
>>
>> Anthony PERARD writes:
>>
>> > On Fri, Dec 08, 2023 at 02:49:27PM -0800, Stefano Stabellini wrote:
>> >> On Fri, 8 D
Hi Anthony
Anthony PERARD writes:
> On Fri, Dec 08, 2023 at 02:49:27PM -0800, Stefano Stabellini wrote:
>> On Fri, 8 Dec 2023, Daniel P. Berrangé wrote:
>> > On Thu, Dec 07, 2023 at 11:12:48PM +, Michael Young wrote:
>> > > Builds of qemu-8.2.0rc2 with xen-4.18.0 are currently failing
>> >
Hello Jan,
Jan Beulich writes:
> On 02.12.2023 02:27, Volodymyr Babchuk wrote:
>> Introduce "fail" label in init_bars() function to have the centralized
>> error return path. This is the pre-requirement for the future changes
>> in this function.
>>
>&g
Hi Jan,
Jan Beulich writes:
> On 02.12.2023 02:27, Volodymyr Babchuk wrote:
>> This function can be used when user wants to remove all rangeset
>> entries but do not want to destroy rangeset itself.
>
> I have to admit that I'm not happy with the name: We're not cons
all,
what should be done in the future anyways. But right now this patch
moves us one step close to have QEMU build without legacy Xen
backends.
Signed-off-by: Volodymyr Babchuk
---
In v4:
- New in v4, previous was part of "xen: add option to disable legacy
backends"
- Do not
-off-by: Volodymyr Babchuk
---
Changes in v3:
- Use QOM properties instead of reading from XenStore
- Remove unneeded includes
- Move pcie_* fields into "struct cfg"
Changes in v2:
- Renamed virtio_pci_host to pcie_host entries in XenStore, because
there is nothing specific to
/html/qemu-devel/2023-11/msg05022.html
Signed-off-by: Volodymyr Babchuk
---
I am not sure if I made correct changes to build system, so this patch
is tagged as RFC.
Changes in v3:
- New patch in v3
---
hw/9pfs/meson.build | 4 +++-
hw/display/meson.build| 4 +++-
hw
n't created by Xen
toolstack. If they were created by toolstack, then it is toolstack's
job to do proper clean-up.
Suggested-by: Paul Durrant
Suggested-by: David Woodhouse
Co-Authored-by: Oleksandr Tyshchenko
Signed-off-by: Volodymyr Babchuk
Reviewed-by: David Woodhouse
---
Changes in
From: David Woodhouse
This allows a XenDevice implementation to know whether it was created
by QEMU, or merely discovered in XenStore after the toolstack created
it. This will allow us to create frontend/backend nodes only when we
should, rather than unconditionally attempting to overwrite them
returning default ~0 on read
may confuse guest OS.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
---
In v11:
- Access guest_addr after adjusting for MEM64_HI bar in
guest_bar_write()
- guest bar handlers renamed and now _mem_ part to denote
that they are handling only
rposes.
Suggested-by: Roger Pau Monné
Suggested-by: Jan Beulich
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
---
Changes in v11:
- Fixed commit message regarding possible spinlocks
- Removed parameter from allocate_and_map_msi_pirq(), which was added
in the prev ver
t: add RANGESETF_no_print flag
vpci/header: handle p2m range sets per BAR
vpci/header: program p2m with guest BAR view
vpci/header: emulate PCI_COMMAND register for guests
vpci: add initial support for virtual PCI bus topology
xen/arm: translate virtual PCI bus topology for guests
xen/ar
. Also, in most cases caller already has pointer
to pdev, so we can avoid an extra list walk.
Signed-off-by: Volodymyr Babchuk
---
In v11:
- Made pdev parameter very first in pci_enable_msi() and friends.
- Extended the commit message
- Added check for pdev into ns16550 driver
- Replaced hard
.
Suggested-by: Jan Beulich
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Jan Beulich
---
Since v5:
- comment indentation (Jan)
Since v1:
- update BUG_ON with new flag
- simplify the definition of the flags
---
xen/common/rangeset.c | 5 -
xen
mapped, while for
domUs the BARs are mapped at the requested guest address without
modifying the BAR address in the device PCI config space.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
---
In v11:
- Add vmsix_guest_table_addr() and vmsix_guest_table_base() functions
Introduce "fail" label in init_bars() function to have the centralized
error return path. This is the pre-requirement for the future changes
in this function.
This patch does not introduce functional changes.
Signed-off-by: Volodymyr Babchuk
Suggested-by: Roger Pau Monné
Acked-by:
are writing 0x in the target
register.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/vpci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
index b6ef440f17..05a479096e 100644
--- a/xen/arch/arm/vpci.c
+++ b/xen
.
Please note, that at the moment only function 0 of a multifunction
device can be passed through.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
---
In v11:
- Fixed code formatting
- Removed bogus write_unlock() call
- Fixed type for new_dev_number
In v10:
- Removed ASSERT
in the physical
topology, e.g. it can't be mapped to some physical host bridge.
So, all access to the host bridge itself needs to be trapped and
emulated.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
---
In v11:
- Fixed format issues
- Added ASSERT_UNREACHABLE() to the dummy
by
the said lock). In case both the newly introduced per-domain rwlock
and the pcidevs lock is taken, the latter must be acquired first.
Suggested-by: Roger Pau Monné
Suggested-by: Jan Beulich
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Roger Pau Monné
---
Changes in v10:
- pdev->dom
From: Stewart Hildebrand
Move iomem_caps initialization earlier (before arch_domain_create()).
Signed-off-by: Stewart Hildebrand
Signed-off-by: Volodymyr Babchuk
---
Changes in v10:
* fix off-by-one
* also permit access to GUEST_VPCI_PREFETCH_MEM_ADDR
Changes in v9:
* new patch
This is sort
-by: Oleksandr Andrushchenko
Acked-by: Julien Grall
Signed-off-by: Volodymyr Babchuk
---
This actually moved here from the part 2 of the prep work for PCI
passthrough on Arm as it seems to be the proper place for it.
Since v5:
- optimize with IS_ENABLED(CONFIG_HAS_PCI_MSI) since VPCI_MAX_VIRT_DEV
This function can be used when user wants to remove all rangeset
entries but do not want to destroy rangeset itself.
Signed-off-by: Volodymyr Babchuk
---
Changes in v11:
- Now the function only empties rangeset, without removing it from
domain's list
Changes in v10:
- New in v10
-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
---
In v11:
- Call vpci_assign_device() in "deassign_device" if IOMMU call
"reassign_device" was successful.
In v10:
- removed HAS_VPCI_GUEST_SUPPORT checks
- HAS_VPCI_GUEST_SUPPORT config option (in Kconfi
are no longer removed if the creation
of the mappings in vpci_process_pending() fails, as that's unlikely to
lead to a functional device in any case.
This is in preparation of making non-identity mappings in p2m for the MMIOs.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
sure only hardware domain can access the hardware directly
and restrict guests from doing so.
Suggested-by: Roger Pau Monné
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Roger Pau Monné
---
Since v9:
- removed stray formatting change
- added Roger's R-b
LE bit. In our case, we prohibit a guest to
change value of this bit if MSI(X) is enabled.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
---
It is better to rework this patch using new register handling tools
that Stewart Hildenbrand upstreaming right now.
In v11:
-
Hi Roger, Stewart,
Roger Pau Monné writes:
> On Thu, Oct 12, 2023 at 10:09:18PM +0000, Volodymyr Babchuk wrote:
>> From: Oleksandr Andrushchenko
>>
>> Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
>> to remain unaltered. PCI_COMMAND_SERR b
Hi Roger,
Roger Pau Monné writes:
> On Wed, Nov 22, 2023 at 01:18:32PM -0800, Stefano Stabellini wrote:
>> On Wed, 22 Nov 2023, Roger Pau Monné wrote:
>> > On Tue, Nov 21, 2023 at 05:12:15PM -0800, Stefano Stabellini wrote:
>> > > Let me expand on this. Like I wrote above, I think it is
Hi Roger
Thank you for the review.
Roger Pau Monné writes:
> On Thu, Oct 12, 2023 at 10:09:15PM +0000, Volodymyr Babchuk wrote:
>> From: Oleksandr Andrushchenko
>>
>> Use a previously introduced per-domain read/write lock to check
>> whether vpci
Hi David,
Thank you for the review
David Woodhouse writes:
> [[S/MIME Signed Part:Undecided]]
> On Fri, 2023-11-24 at 23:24 +, Volodymyr Babchuk wrote:
>> Xen PV devices in QEMU can be created in two ways: either by QEMU
>> itself, if they were passed via command line, o
Hi David,
"Woodhouse, David" writes:
> [[S/MIME Signed Part:Undecided]]
> On Fri, 2023-11-24 at 23:24 +, Volodymyr Babchuk wrote:
>> This patch makes legacy backends optional. As was discussed at [1]
>> this is a solution to a problem when we can't run QEMU a
of course.
[1]
https://lists.gnu.org/archive/html/qemu-devel/2023-11/msg05022.html
Signed-off-by: Volodymyr Babchuk
---
I am not sure if I made correct changes to the build system, thus this
patch is tagged as RFC.
Changes in v3:
- New patch in v3
---
accel/xen/xen-all.c | 13 +++
From: David Woodhouse
This allows a XenDevice implementation to know whether it was created
by QEMU, or merely discovered in XenStore after the toolstack created
it. This will allow us to create frontend/backend nodes only when we
should, rather than unconditionally attempting to overwrite them
n't created by Xen
toolstack. If they were created by toolstack, then it is toolstack's
job to do proper clean-up.
Suggested-by: Paul Durrant
Suggested-by: David Woodhouse
Co-Authored-by: Oleksandr Tyshchenko
Signed-off-by: Volodymyr Babchuk
---
Changes in v3:
- Rephrased the commit mess
-off-by: Volodymyr Babchuk
---
Changes in v3:
- Use QOM properties instead of reading from XenStore
- Remove unneeded includes
- Move pcie_* fields into "struct cfg"
Changes in v2:
- Renamed virtio_pci_host to pcie_host entries in XenStore, because
there is nothing specific to
Hi Igor,
Thank you for the review,
Igor Mammedov writes:
> On Tue, 21 Nov 2023 22:10:28 +
> Volodymyr Babchuk wrote:
>
>> From: Oleksandr Tyshchenko
>>
>> The bridge is needed for virtio-pci support, as QEMU can emulate the
>> whole bridge with
Hi David,
David Woodhouse writes:
> On 23 November 2023 12:17:57 GMT, Volodymyr Babchuk
> wrote:
>>
>>Hi David,
>>
>>David Woodhouse writes:
>>> Which PV backends do you care about? We already have net, block and console
>>> converted.
>
Hi David,
David Woodhouse writes:
> On 23 November 2023 11:54:01 GMT, Volodymyr Babchuk
> wrote:
>>
>>Hi Paul,
>>
>>Paul Durrant writes:
>>
>>> On 23/11/2023 00:07, Volodymyr Babchuk wrote:
>>>> Hi,
>>>> Volodymyr Ba
Hi Paul,
Paul Durrant writes:
> On 23/11/2023 00:07, Volodymyr Babchuk wrote:
>> Hi,
>> Volodymyr Babchuk writes:
>>
>>> Hi Stefano,
>>>
>>> Stefano Stabellini writes:
>>>
>>>> On Wed, 22 Nov 2023, David Woodhouse wro
Hi David,
David Woodhouse writes:
> [[S/MIME Signed Part:Undecided]]
> On Thu, 2023-11-23 at 09:28 +, Paul Durrant wrote:
>> On 23/11/2023 00:07, Volodymyr Babchuk wrote:
>> >
>> > Hi,
>> >
>> > Volodymyr Babchuk writes:
>> &
Hi David,
David Woodhouse writes:
> [[S/MIME Signed Part:Undecided]]
> On Tue, 2023-11-21 at 22:10 +, Volodymyr Babchuk wrote:
>>
>> --- a/hw/xen/xen-operations.c
>> +++ b/hw/xen/xen-operations.c
>> @@ -300,6 +300,18 @@ static bool libxenstore_creat
Hi Vikram,
Vikram Garhwal writes:
> Hi Volodymyr,
> Thank you sharing this patch. I have few comments below
> On Wed, Nov 22, 2023 at 02:39:46PM -0800, Stefano Stabellini wrote:
>> +Vikram
>>
>> On Tue, 21 Nov 2023, Volodymyr Babchuk wrote:
>
Hi,
Volodymyr Babchuk writes:
> Hi Stefano,
>
> Stefano Stabellini writes:
>
>> On Wed, 22 Nov 2023, David Woodhouse wrote:
>>> On Wed, 2023-11-22 at 15:09 -0800, Stefano Stabellini wrote:
>>> > On Wed, 22 Nov 2023, David Woodhouse wrote:
>>>
Hi David,
"Woodhouse, David" writes:
> On Wed, 2023-11-22 at 17:05 +, Paul Durrant wrote:
>> On 21/11/2023 22:10, Volodymyr Babchuk wrote:
>> > From: David Woodhouse
>> >
>> > This allows a XenDevice implementation to know whether it
wrote:
>> > > > On Wed, 22 Nov 2023, Paul Durrant wrote:
>> > > > > On 21/11/2023 22:10, Volodymyr Babchuk wrote:
>> > > > > > From: Oleksandr Tyshchenko
>> > > > > >
>> > > > > > Instead of forcing t
Hi David,
David Woodhouse writes:
> [[S/MIME Signed Part:Undecided]]
> On Tue, 2023-11-21 at 22:10 +, Volodymyr Babchuk wrote:
>>
>> --- a/hw/xen/xen-operations.c
>> +++ b/hw/xen/xen-operations.c
>> @@ -300,6 +300,18 @@ static bool libxenstore_creat
Paul Durrant writes:
> On 21/11/2023 22:10, Volodymyr Babchuk wrote:
>> From: David Woodhouse
>> This allows a XenDevice implementation to know whether it was
>> created
>> by QEMU, or merely discovered in XenStore after the toolstack created
>> it. This
Hi Paul,
Paul Durrant writes:
> On 21/11/2023 22:10, Volodymyr Babchuk wrote:
>> was created by QEMU
>> Xen PV devices in QEMU can be created in two ways: either by QEMU
>> itself, if they were passed via command line, or by Xen toolstack. In
>> the latter case,
Hi Philippe,
Philippe Mathieu-Daudé writes:
> Hi Volodymyr,
>
> On 21/11/23 23:10, Volodymyr Babchuk wrote:
>> was created by QEMU
>
> Please do not split lines between subject and content. Rewrite the
> full line. Preferably restrict the subject to 72 chars.
I tr
run in different domains and serve
virtio-pci devices for the same guest should use different host
bridge resources for Xen to distinguish. The rule for the guest
device-tree generation is one PCI host bridge per backend domain.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Volodymyr
ore entries during device teardown
only if they weren't created by Xen toolstack. If they were created by
toolstack, then it is toolstack's job to do proper clean-up.
Suggested-by: Paul Durrant
Suggested-by: David Woodhouse
Co-Authored-by: Oleksandr Tyshchenko
Signed-off-by: Volodymyr Babc
will make specific implementation to
get original owner of an entry and pass it back to
set_permissions() call.
Please note, that XenStore inherits permissions, so even if entry is
newly created by, it already has the owner set to match owner of entry
at previous level.
Signed-off-by: Volodym
e required directories in advance.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Volodymyr Babchuk
---
hw/xen/xen_pvdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index c5ad71e8dc..42bdd4f6c8 100644
--- a/hw/xen/xen_pvdev.c
++
From: David Woodhouse
This allows a XenDevice implementation to know whether it was created
by QEMU, or merely discovered in XenStore after the toolstack created
it. This will allow us to create frontend/backend nodes only when we
should, rather than unconditionally attempting to overwrite them
Hi Stefano,
Stefano Stabellini writes:
> On Fri, 17 Nov 2023, Volodymyr Babchuk wrote:
>> > On Fri, 17 Nov 2023, Volodymyr Babchuk wrote:
>> >> Hi Julien,
>> >>
>> >> Julien Grall writes:
>> >>
>> >> > Hi Volodymyr
Previous change to xenstored used "%d" to format conn->id while in fact
conn->id has "unsigned int" type, so "%u" should be used.
Fixes: 97f8555acbf3 ("xenstored: print domain id in traces")
Signed-off-by: Volodymyr Babchuk
---
tools/xenstored/co
Hi Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> On 16/11/2023 20:56, Volodymyr Babchuk wrote:
>> It is very helpful to see domain id why analyzing xenstored
>> traces. Especially when you are trying to understand which exactly
>> domain performs an action.
Hi Stefano,
Stefano Stabellini writes:
> On Fri, 17 Nov 2023, Volodymyr Babchuk wrote:
>> Hi Julien,
>>
>> Julien Grall writes:
>>
>> > Hi Volodymyr,
>> >
>> > On 17/11/2023 14:09, Volodymyr Babchuk wrote:
>> >> Hi Stefa
Hi Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> On 17/11/2023 14:09, Volodymyr Babchuk wrote:
>> Hi Stefano,
>> Stefano Stabellini writes:
>>
>>> On Fri, 17 Nov 2023, Volodymyr Babchuk wrote:
>>>>> I still think, no matter the BDF a
Hi Stefano,
Stefano Stabellini writes:
> On Fri, 17 Nov 2023, Volodymyr Babchuk wrote:
>> > I still think, no matter the BDF allocation scheme, that we should try
>> > to avoid as much as possible to have two different PCI Root Complex
>> > emulators. Ideally w
Hi Stefano,
Stefano Stabellini writes:
> On Thu, 16 Nov 2023, Volodymyr Babchuk wrote:
>> Hi Stefano,
>>
>> Stefano Stabellini writes:
>>
>> > + Stewart, Vikram
>> >
>> > On Wed, 15 Nov 2023, Oleksandr Tyshchenko wrote:
>> >>
Hi Stefano,
Stefano Stabellini writes:
> On Thu, 16 Nov 2023, Julien Grall wrote:
>> IIUC, this means that Xen will allocate the BDF. I think this will become a
>> problem quite quickly as some of the PCI may need to be assigned at a
>> specific
>> vBDF (I have the intel graphic card in
It is very helpful to see domain id why analyzing xenstored
traces. Especially when you are trying to understand which exactly
domain performs an action.
Signed-off-by: Volodymyr Babchuk
---
tools/xenstored/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools
Hi Julien,
Julien Grall writes:
> On 16/11/2023 15:26, Stewart Hildebrand wrote:
>> On 11/16/23 10:12, Julien Grall wrote:
>>> Hi Volodymyr,
>>>
>>> On 16/11/2023 15:07, Volodymyr Babchuk wrote:
>>>> With my vPCI patch series in place, hyperv
Hi Stefano,
Stefano Stabellini writes:
> + Stewart, Vikram
>
> On Wed, 15 Nov 2023, Oleksandr Tyshchenko wrote:
>> On 15.11.23 14:33, Julien Grall wrote:
>> > Thanks for adding support for virtio-pci in Xen. I have some questions.
>> >
>> > On 15/11/2023 11:26, Sergiy Kibrik wrote:
>> >>
Hi David,
David Woodhouse writes:
> [[S/MIME Signed Part:Undecided]]
> On Fri, 2023-11-10 at 20:42 +, Volodymyr Babchuk wrote:
>> From: Oleksandr Tyshchenko
>>
>> Instead of forcing the owner to domid 0, use XS_PRESERVE_OWNER to save
>> the previous owner of
Hi David,
David Woodhouse writes:
> On 11 November 2023 16:51:22 GMT-05:00, Andrew Cooper
> wrote:
>>On 11/11/2023 8:18 pm, David Woodhouse wrote:
>>> On 11 November 2023 08:43:40 GMT-05:00, Andrew Cooper
>>> wrote:
Furthermore, the control domain doesn't always have the domid of 0.
Hi David,
David Woodhouse writes:
> [[S/MIME Signed Part:Undecided]]
> On Sat, 2023-11-11 at 11:01 +, David Woodhouse wrote:
>>
>> > --- a/hw/xen/xen-operations.c
>> > +++ b/hw/xen/xen-operations.c
>> > @@ -300,6 +300,18 @@ static bool libxenstore_create(struct qemu_xs_handle
>> > *h,
Hi David,
David Woodhouse writes:
> [[S/MIME Signed Part:Undecided]]
> On Fri, 2023-11-10 at 20:42 +, Volodymyr Babchuk wrote:
>> Add option to preserve owner when creating an entry in Xen Store. This
>> may be needed in cases when Qemu is working as device mo
Hi David,
David Woodhouse writes:
> [[S/MIME Signed Part:Undecided]]
> On Fri, 2023-11-10 at 20:42 +, Volodymyr Babchuk wrote:
>> From: Oleksandr Tyshchenko
>>
>> This patch adds basic virtio-pci support for xen_arm machine.
>
> Why only xen_arm? Couldn't t
to create required directories in advance.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Volodymyr Babchuk
---
hw/xen/xen_pvdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c
index c5ad71e8dc..42bdd4f6c8 100644
--- a/hw/xen/xen_pvd
guest should use different host
bridge resources for Xen to distinguish. The rule for the guest
device-tree generation is one PCI host bridge per backend domain.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Volodymyr Babchuk
---
hw/arm/xen_arm.c| 186
, this is not really
needed, probably it is just a leftover and all xen_device_frontend_printf()
instances should go away completely.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Volodymyr Babchuk
---
hw/block/xen-block.c | 11 +++
hw/xen/xen-bus.c | 2 +-
2 files changed, 8
will make specific implementation to
get original owner of an entry and pass it back to
set_permissions() call.
Signed-off-by: Volodymyr Babchuk
---
hw/i386/kvm/xen_xenstore.c | 18 ++
hw/xen/xen-operations.c | 12
include/hw/xen/xen_backend_ops.h | 2 +
that here, this is not really
needed, probably it is just a leftover and all xs_node_destroy()
instances should go away completely.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Volodymyr Babchuk
---
hw/xen/xen-bus.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
e.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Volodymyr Babchuk
---
hw/xen/xen-bus.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 75474d4b43..6e7ec3af64 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -519,6 +519,10 @@ s
Volodymyr Babchuk writes:
> From: Oleksandr Andrushchenko
>
> Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
> to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the
> guest's view of this will want to be zero initially, the host having se
Hi Stewart,
Stewart Hildebrand writes:
> On 10/12/23 18:09, Volodymyr Babchuk wrote:
>> This function can be used when user wants to remove all rangeset
>> entries but do not want to destroy rangeset itself.
>>
>> Signed-off-by: Volodymyr Babchuk
>&
Julien,
Julien Grall writes:
> Hi,
>
> On 13/10/2023 14:06, Volodymyr Babchuk wrote:
>> Hi Julien,
>> Julien Grall writes:
>>
>>> Hi Volodymyr,
>>>
>>> On 12/10/2023 23:09, Volodymyr Babchuk wrote:
>>>> From: Oleksandr Andru
Hi Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> On 12/10/2023 23:09, Volodymyr Babchuk wrote:
>> 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 handler
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-by:
are writing 0x in the target
register.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/vpci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
index 3521d5bc2f..f1e434a5db 100644
--- a/xen/arch/arm/vpci.c
+++ b/xen
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
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: Stewart Hildebrand
Move iomem_caps initialization earlier (before arch_domain_create()).
Signed-off-by: Stewart Hildebrand
---
Changes in v10:
* fix off-by-one
* also permit access to GUEST_VPCI_PREFETCH_MEM_ADDR
Changes in v9:
* new patch
This is sort of a follow-up to:
by
the said lock). In case both the newly introduced per-domain rwlock
and the pcidevs lock is taken, the later must be acquired first.
Suggested-by: Roger Pau Monné
Suggested-by: Jan Beulich
Signed-off-by: Volodymyr Babchuk
---
Changes in v10:
- pdev->domain is assigned after removing fro
From: Oleksandr Andrushchenko
A guest would be able to read and write those registers which are not
emulated and have no respective vPCI handlers, so it will be possible
for it to access the hardware directly.
In order to prevent a guest from reads and writes from/to the unhandled
registers make
LE bit. In our case, we prohibit a guest to
change value of this bit if MSI(X) is enabled.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
---
In v10:
- Added cf_check attribute to guest_cmd_read
- Removed warning about non-zero cmd
- Updated comment MSI code regardin
1 - 100 of 666 matches
Mail list logo
