In the past there have been spotted some shortcomings in the Xenstore
interface, which should be repaired. Those are in detail:
- Using driver domains for large number of domains needs per domain
Xenstore quota [1]. The feedback sent was rather slim (one reply),
but it was preferring a new set
Add documentation for two new Xenstore wire commands SET_FEATURE and
GET_FEATURE used to set or query the Xenstore features visible in the
ring page of a given domain.
Signed-off-by: Juergen Gross
---
Do we need support in the migration protocol for the features?
V2:
- remove feature bit (Julien
Add documentation for two new Xenstore wire commands SET_QUOTA and
GET_QUOTA used to set or query the global Xenstore quota or those of
a given domain.
Signed-off-by: Juergen Gross
---
Note that it might be a good idea to add support to the Xenstore
migration protocol to transfer quota data (glob
Instead of specifying the feature bits in xenstore-ring.txt as a mask
value use bit numbers. This will make the specification easier to read
when adding more features.
Signed-off-by: Juergen Gross
---
V2:
- new patch (triggered by Julien Grall)
---
docs/misc/xenstore-ring.txt | 9 +
1 fi
Add documentation for an extension of the WATCH command used to limit
the scope of watched paths. Additionally it enables to receive more
information in the events related to special watches (@introduceDomain
or @releaseDomain).
Signed-off-by: Juergen Gross
---
This will probably need an extensio
On 20.05.2022 13:13, Roger Pau Monné wrote:
> On Wed, May 18, 2022 at 12:26:03PM +0200, Jan Beulich wrote:
>> On 10.05.2022 16:30, Roger Pau Monné wrote:
>>> On Mon, Apr 25, 2022 at 10:42:50AM +0200, Jan Beulich wrote:
@@ -837,9 +843,31 @@ static int dma_pte_clear_one(struct doma
On 27.05.2022 09:40, Jan Beulich wrote:
> On 20.05.2022 13:13, Roger Pau Monné wrote:
>> On Wed, May 18, 2022 at 12:26:03PM +0200, Jan Beulich wrote:
>>> On 10.05.2022 16:30, Roger Pau Monné wrote:
On Mon, Apr 25, 2022 at 10:42:50AM +0200, Jan Beulich wrote:
> @@ -837,9 +843,31 @@ static i
flight 170752 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On Fri, May 27, 2022 at 09:53:01AM +0200, Jan Beulich wrote:
> On 27.05.2022 09:40, Jan Beulich wrote:
> > On 20.05.2022 13:13, Roger Pau Monné wrote:
> >> On Wed, May 18, 2022 at 12:26:03PM +0200, Jan Beulich wrote:
> >>> On 10.05.2022 16:30, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 1
Ping?
On 03.05.22 15:22, Juergen Gross wrote:
x86_has_pat_wp() is using a wrong test, as it relies on the normal
PAT configuration used by the kernel. In case the PAT MSR has been
setup by another entity (e.g. BIOS or Xen hypervisor) it might return
false even if the PAT configuration is allowin
As per [1] the expansion of the pirq_dpci() macro causes a -Waddress
controlled warning (enabled implicitly in our builds, if not by default)
tying the middle part of the involved conditional expression to the
surrounding boolean context. Work around this by introducing a local
inline function in t
flight 170751 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170751/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt 20 guest-start/debian.repeat fail in 170747 pass in
170751
test-amd64-i386-migrupgrade
For a long time we've been rather inefficient with IOMMU page table
management when not sharing page tables, i.e. in particular for PV (and
further specifically also for PV Dom0) and AMD (where nowadays we never
share page tables). While up to about 3.5 years ago AMD code had logic
to un-shatter pa
While already the case for PVH, there's no reason to treat PV
differently here, though of course the addresses get taken from another
source in this case. Except that, to match CPU side mappings, by default
we permit r/o ones. This then also means we now deal consistently with
IO-APICs whose MMIO i
For large page mappings to be easily usable (i.e. in particular without
un-shattering of smaller page mappings) and for mapping operations to
then also be more efficient, pass batches of Dom0 memory to iommu_map().
In dom0_construct_pv() and its helpers (covering strict mode) this
additionally requ
For vendor specific code to support superpages we need to be able to
deal with a superpage mapping replacing an intermediate page table (or
hierarchy thereof). Consequently an iommu_alloc_pgtable() counterpart is
needed to free individual page tables while a domain is still alive.
Since the freeing
... depending on feature availability (and absence of quirks).
Also make the page table dumping function aware of superpages.
Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monné
---
v5: In intel_iommu_{,un}map_page() assert page order is supported.
v4: Change type o
Having a separate flush-all hook has always been puzzling me some. We
will want to be able to force a full flush via accumulated flush flags
from the map/unmap functions. Introduce a respective new flag and fold
all flush handling to use the single remaining hook.
Note that because of the respecti
This is a re-usable helper (kind of a template) which gets introduced
without users so that the individual subsequent patches introducing such
users can get committed independently of one another.
See the comment at the top of the new file. To demonstrate the effect,
if a page table had just 16 en
Page tables are used for two purposes after allocation: They either
start out all empty, or they are filled to replace a superpage.
Subsequently, to replace all empty or fully contiguous page tables,
contiguous sub-regions will be recorded within individual page tables.
Install the initial set of m
When a page table ends up with no present entries left, it can be
replaced by a non-present entry at the next higher level. The page table
itself can then be scheduled for freeing.
Note that while its output isn't used there yet,
pt_update_contig_markers() right away needs to be called in all plac
When a page table ends up with no present entries left, it can be
replaced by a non-present entry at the next higher level. The page table
itself can then be scheduled for freeing.
Note that while its output isn't used there yet,
pt_update_contig_markers() right away needs to be called in all plac
When a page table ends up with all contiguous entries (including all
identical attributes), it can be replaced by a superpage entry at the
next higher level. The page table itself can then be scheduled for
freeing.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
Unlike the freeing of
With iommu_flush_iotlb_all() gone, iommu_flush_iotlb_pages() is merely a
wrapper around the not otherwise called iommu_flush_iotlb(). Fold both
functions.
No functional change intended.
Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monné
---
v4: New.
--- a/xen/driv
This way intel_iommu_unmap_page() ends up quite a bit more similar to
intel_iommu_map_page().
No functional change intended.
Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monné
---
v5: Re-base of changes earlier in the series.
v4: New.
--- a/xen/drivers/passthrough
When a page table ends up with all contiguous entries (including all
identical attributes), it can be replaced by a superpage entry at the
next higher level. The page table itself can then be scheduled for
freeing.
The adjustment to LEVEL_MASK is merely to avoid leaving a latent trap
for whenever
Signed-off-by: Jan Beulich
Reviewed-by: Kevin tian
Reviewed-by: Roger Pau Monné
---
v3: New.
--- a/xen/arch/x86/include/asm/perfc_defn.h
+++ b/xen/arch/x86/include/asm/perfc_defn.h
@@ -125,4 +125,7 @@ PERFCOUNTER(realmode_exits, "vmexit
PERFCOUNTER(pauseloop_exits, "vmexits from Pause-L
No separate feature flags exist which would control availability of
these; the only restriction is HATS (establishing the maximum number of
page table levels in general), and even that has a lower bound of 4.
Thus we can unconditionally announce 2M and 1G mappings. (Via non-
default page sizes the
On 26.05.22 10:12, Luca Fancellu wrote:
Commit 92ea9c54fc81 ("arm/dom0less: assign dom0less guests to cpupools")
introduced a way to start a domain directly on a certain cpupool,
adding a "cpupool_id" member to struct xen_domctl_createdomain.
This was done to be able to start dom0less guests in
flight 170753 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 170714
test-amd64-amd64-do
On 24/05/2022 07:34, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 23.05.2022 22:00, Julien Grall wrote:
On 23/05/2022 11:21, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 23.05.2022 12:05, Julien Grall wrote:
Hi,
On 23/05/2022 10:13, Michal Orzel wrote:
Introduce a command line
Due to time constraints I am stepping down as maintainter. I will stay
as reviewer for x86 code (for which create a separate category).
Stefano is now maintainer for Xen hypervisor interface and Oleksandr has
graciously agreed to become a reviewer.
Signed-off-by: Boris Ostrovsky
---
MAINTAINERS
On Fri, 27 May 2022, Boris Ostrovsky wrote:
> Due to time constraints I am stepping down as maintainter. I will stay
> as reviewer for x86 code (for which create a separate category).
>
> Stefano is now maintainer for Xen hypervisor interface and Oleksandr has
> graciously agreed to become a revie
On 27.05.22 19:57, Boris Ostrovsky wrote:
Due to time constraints I am stepping down as maintainter. I will stay
as reviewer for x86 code (for which create a separate category).
Stefano is now maintainer for Xen hypervisor interface and Oleksandr has
graciously agreed to become a reviewer.
Sign
On 27.05.22 20:57, Boris Ostrovsky wrote:
Hello Boris
Due to time constraints I am stepping down as maintainter. I will stay
as reviewer for x86 code (for which create a separate category).
Stefano is now maintainer for Xen hypervisor interface and Oleksandr has
graciously agreed to become a
flight 170755 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170755/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dac2fc8146e42ef19cd50ecbe32ccb7705b76fa3
baseline version:
ovmf 16779ede2d366bfc6b702
On Fri, 27 May 2022, Jan Beulich wrote:
> On 26.05.2022 21:57, Stefano Stabellini wrote:
> > On Thu, 26 May 2022, Bertrand Marquis wrote:
> >>> On 26 May 2022, at 11:15, Jan Beulich wrote:
> >>> On 26.05.2022 11:54, Bertrand Marquis wrote:
> > On 26 May 2022, at 10:43, Jan Beulich wrote:
> >>
flight 170754 qemu-mainline real [real]
flight 170757 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170754/
http://logs.test-lab.xenproject.org/osstest/logs/170757/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
flight 170756 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170756/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 170714
test-amd64-amd64-xl
39 matches
Mail list logo
