On 29.09.2021 07:45, Juergen Gross wrote:
> On 23.09.21 17:31, Jan Beulich wrote:
>> On 23.09.2021 17:25, Juergen Gross wrote:
>>> On 23.09.21 17:19, Jan Beulich wrote:
On 23.09.2021 17:15, Juergen Gross wrote:
> On 23.09.21 17:10, Jan Beulich wrote:
>> On 23.09.2021 16:59, Juergen Gro
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> On Arm, the initial plan is to only support GICv3 ITS which doesn't
> require us to manage the MSIs because the HW will protect against
> spoofing. Move the code under CONFIG_HAS_PCI_MSI flag to gate the code
> for ARM.
>
> No functio
On 29.09.21 09:28, Jan Beulich wrote:
On 29.09.2021 07:45, Juergen Gross wrote:
On 23.09.21 17:31, Jan Beulich wrote:
On 23.09.2021 17:25, Juergen Gross wrote:
On 23.09.21 17:19, Jan Beulich wrote:
On 23.09.2021 17:15, Juergen Gross wrote:
On 23.09.21 17:10, Jan Beulich wrote:
On 23.09.2021
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> In a follow-up we will enable PCI support in Xen on Arm (i.e select
> HAS_PCI).
>
> The generic code expects the arch to implement a few functions:
> arch_iommu_use_permitted()
> arch_pci_clean_pirqs()
>
> Note that this is not yet s
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> prelink.o: In function `pcie_aer_get_firmware_first’:
> drivers/passthrough/pci.c:1251: undefined reference to `apei_hest_parse'
>
> Compilation error is observed when ACPI and HAS_PCI is enabled for ARM
> architecture. APEI not suppo
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> ARM architecture does not implement I/O ports. Ignore this call on ARM
> to avoid the overhead of making a hypercall just for Xen to return
> -ENOSYS.
>
> Signed-off-by: Rahul Singh
> Reviewed-by: Stefano Stabellini
Reviewed-by: Ber
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> Hardware domain is in charge of doing the PCI enumeration and will
> discover the PCI devices and then will communicate to XEN via hyper
> call PHYSDEVOP_pci_device_add(..) to add the PCI devices in XEN.
>
> Also implement PHYSDEVOP_p
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> Based Linux commit a67e9472da423ec47a3586920b526ebaedf25fc3
>
> Import the Linux helper of_property_read_variable_u32_array. This
> function find and read an array of 32 bit integers from a property,
> with bounds on the minimum and m
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> Based Linux commit a67e9472da423ec47a3586920b526ebaedf25fc3
>
> Import the Linux helper of_property_read_u32_array. This function find
> and read an array of 32 bit integers from a property.
>
> Signed-off-by: Rahul Singh
Reviewed-b
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> Based Linux commit 41e5c0f81d3e676d671d96a0a1fafb27abfbd9d7
>
> Import the Linux helper of_get_pci_domain_nr. This function will try to
> obtain the host bridge domain number by finding a property called
> "linux,pci-domain" of the gi
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> pci_init(..) will be called during xen startup to initialize and probe
> the PCI host-bridge driver.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> Change in v3:
> - Some nit for device_init(.
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> Add cmdline boot option "pci-passthrough = = " to enable or
> disable the PCI passthrough support on ARM.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> Change in v3:
> - Remove "define pci_pa
Add some missing defines and documentation to the pvUSB header file.
Changes in V2:
- add patch 3
- minor fixes in patch 1
Juergen Gross (3):
include/public: add possible status values to usbif.h
include/public: add better interface description to usbif.h
include/public: fix style of usbif.
The interface definition of PV USB devices is lacking the specification
of possible values of the status field in a response. Those are
negative errno values as used in Linux, so they might differ in other
OS's. Specify them via appropriate defines.
Signed-off-by: Juergen Gross
---
V2:
- add pare
The PV USB protocol is poorly described. Add a more detailed
description to the usbif.h header file.
Signed-off-by: Juergen Gross
---
xen/include/public/io/usbif.h | 164 ++
1 file changed, 164 insertions(+)
diff --git a/xen/include/public/io/usbif.h b/xen/includ
usbif.h is violating the Xen hypervisor coding style. Fix that.
Signed-off-by: Juergen Gross
---
V2:
- new patch (Jan Beulich)
---
xen/include/public/io/usbif.h | 196 +-
1 file changed, 98 insertions(+), 98 deletions(-)
diff --git a/xen/include/public/io/usbif.h
On 28.09.2021 18:32, Luca Fancellu wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -678,6 +678,12 @@ static void __init efi_arch_handle_module(const struct
> file *file,
> efi_bs->FreePool(ptr);
> }
>
> +static int __init efi_arch_check_dt_boot(EFI_FILE_
On 28.09.2021 18:32, Luca Fancellu wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1296,11 +1296,6 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
> *SystemTable)
> {
> read_file(dir_handle, s2w(&name), &kernel, option_str);
> efi_b
On 29.09.2021 09:46, Juergen Gross wrote:
> usbif.h is violating the Xen hypervisor coding style. Fix that.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
On 28.09.2021 23:00, Andrew Cooper wrote:
> The call to debugger_trap_entry() should pass the correct vector. The
> break-for-gdbsx logic is in practice unreachable because PV guests can't
> generate #CP, but it will interfere with anyone inserting custom debugging
> into debugger_trap_entry().
>
On 28.09.2021 23:09, Andrew Cooper wrote:
> On 28/09/2021 21:30, Bobby Eshleman wrote:
>> diff --git a/xen/include/asm-x86/gdbsx.h b/xen/include/asm-x86/gdbsx.h
>> new file mode 100644
>> index 00..473229a7fb
>> --- /dev/null
>> +++ b/xen/include/asm-x86/gdbsx.h
>> @@ -0,0 +1,19 @@
>> +#ifn
Hi Oleksandr,
On 23.09.2021 14:54, 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 value as set
> up by the host bridge in the hardware domain.
> Th
On 29.09.2021 10:13, Michal Orzel wrote:
> On 23.09.2021 14:54, Oleksandr Andrushchenko wrote:
>> @@ -149,6 +172,10 @@ bool vpci_process_pending(struct vcpu *v)
>> if ( !bar->mem )
>> continue;
>>
>> +data.start_gfn = is_hardware_domain(v->vpci.pdev->doma
Hi, Michal!
On 29.09.21 11:13, Michal Orzel wrote:
> Hi Oleksandr,
>
> On 23.09.2021 14:54, 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 value
On 29.09.2021 08:03, Stefano Stabellini wrote:
> That's great, Ian.
>
> Should I go ahead and add the patch to linux-arm-xen? Or do you want to
> do it?
This was only the build flight afaict; we still want to wait for the actual
test to hopefully indicate success.
Jan
On 29.09.21 11:16, Jan Beulich wrote:
> On 29.09.2021 10:13, Michal Orzel wrote:
>> On 23.09.2021 14:54, Oleksandr Andrushchenko wrote:
>>> @@ -149,6 +172,10 @@ bool vpci_process_pending(struct vcpu *v)
>>> if ( !bar->mem )
>>> continue;
>>>
>>> +data
On 28.09.2021 20:18, Rahul Singh wrote:
> prelink.o: In function `pcie_aer_get_firmware_first’:
> drivers/passthrough/pci.c:1251: undefined reference to `apei_hest_parse'
>
> Compilation error is observed when ACPI and HAS_PCI is enabled for ARM
> architecture. APEI not supported on ARM yet move t
On 28.09.2021 20:18, Rahul Singh wrote:
> XEN during boot will read the PCI device tree node “reg” property
> and will map the PCI config space to the XEN memory.
>
> As of now only "pci-host-ecam-generic" compatible board is supported.
>
> "linux,pci-domain" device tree property assigns a fixed
On 29.09.2021 10:24, Oleksandr Andrushchenko wrote:
>
> On 29.09.21 11:16, Jan Beulich wrote:
>> On 29.09.2021 10:13, Michal Orzel wrote:
>>> On 23.09.2021 14:54, Oleksandr Andrushchenko wrote:
@@ -149,6 +172,10 @@ bool vpci_process_pending(struct vcpu *v)
if ( !bar->mem )
[...]
+
+static bool virtio_mem_vmcore_pfn_is_ram(struct vmcore_cb *cb,
+unsigned long pfn)
+{
+ struct virtio_mem *vm = container_of(cb, struct virtio_mem,
+vmcore_cb);
+ uint64_t addr = PFN_PHYS(pfn
How about
return a.mem_type != HVMMEM_mmio_dm;
Ha, how could I have missed that :)
Result should be promoted to int and this has added benefit of not requiring
changes in patch 4.
Can we go one step further and do
@@ -20,24 +20,11 @@ static int xen_oldmem_pfn_is_ram(unsigned lon
pcifront_common_process() has a check at the start that exits early if
pcidev or pdidev->driver are NULL. So simplify the following code by not
checking these two again.
Reviewed-by: Boris Ostrovsky
Reviewed-by: Christoph Hellwig
Signed-off-by: Uwe Kleine-König
---
drivers/pci/xen-pcifront.c |
struct pci_dev::driver contains (apart from a constant offset) the same
data as struct pci_dev::dev->driver. Replace all remaining users of the
former pointer by the latter to allow removing the former.
Reviewed-by: Boris Ostrovsky
Signed-off-by: Uwe Kleine-König
---
arch/powerpc/kernel/eeh_dri
Hello,
this is v5 of the quest to drop the "driver" member from struct pci_dev
which tracks the same data (apart from a constant offset) as dev.driver.
Changes since v4:
- split some changes out of "PCI: replace pci_dev::driver usage that
gets the driver name" and reworked them a bit as sugge
On 29.09.21 11:36, Jan Beulich wrote:
> On 29.09.2021 10:24, Oleksandr Andrushchenko wrote:
>> On 29.09.21 11:16, Jan Beulich wrote:
>>> On 29.09.2021 10:13, Michal Orzel wrote:
On 23.09.2021 14:54, Oleksandr Andrushchenko wrote:
> @@ -149,6 +172,10 @@ bool vpci_process_pending(struct vcp
Hi Jan,
> On 29 Sep 2021, at 9:31 am, Jan Beulich wrote:
>
> On 28.09.2021 20:18, Rahul Singh wrote:
>> XEN during boot will read the PCI device tree node “reg” property
>> and will map the PCI config space to the XEN memory.
>>
>> As of now only "pci-host-ecam-generic" compatible board is supp
Hi, Jan!
Sorry for top posting, but this is a general question on this
patch/functionality.
Do you see we need to gate all this with CONFIG_HAS_VPCI_GUEST_SUPPORT
as this renders in somewhat dead code for x86 for now? I do think this still
needs to be in the common code though.
Thank you in a
On 29.09.21 10:45, David Hildenbrand wrote:
How about
return a.mem_type != HVMMEM_mmio_dm;
Ha, how could I have missed that :)
Result should be promoted to int and this has added benefit of not requiring
changes in patch 4.
Can we go one step further and do
@@ -20,24 +20,11 @@
On 29.09.2021 11:03, Oleksandr Andrushchenko wrote:
> Sorry for top posting, but this is a general question on this
> patch/functionality.
>
> Do you see we need to gate all this with CONFIG_HAS_VPCI_GUEST_SUPPORT
> as this renders in somewhat dead code for x86 for now? I do think this still
> ne
On 23.09.2021 14:54, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Emulate guest BAR register values: this allows creating a guest view
> of the registers and emulates size and properties probe as it is done
> during PCI device enumeration by the guest.
>
> ROM BAR is onl
Hi Jan,
> On 29 Sep 2021, at 9:24 am, Jan Beulich wrote:
>
> On 28.09.2021 20:18, Rahul Singh wrote:
>> prelink.o: In function `pcie_aer_get_firmware_first’:
>> drivers/passthrough/pci.c:1251: undefined reference to `apei_hest_parse'
>>
>> Compilation error is observed when ACPI and HAS_PCI is
On 23.09.2021 14:54, 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 of hooks so vPCI can handle
> that.
>
> Please note, that in the current design the e
Having played with '0' for PVH quite a bit lately, it just so happened
that I also tried it with PV, finding that it has been broken for quite
some time.
1: make '0' debug key dump Dom0's stacks again
2: replace assertions in '0' debug key stack dumping
3: drop "vcpu" local variable from show_gues
The conversion to __get_guest() failed to account for the fact that for
remote vCPU-s dumping gets done through a pointer obtained from
map_domain_page(): __get_guest() arranges for (apparent) accesses to
hypervisor space to cause #GP(0).
Fixes: 6a1d72d3739e ('x86: split __{get,put}_user() into "g
While it was me to add them, I'm afraid I don't see justification for
the assertions: A vCPU may very well have got preempted while in user
mode. Limit compat guest user mode stack dumps to the containing page
(like is done when using do_page_walk()), and suppress their dumping
altogether for 64-bi
It's not really needed and has been misleading me more than once to try
and spot its "actual" use(s). It should really have been dropped when
the 32-bit specific logic was purged from here.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -327,16 +327,13 @@ sta
Currently, osstest is not working. We have lost one of our PDUs,
meaning that about half a rack is out of action, including one of the
VM hosts.
There has been quite a bit of outstanding maintenance which has been
deferred due to the pandemic. I am trying to see if we can get
someone on-site to
> On Tue, 28 Sep 2021, Luca Fancellu wrote:
>> Introduce the uefi,cfg-load DT property of /chosen
>> node for ARM whose presence decide whether to force
>> the load of the UEFI Xen configuration file.
>>
>> The logic is that if any multiboot,module is found in
>> the DT, then the uefi,cfg-load pro
> On Tue, 28 Sep 2021, Luca Fancellu wrote:
>> Add support to load Dom0 boot modules from
>> the device tree using the uefi,binary property.
>>
>> Update documentation about that.
>>
>> Signed-off-by: Luca Fancellu
>
> It is great how simple this patch is!
>
> The patch looks all correct. Only
On 22.09.2021 13:59, Roger Pau Monné wrote:
> On Tue, Sep 21, 2021 at 09:16:44AM +0200, Jan Beulich wrote:
>> @@ -337,18 +337,23 @@ unsigned long __init dom0_compute_nr_pag
>> avail -= d->max_vcpus - 1;
>>
>> /* Reserve memory for iommu_dom0_init() (rough estimate). */
>> -if (
> On 29 Sep 2021, at 09:00, Jan Beulich wrote:
>
> On 28.09.2021 18:32, Luca Fancellu wrote:
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -1296,11 +1296,6 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
>> *SystemTable)
>> {
>> read_file(dir_ha
> On 29 Sep 2021, at 08:50, Jan Beulich wrote:
>
> On 28.09.2021 18:32, Luca Fancellu wrote:
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -678,6 +678,12 @@ static void __init efi_arch_handle_module(const struct
>> file *file,
>> efi_bs->FreePool(ptr);
>>
On 29.09.2021 13:30, Luca Fancellu wrote:
>
>
>> On 29 Sep 2021, at 08:50, Jan Beulich wrote:
>>
>> On 28.09.2021 18:32, Luca Fancellu wrote:
>>> --- a/xen/arch/x86/efi/efi-boot.h
>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>> @@ -678,6 +678,12 @@ static void __init efi_arch_handle_module(const struc
On 29.09.21 12:09, Jan Beulich wrote:
> On 29.09.2021 11:03, Oleksandr Andrushchenko wrote:
>> Sorry for top posting, but this is a general question on this
>> patch/functionality.
>>
>> Do you see we need to gate all this with CONFIG_HAS_VPCI_GUEST_SUPPORT
>> as this renders in somewhat dead cod
This regex is used for auto-balloon mode detection based on Xen command line.
The case of specifying a negative size was handled incorrectly.
>From misc/xen-command-line documentation:
dom0_mem (x86)
= List of ( min: | max: | )
If a size is positive, it represents an absolute value.
Modern hardware may report more than 48 bits of physical address width.
For paging-external guests our P2M implementation does not cope with
larger values. Telling the guest of more available bits means misleading
it into perhaps trying to actually put some page there (like was e.g.
intermediately
On 29.09.2021 13:56, Oleksandr Andrushchenko wrote:
>
> On 29.09.21 12:09, Jan Beulich wrote:
>> On 29.09.2021 11:03, Oleksandr Andrushchenko wrote:
>>> Sorry for top posting, but this is a general question on this
>>> patch/functionality.
>>>
>>> Do you see we need to gate all this with CONFIG_H
In the course of fixing XSA-378 fallout I ran into a number of
issues, the remaining parts of which this series is trying to deal
with. The majority of the changes is pretty much independent of
one another.
There was another rather basic issue to fight first (patch
was submitted separately as RFC)
Assuming that the accounting for IOMMU page tables will also take care
of the P2M needs was wrong: dom0_paging_pages() can determine a far
higher value, high enough for the system to run out of memory while
setting up Dom0. Hence in the case of shared page tables the larger of
the two values needs
Leaving shadow setup just to the L1TF tasklet means running Dom0 on a
minimally acceptable shadow memory pool, rather than what normally
would be used (also, for example, for PVH). Populate the pool before
triggering the tasklet (or in preparation for L1TF checking logic to
trigger it), on a best e
Certain notifications of Dom0 to Xen are independent of the mode Dom0 is
running in. Permit further PCI related ones (only their modern forms).
Also include the USB2 debug port operation at this occasion.
Signed-off-by: Jan Beulich
---
I'm uncertain about the has_vpci() part of the check: I would
Wire up show_hvm_stack() also on this path. Move the show_guest_stack()
invocation out of show_stack(), rendering dead the is-HVM check there.
While separating guest and host paths, also move the show_code()
invocation - the function bails immediately when guest_mode() returns
"true".
Signed-off-
There's not really any register state associated with vCPU-s that
haven't been initialized yet, so avoid spamming the log with largely
useless information while still leaving an indication of the fact.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v4: Key off of v->is_initialised.
To become independent of the sequence of mapping operations, permit
"access" to accumulate for Dom0, noting that there's not going to be an
introspection agent for it which this might interfere with. While e.g.
ideally only ROM regions would get mapped with X set, getting there is
quite a bit of wo
On 29.09.21 15:54, Jan Beulich wrote:
> On 29.09.2021 13:56, Oleksandr Andrushchenko wrote:
>> On 29.09.21 12:09, Jan Beulich wrote:
>>> On 29.09.2021 11:03, Oleksandr Andrushchenko wrote:
Sorry for top posting, but this is a general question on this
patch/functionality.
Do yo
On 29/9/21 6:53 pm, Uwe Kleine-König wrote:>
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
- if (afu_dev->driver && afu_dev->driver->err_handler &&
- afu_dev->driver->err_handler->resume)
- afu_d
On 29.09.2021 15:16, Oleksandr Andrushchenko wrote:
>
> On 29.09.21 15:54, Jan Beulich wrote:
>> On 29.09.2021 13:56, Oleksandr Andrushchenko wrote:
>>> On 29.09.21 12:09, Jan Beulich wrote:
On 29.09.2021 11:03, Oleksandr Andrushchenko wrote:
> Sorry for top posting, but this is a general
On 27.09.2021 00:53, Elliott Mitchell wrote:
> Getting everything right to recreate is rather inexact. Having an
> equivalent of `sysctl` to turn on the serial console while running might
> be handy...
>
> Luckily get things together and...
Thanks; finally got around to look at this in at least
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> Implement generic pci access functions to read/write the configuration
> space.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> Change in v3:
> - Remove PRI_pci as not used.
> - Replace uint32_
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> From: Oleksandr Andrushchenko
>
> Add support for Xilinx ZynqMP PCI host controller to map the PCI config
> space to the XEN memory.
>
> Patch helps to understand how the generic infrastructure for PCI
> host-bridge discovery will b
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> This patch will be reverted once we add support for VPCI MSI/MSIX
> support on ARM.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> Change in v3: none
> Change in v2: Patch introduced in v2
> -
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> libxl will create an emulated PCI device tree node in the device tree to
> enable the guest OS to discover the virtual PCI during guest boot.
> Emulated PCI device tree node will only be created when there is any
> device assigned to g
Hi Rahul,
> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>
> If the property is not present in the device tree node for host bridge,
> XEN while creating the dtb for hwdom will create this property and
> assigns the already allocated segment to the host bridge
> so that XEN and linux will have t
On Wed, Sep 29, 2021 at 11:15:37PM +1000, Andrew Donnellan wrote:
> On 29/9/21 6:53 pm, Uwe Kleine-König wrote:>
> list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
> > - if (afu_dev->driver && afu_dev->driver->err_handler &&
> > - a
On 29.09.21 16:23, Jan Beulich wrote:
> On 29.09.2021 15:16, Oleksandr Andrushchenko wrote:
>> On 29.09.21 15:54, Jan Beulich wrote:
>>> On 29.09.2021 13:56, Oleksandr Andrushchenko wrote:
On 29.09.21 12:09, Jan Beulich wrote:
> On 29.09.2021 11:03, Oleksandr Andrushchenko wrote:
>>
On 29.09.2021 15:49, Oleksandr Andrushchenko wrote:
>
>
> On 29.09.21 16:23, Jan Beulich wrote:
>> On 29.09.2021 15:16, Oleksandr Andrushchenko wrote:
>>> On 29.09.21 15:54, Jan Beulich wrote:
On 29.09.2021 13:56, Oleksandr Andrushchenko wrote:
> On 29.09.21 12:09, Jan Beulich wrote:
>>>
On 29.09.21 17:07, Jan Beulich wrote:
> On 29.09.2021 15:49, Oleksandr Andrushchenko wrote:
>>
>> On 29.09.21 16:23, Jan Beulich wrote:
>>> On 29.09.2021 15:16, Oleksandr Andrushchenko wrote:
On 29.09.21 15:54, Jan Beulich wrote:
> On 29.09.2021 13:56, Oleksandr Andrushchenko wrote:
On 29.09.21 16:38, Bertrand Marquis wrote:
> Hi Rahul,
>
>> On 28 Sep 2021, at 19:18, Rahul Singh wrote:
>>
>> From: Oleksandr Andrushchenko
>>
>> Add support for Xilinx ZynqMP PCI host controller to map the PCI config
>> space to the XEN memory.
>>
>> Patch helps to understand how the generic
Anthony PERARD writes ("[XEN PATCH v2] build: add --full to version.sh to guess
$(XEN_FULLVERSION)"):
> Running $(MAKE) like that in a $(shell ) while parsing the Makefile
> doesn't work reliably. In some case, make will complain with
> "jobserver unavailable: using -j1. Add '+' to parent make ru
On 9/29/21 5:03 AM, David Hildenbrand wrote:
> On 29.09.21 10:45, David Hildenbrand wrote:
>>>
>> Can we go one step further and do
>>
>>
>> @@ -20,24 +20,11 @@ static int xen_oldmem_pfn_is_ram(unsigned long pfn)
>> struct xen_hvm_get_mem_type a = {
>> .domid = DOMID_S
On 29.09.21 16:22, Boris Ostrovsky wrote:
On 9/29/21 5:03 AM, David Hildenbrand wrote:
On 29.09.21 10:45, David Hildenbrand wrote:
Can we go one step further and do
@@ -20,24 +20,11 @@ static int xen_oldmem_pfn_is_ram(unsigned long pfn)
struct xen_hvm_get_mem_type a = {
On Wed, Sep 29, 2021 at 03:32:15PM +0200, Jan Beulich wrote:
> On 27.09.2021 00:53, Elliott Mitchell wrote:
> > (XEN) Xen call trace:
> > (XEN)[] R
> > arch/x86/mm/p2m.c#p2m_flush_table+0x240/0x260
> > (XEN)[] S p2m_flush_nestedp2m+0x1c/0x30
> > (XEN)[] S
> > arch/x86/mm/hap/hap.c#hap
On 29/9/21 11:43 pm, Uwe Kleine-König wrote:> I'm not a huge fan either,
I used it to keep the control flow as is and
without introducing several calls to to_pci_driver.
The whole code looks as follows:
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
st
On Wed, 29 Sep 2021, Luca Fancellu wrote:
> > On Tue, 28 Sep 2021, Luca Fancellu wrote:
> >> Introduce the uefi,cfg-load DT property of /chosen
> >> node for ARM whose presence decide whether to force
> >> the load of the UEFI Xen configuration file.
> >>
> >> The logic is that if any multiboot,mo
On Tue, 28 Sep 2021, Rahul Singh wrote:
> XEN during boot will read the PCI device tree node “reg” property
> and will map the PCI config space to the XEN memory.
>
> As of now only "pci-host-ecam-generic" compatible board is supported.
>
> "linux,pci-domain" device tree property assigns a fixed
On Tue, 28 Sep 2021, Rahul Singh wrote:
> From: Oleksandr Andrushchenko
>
> Add support for Xilinx ZynqMP PCI host controller to map the PCI config
> space to the XEN memory.
>
> Patch helps to understand how the generic infrastructure for PCI
> host-bridge discovery will be used for future refe
On Tue, 28 Sep 2021, Rahul Singh wrote:
> Implement generic pci access functions to read/write the configuration
> space.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Stefano Stabellini
> ---
> Change in v3:
> - Remove PRI_pci as not used.
> - Replace uint32_t sbdf to pci_sbdf_t sbdf to avoid
On Tue, 28 Sep 2021, 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_add”, VPCI handler for the config space
> access is added to the Xen to emulate the PCI devices config space.
>
> A
On Tue, 28 Sep 2021, Rahul Singh wrote:
> This patch will be reverted once we add support for VPCI MSI/MSIX
> support on ARM.
>
> Signed-off-by: Rahul Singh
Acked-by: Stefano Stabellini
> ---
> Change in v3: none
> Change in v2: Patch introduced in v2
> ---
> xen/drivers/vpci/Makefile | 3 ++
On Tue, 28 Sep 2021, Rahul Singh wrote:
> libxl will create an emulated PCI device tree node in the device tree to
> enable the guest OS to discover the virtual PCI during guest boot.
> Emulated PCI device tree node will only be created when there is any
> device assigned to guest.
>
> A new area
On Tue, 28 Sep 2021, Rahul Singh wrote:
> If the property is not present in the device tree node for host bridge,
> XEN while creating the dtb for hwdom will create this property and
> assigns the already allocated segment to the host bridge
> so that XEN and linux will have the same segment for th
On Tue, 28 Sep 2021, Rahul Singh wrote:
> On Arm, the initial plan is to only support GICv3 ITS which doesn't
> require us to manage the MSIs because the HW will protect against
> spoofing. Move the code under CONFIG_HAS_PCI_MSI flag to gate the code
> for ARM.
>
> No functional change intended.
>
Ian Jackson writes ("osstest down, PDU failure"):
> Currently, osstest is not working. We have lost one of our PDUs,
> meaning that about half a rack is out of action, including one of the
> VM hosts.
>
> There has been quite a bit of outstanding maintenance which has been
> deferred due to the p
Ian Jackson writes ("Re: [xen-unstable test] 164996: regressions - FAIL"):
> Thanks. The attachment didn't git-am but I managed to make a tree
> with it in (but a bogus commit message).
>
> I have a repro of 165218 test-arm64-arm64-libvirt-raw (that's the last
> xen-unstable flight) running. If
[adhoc adhoc]
harness 3a3089c9: mfi-common: Drop Linux dom0 i386 tests for newer Lin...
165323: all pass
flight 165323 xen-unstable adhoc [adhoc]
http://logs.test-lab.xenproject.org/osstest/logs/165323/
Perfect :-)
All tests in this flight passed as required
jobs:
build-arm64-pvops
From: Oleksandr Tyshchenko
We need to pass info about maximum supported guest address
space size to the toolstack on Arm in order to properly
calculate the base and size of the extended region (safe range)
for the guest. The extended region is unused address space which
could be safely used by do
From: Oleksandr Tyshchenko
You can find an initial discussion at [1]-[4].
The extended region (safe range) is a region of guest physical address space
which is unused and could be safely used to create grant/foreign mappings
instead
of wasting real RAM pages from the domain memory for establish
From: Oleksandr Tyshchenko
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings instead of wasting real RAM pages from
the domain memory for establishing these mappings.
The extended regions are cho
From: Oleksandr Tyshchenko
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings instead of wasting real RAM pages from
the domain memory for establishing these mappings.
The extended regions are cho
flight 165317 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165317/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
1 - 100 of 103 matches
Mail list logo
