flight 152186 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152186/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 91e4bcb313f0c1f0f19b87b5849f5486aa076be4
baseline version:
ovmf 50528537b2fb0ebdf32c7
From: Andrea Righi
Date: Fri, 24 Jul 2020 10:59:10 +0200
> There's a potential race in xennet_remove(); this is what the driver is
> doing upon unregistering a network device:
>
> 1. state = read bus state
> 2. if state is not "Closed":
> 3.request to set state to "Closing"
> 4.w
flight 152171 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152171/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 151065
test-amd64-i386-x
On Fri, 24 Jul 2020, Julien Grall wrote:
> On Fri, 24 Jul 2020 at 19:32, Stefano Stabellini
> wrote:
> > > If they are not equal, then I fail to see why it would be useful to have
> > > this
> > > value in Xen.
> >
> > I think that's because the domain is actually more convenient to use
> > beca
On Thu, 23 Jul 2020, Anchal Agarwal wrote:
> On Wed, Jul 22, 2020 at 04:49:16PM -0700, Stefano Stabellini wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> > the content is safe.
> >
flight 152175 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152175/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 50528537b2fb0ebdf32c719a0525635c93b905c2
baseline version:
ovmf e43d0884ed93ffd8044e4
On Fri, 24 Jul 2020 at 19:32, Stefano Stabellini wrote:
> > If they are not equal, then I fail to see why it would be useful to have
> > this
> > value in Xen.
>
> I think that's because the domain is actually more convenient to use
> because a segment can span multiple PCI host bridges. So my
>
On 24/07/2020 17:46, Paul Durrant wrote:
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index 6a3803ff2c..5bc190bf98 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -535,12 +535,12 @@ static void iommu_dump_p2m_table(un
flight 152180 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152180/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 24/07/2020 17:46, Paul Durrant wrote:
> From: Paul Durrant
>
> Sharing of HAP tables is VT-d specific so the operation is never defined for
> AMD IOMMU.
It's not VT-d specific, and Xen really did used to share on AMD.
In fact, a remnant of this logic is still present in the form of the
commen
> -Original Message-
> From: Andrew Cooper
> Sent: 24 July 2020 19:39
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Kevin Tian ;
> Jan Beulich
>
> Subject: Re: [PATCH 3/6] iommu: remove iommu_lookup_page() and the
> lookup_page() method...
>
> On 24/07/2020 1
> -Original Message-
> From: Andrew Cooper
> Sent: 24 July 2020 18:29
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Lukasz Hawrylko
> ; Jan Beulich
> ; Wei Liu ; Roger Pau Monné
> ; Kevin Tian
>
> Subject: Re: [PATCH 1/6] x86/iommu: re-arrange arch_iommu to se
On 24/07/2020 17:46, Paul Durrant wrote:
> From: Paul Durrant
>
> ... from iommu_ops.
>
> This patch is essentially a reversion of dd93d54f "vtd: add lookup_page method
> to iommu_ops". The code was intended to be used by a patch that has long-
> since been abandoned. Therefore it is dead code and
On Fri, 24 Jul 2020, Julien Grall wrote:
> On 24/07/2020 18:41, Stefano Stabellini wrote:
> > On Fri, 24 Jul 2020, Julien Grall wrote:
> > > On 24/07/2020 00:38, Stefano Stabellini wrote:
> > > The segment number is just a value defined by the software. So as long as
> > > Linux and Xen agrees with
On 24/07/2020 17:46, Paul Durrant wrote:
> From: Paul Durrant
>
> Instead of having separate page table allocation functions in VT-d and AMD
> IOMMU code, use a common allocation function in the general x86 code.
> Also, rather than walking the page tables and using a tasklet to free them
> during
On 24/07/2020 18:41, Stefano Stabellini wrote:
On Fri, 24 Jul 2020, Julien Grall wrote:
On 24/07/2020 00:38, Stefano Stabellini wrote:
The segment number is just a value defined by the software. So as long as
Linux and Xen agrees with the number, then we should be ok.
As far as I understand
On Fri, 24 Jul 2020, Julien Grall wrote:
> > > > +list_add_tail(&bridge->node, &pci_host_bridges);
> > > It looks like &pci_host_bridges should be an ordered list, ordered by
> > > segment number?
> >
> > Why? Do you expect bridge access in some specific order so ordered
> >
> > list will mak
On Fri, 24 Jul 2020, Julien Grall wrote:
> On 24/07/2020 00:38, Stefano Stabellini wrote:
> > > +bridge->dt_node = dev;
> > > +bridge->sysdata = cfg;
> > > +bridge->ops = &ops->pci_ops;
> > > +
> > > +if( !dt_property_read_u32(dev, "linux,pci-domain", &segment) )
> > > +{
> > >
Run each host's report in a separate child. This is considerably
faster.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 47 +++---
1 file changed, 40 insertions(+), 7 deletions(-)
diff --git a/sg-report-host-history b/sg-report-host-history
index 78
This condition is the same as $flightcond. (This has no effect on the
db performance since the query planner figures it out, but it is
confusing.)
Signed-off-by: Ian Jackson
---
sg-report-host-history | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sg-report-host-history b
On 24/07/2020 17:46, Paul Durrant wrote:
> diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
> index 6c9d5e5632..a7add5208c 100644
> --- a/xen/include/asm-x86/iommu.h
> +++ b/xen/include/asm-x86/iommu.h
> @@ -45,16 +45,23 @@ typedef uint64_t daddr_t;
>
> struct arch_iommu
>
On 24/07/2020 16:01, Srinivas Bangalore wrote:
Hi Julien,
Hello,
Thanks for the tips. Comments inline...
I struggled to find your comment inline as your e-mail client doesn't
quote my answer. Please configure your e-mail client to use some form of
quoting (the usual is '>').
Here'
Perhaps at one point something read from these logs influenced the db
query for thye flights range, but that is no longer the case and it
doesn't seem likely to need to come back.
We want to move the per-host stuff together.
No functional change.
Signed-off-by: Ian Jackson
---
sg-report-host-h
This moves the loop over hosts into the main program. We are working
our way to a new code structure.
No functional change.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/sg-report-host-history b/sg
Move the per-host code all into the same per-host loop. One effect is
to transpose the db_retry and host loops for mainquery.
No functional change.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/sg-report-
In f6001d628c3b3fd42b10cd15351981a04bc02572 we combined these
queries into one:
sg-report-host-history: Aggregate runvars query for all hosts
Now that we have an index, there is a faster way for the db to do this
query: via that index. But it doesn't like to do that if be aggregate
the queries.
This is reasonably straightforward.
In my tests it reduces the time for an incremental run, with a hot
cache, from several hundred seconds to a handful of seconds.
This series really wants to go after the flight report improvements,
although the schema updates could be combined.
Ian Jackson (11)
By default we look for anything in (roughly) the last year.
This query is in fact quite fast because the flights table is small.
There is still the per-host limit of $limit (2000) recent runs.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 56 --
sg-report-host-history is going to want this in a moment
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 33de3708..c1095bac 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Ex
This helps rule this sort out as a source of slowness.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sg-report-host-history b/sg-report-host-history
index 8b409fc7..25a0c847 100755
--- a/sg-report-host-history
+++ b/sg-report-host-his
This printing has a significant effect on the performance of this
program, at least after we optimise various other things.
Signed-off-by: Ian Jackson
---
sg-report-host-history | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/sg-report-host-history b/sg-report-
Signed-off-by: Ian Jackson
---
schema/runvars-host-index.sql | 8
1 file changed, 8 insertions(+)
create mode 100644 schema/runvars-host-index.sql
diff --git a/schema/runvars-host-index.sql b/schema/runvars-host-index.sql
new file mode 100644
index ..fec0b960
--- /dev/null
+++
flight 152162 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152162/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which did no
Hi Jan,
On 24/07/2020 17:01, Jan Beulich wrote:
On 24.07.2020 17:15, Julien Grall wrote:
On 24/07/2020 15:44, Roger Pau Monné wrote:
+
+struct pci_host_bridge *bridge = pci_find_host_bridge(sbdf.seg, sbdf.bus);
+
+if ( unlikely(!bridge) )
+{
+printk(XENLOG_ERR "Unable to fi
From: Paul Durrant
It's confusing and not consistent with the terminology introduced with 'dfn_t'.
Just call them IOMMU page tables.
Also remove a pointless check of the 'acpi_drhd_units' list in
vtd_dump_page_table_level(). If the list is empty then IOMMU mappings would
not have been enabled fo
From: Paul Durrant
The 'legacy' functions do implicit flushing so amend the callers to do the
appropriate flushing.
Unfortunately, because of the structure of the P2M code, we cannot remove
the per-CPU 'iommu_dont_flush_iotlb' global and the optimization it
facilitates. It is now checked directl
From: Paul Durrant
Sharing of HAP tables is VT-d specific so the operation is never defined for
AMD IOMMU. There's also no need to pro-actively set vtd.pgd_maddr when using
shared EPT as it is straightforward to simply define a helper function to
return the appropriate value in the shared and non
From: Paul Durrant
Instead of having separate page table allocation functions in VT-d and AMD
IOMMU code, use a common allocation function in the general x86 code.
Also, rather than walking the page tables and using a tasklet to free them
during iommu_domain_destroy(), add allocated page table pa
From: Paul Durrant
... from iommu_ops.
This patch is essentially a reversion of dd93d54f "vtd: add lookup_page method
to iommu_ops". The code was intended to be used by a patch that has long-
since been abandoned. Therefore it is dead code and can be removed.
Signed-off-by: Paul Durrant
---
Cc
From: Paul Durrant
Patches accumulated in my during 4.14 freeze...
Paul Durrant (6):
x86/iommu: re-arrange arch_iommu to separate common fields...
x86/iommu: add common page-table allocator
iommu: remove iommu_lookup_page() and the lookup_page() method...
remove remaining uses of iommu_l
From: Paul Durrant
... from those specific to VT-d or AMD IOMMU, and put the latter in a union.
There is no functional change in this patch, although the initialization of
the 'mapped_rmrrs' list occurs slightly later in iommu_domain_init() since
it is now done (correctly) in VT-d specific code
On 7/24/20 10:34 AM, David Hildenbrand wrote:
> CCing Dan
>
> On 24.07.20 14:42, Roger Pau Monne wrote:
>> diff --git a/drivers/xen/unpopulated-alloc.c
>> b/drivers/xen/unpopulated-alloc.c
>> new file mode 100644
>> index ..aaa91cefbbf9
>> --- /dev/null
>> +++ b/drivers/xen/unpopulated
Dear community members,
I'm pleased to announce that Xen 4.14.0 is released.
Please find the tarball and its signature at:
https://downloads.xenproject.org/release/xen/4.14.0
Git checkout and build instructions can be found at:
https://wiki.xenproject.org/wiki/Xen_Project_4.14_Release_Not
On 24.07.2020 17:15, Julien Grall wrote:
> On 24/07/2020 15:44, Roger Pau Monné wrote:
>>> +
>>> +struct pci_host_bridge *bridge = pci_find_host_bridge(sbdf.seg,
>>> sbdf.bus);
>>> +
>>> +if ( unlikely(!bridge) )
>>> +{
>>> +printk(XENLOG_ERR "Unable to find bridge for "PRI_pci
On 24/07/2020 16:29, Roger Pau Monné wrote:
On Fri, Jul 24, 2020 at 04:15:47PM +0100, Julien Grall wrote:
On 24/07/2020 15:44, Roger Pau Monné wrote:
diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
new file mode 100644
index 00..358508b787
--- /dev/null
+++ b/xen
On Fri, Jul 24, 2020 at 05:29:05PM +0200, Roger Pau Monné wrote:
> On Fri, Jul 24, 2020 at 04:15:47PM +0100, Julien Grall wrote:
> >
> >
> > On 24/07/2020 15:44, Roger Pau Monné wrote:
> > > > +
> > > > +if ( acpi_disabled )
> > > > +dt_pci_init();
> > > > +else
> > > > +a
On Fri, Jul 24, 2020 at 04:15:47PM +0100, Julien Grall wrote:
>
>
> On 24/07/2020 15:44, Roger Pau Monné wrote:
> > > diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
> > > new file mode 100644
> > > index 00..358508b787
> > > --- /dev/null
> > > +++ b/xen/arch/arm/pci/M
On 24/07/2020 15:44, Roger Pau Monné wrote:
diff --git a/xen/arch/arm/pci/Makefile b/xen/arch/arm/pci/Makefile
new file mode 100644
index 00..358508b787
--- /dev/null
+++ b/xen/arch/arm/pci/Makefile
@@ -0,0 +1,4 @@
+obj-y += pci.o
+obj-y += pci-host-generic.o
+obj-y += pci-host-common.
On Thu, Jul 23, 2020 at 04:40:23PM +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_add”, VPCI handler for the config space
> access is added to the PCI device to emulate the PCI
On Thu, Jul 23, 2020 at 01:44:03PM -0700, Stefano Stabellini wrote:
> On Thu, 23 Jul 2020, 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 P
On Thu, Jul 23, 2020 at 04:40:21PM +0100, 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.
>
> XEN will read the “linux, pci-domain” property from the device tree
> node and configure the host bridge segme
flight 152173 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152173/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
CCing Dan
On 24.07.20 14:42, Roger Pau Monne wrote:
> To be used in order to create foreign mappings. This is based on the
> ZONE_DEVICE facility which is used by persistent memory devices in
> order to create struct pages and kernel virtual mappings for the IOMEM
> areas of such devices. Note tha
On 24.07.20 14:42, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels with
On 24.07.2020 14:11, Andrew Cooper wrote:
> On 17/07/2020 14:10, Jan Beulich wrote:
>> Since we intercept RTC/CMOS port accesses, let's do so consistently in
>> all cases, i.e. also for e.g. a dword access to [006E,0071]. To avoid
>> the risk of unintended impact on Dom0 code actually doing so (des
On 24.07.20 14:42, Roger Pau Monne wrote:
This reverts commit dfd74a1edfaba5864276a2859190a8d242d18952.
This has been fixed by commit dca4436d1cf9e0d237c which added the out
of bounds check to __add_memory, so that trying to add blocks past
MAX_PHYSMEM_BITS will fail.
Note the check in the Xen
On 24.07.20 14:42, Roger Pau Monne wrote:
So it can be killed, or else processes can get hung indefinitely
waiting for balloon pages.
Signed-off-by: Roger Pau Monné
Reviewed-by: Juergen Gross
Juergen
On 24.07.20 14:42, Roger Pau Monne wrote:
target_unpopulated is incremented with nr_pages at the start of the
function, but the call to free_xenballooned_pages will only subtract
pgno number of pages, and thus the rest need to be subtracted before
returning or else accounting will be skewed.
Sig
flight 152167 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152167/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallbac
target_unpopulated is incremented with nr_pages at the start of the
function, but the call to free_xenballooned_pages will only subtract
pgno number of pages, and thus the rest need to be subtracted before
returning or else accounting will be skewed.
Signed-off-by: Roger Pau Monné
Cc: sta...@vger
Hello,
The following series contain some fixes in order to split Xen
unpopulated memory handling from the ballooning driver if ZONE_DEVICE is
available, so that physical memory regions used to map foreign pages are
not tied to memory hotplug.
Fix two patches are bugfixes that IMO should be backpo
So it can be killed, or else processes can get hung indefinitely
waiting for balloon pages.
Signed-off-by: Roger Pau Monné
Cc: sta...@vger.kernel.org
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
---
drivers/xen/balloon.c | 6 --
1 fil
This reverts commit dfd74a1edfaba5864276a2859190a8d242d18952.
This has been fixed by commit dca4436d1cf9e0d237c which added the out
of bounds check to __add_memory, so that trying to add blocks past
MAX_PHYSMEM_BITS will fail.
Note the check in the Xen balloon driver was bogus anyway, as it
check
On 17/07/2020 14:10, Jan Beulich wrote:
> Since we intercept RTC/CMOS port accesses, let's do so consistently in
> all cases, i.e. also for e.g. a dword access to [006E,0071]. To avoid
> the risk of unintended impact on Dom0 code actually doing so (despite
> the belief that none ought to exist), al
Hello, and thanks for the response.
El vie., 24 jul. 2020 a las 12:45, Julien Grall () escribió:
> > I'm trying Xen 4.13.1 in a Allwinner H6 SoC (more precisely a Pine H64
> > model B, with a ARM Cortex-A53 CPU).
> > I managed to get a dom0 Linux 5.8-rc5 kernel running fine, unpatched,
> > and I'm
On 24/07/2020 12:17, Amit Tomer wrote:
Hi,
Hi,
I remember this discussion. The problem was that the PMU is using
per-CPU interrupts. Xen is not yet able to handle PPIs as they often
requires more context to be saved/restored (in this case the PMU context).
There was a proposal to look if
Hi,
> I remember this discussion. The problem was that the PMU is using
> per-CPU interrupts. Xen is not yet able to handle PPIs as they often
> requires more context to be saved/restored (in this case the PMU context).
>
> There was a proposal to look if a device is using PPIs and just remove
> t
(+ Andre and Stefano)
On 20/07/2020 15:53, Alejandro wrote:
Hello all.
Hello,
I'm new to this community, and firstly I'd like to thank you all for
your efforts on supporting Xen in ARM devices.
Welcome to the community!
I'm trying Xen 4.13.1 in a Allwinner H6 SoC (more precisely a Pine
On Wed, Jul 22, 2020 at 09:47:43AM -0700, Stefano Stabellini wrote:
> On Tue, 21 Jul 2020, Brian Woods wrote:
> > Modify the smmu driver so that it uses the iommu_fwspec helper
> > functions. This means both ARM IOMMU drivers will both use the
> > iommu_fwspec helper functions.
> >
> > Signed-off
flight 152157 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152157/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e43d0884ed93ffd8044e48e8d5d2d010a46aab33
baseline version:
ovmf 3d2f7953b2ba9d27b1905
flight 152153 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152153/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 152081
Tests which did not suc
Hi,
On 24/07/2020 00:39, Stefano Stabellini wrote:
On Thu, 23 Jul 2020, Rahul Singh wrote:
+if (res) return res;
+
+/*
+ * Legacy interrupt is forced and assigned to the guest.
+ * This will be removed once we have implementation for MSI support.
+ *
+ */
+res = fdt_
There's a potential race in xennet_remove(); this is what the driver is
doing upon unregistering a network device:
1. state = read bus state
2. if state is not "Closed":
3.request to set state to "Closing"
4.wait for state to be set to "Closing"
5.request to set state to "Clo
Hi,
On 24/07/2020 00:38, Stefano Stabellini wrote:
+bridge->dt_node = dev;
+bridge->sysdata = cfg;
+bridge->ops = &ops->pci_ops;
+
+if( !dt_property_read_u32(dev, "linux,pci-domain", &segment) )
+{
+printk(XENLOG_ERR "\"linux,pci-domain\" property in not available in
Hi Rahul,
On 23/07/2020 16:40, 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.
XEN will read the “linux, pci-domain” property from the device tree
node and configure the host bridge segment number accordin
Hi,
On 24/07/2020 08:14, Oleksandr Andrushchenko wrote:
On 7/23/20 11:44 PM, Stefano Stabellini wrote:
On Thu, 23 Jul 2020, 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_
Hi,
On 24/07/2020 08:03, Oleksandr Andrushchenko wrote:
diff --git a/xen/arch/arm/pci/pci-access.c b/xen/arch/arm/pci/pci-access.c
new file mode 100644
index 00..c53ef58336
--- /dev/null
+++ b/xen/arch/arm/pci/pci-access.c
@@ -0,0 +1,101 @@
+/*
+ * Copyright (C) 2020 Arm Ltd.
I think SP
On 7/24/20 2:39 AM, Stefano Stabellini wrote:
> On Thu, 23 Jul 2020, 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.
>>
>> We introduced the new config option [vpci="ecam"] for g
On Thu 23-07-20 19:39:54, David Hildenbrand wrote:
[...]
> Yeah, might require some code churn. It just feels wrong to involve
> buddy concepts (e.g., onlining pages, calling memory notifiers, exposing
> memory block devices) and introducing hacks (forced onlining) just to
> get a memmap+identity m
On 23.07.2020 20:26, Andrew Cooper wrote:
> The current HVM default for writes to unknown MSRs is to inject #GP if the MSR
> is unreadable, and discard writes otherwise. While this behaviour isn't great,
> the PV default is even worse, because it swallows writes even to non-readable
> MSRs. i.e. A
On 7/23/20 11:44 PM, Stefano Stabellini wrote:
> On Thu, 23 Jul 2020, 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.
>>
>
On 7/24/20 2:38 AM, Stefano Stabellini wrote:
> + Jan, Andrew, Roger
>
> Please have a look at my comment on whether we should share the MMCFG
> code below, feel free to ignore the rest :-)
>
>
> On Thu, 23 Jul 2020, Rahul Singh wrote:
>> XEN during boot will read the PCI device tree node “reg” pr
83 matches
Mail list logo
