flight 179499 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179499/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-freebsd12-amd64 13 guest-start fail REGR. vs. 178042
On Thu, Mar 02, 2023 at 12:46:10PM -0800, Luis Chamberlain wrote:
> Although this driver is a good use case for having a directory
> that is not other directories and then subdirectories with more
> entries, the usage of register_sysctl_table() can recurse and
> increases complexity so to avoid
flight 179504 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179504/
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
On Tue, 7 Mar 2023, Michal Orzel wrote:
> Hi Stefano,
>
> On 07/03/2023 00:33, Stefano Stabellini wrote:
> >
> >
> > From: Stefano Stabellini
> >
> > The test prepares dom0 and domU binaries and boot artifacts, similarly
> > to the existing QEMU test. (TBD: share preparation steps with the
>
flight 179502 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179502/
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
On 7/3/23 23:34, David Woodhouse wrote:
On Tue, 2023-03-07 at 21:20 +0100, Philippe Mathieu-Daudé wrote:
This tag only appears in the cover letter, and is missing in each patch.
It would have been acceptable if it were in the PR tag, but
the tag (which for some reason isn't displayed in your
flight 179497 qemu-mainline real [real]
flight 179500 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/179497/
http://logs.test-lab.xenproject.org/osstest/logs/179500/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Tue, 28 Feb 2023, Jan Beulich wrote:
> On 28.02.2023 09:14, Michal Orzel wrote:
> > On 27/02/2023 16:57, Jan Beulich wrote:
> >> On 27.02.2023 16:46, Michal Orzel wrote:
> >>> On 27/02/2023 16:00, Jan Beulich wrote:
> On 27.02.2023 15:46, Michal Orzel wrote:
> > On 27/02/2023 14:54,
On Tue, 2023-03-07 at 21:20 +0100, Philippe Mathieu-Daudé wrote:
>
> This tag only appears in the cover letter, and is missing in each patch.
> It would have been acceptable if it were in the PR tag, but
> the tag (which for some reason isn't displayed in your cover letter)
> is simply "PV back
On 3/6/23 11:34 AM, Juergen Gross wrote:
When running as Xen PV initial domain (aka dom0), MTRRs are disabled
by the hypervisor, but the system should nevertheless use correct
cache memory types. This has always kind of worked, as disabled MTRRs
resulted in disabled PAT, too, so that the
From: Juergen Gross Sent: Monday, March 6, 2023 8:34 AM
>
> This series tries to fix the rather special case of PAT being available
> without having MTRRs (either due to CONFIG_MTRR being not set, or
> because the feature has been disabled e.g. by a hypervisor).
>
> The main use cases are Xen
On Tue, 7 Mar 2023, Bertrand Marquis wrote:
> > On 7 Mar 2023, at 11:09, Andrei Cherechesu (OSS)
> > wrote:
> >
> > From: Andrei Cherechesu
> >
> > Added support for parsing the ARM generic timer interrupts DT
> > node by the "interrupt-names" property, if it is available.
> >
> > If not
On Tue, 7 Mar 2023, Marek Marczykowski-Górecki wrote:
> On Mon, Mar 06, 2023 at 03:02:51PM -0800, Stefano Stabellini wrote:
> > On Mon, 6 Mar 2023, Andrew Cooper wrote:
> > > On 03/03/2023 11:57 pm, Stefano Stabellini wrote:
> > > > + only:
> > > > +variables:
> > > > + - $XILINX_JOBS ==
Hi David,
On 7/3/23 19:26, David Woodhouse wrote:
The following changes since commit 9832009d9dd2386664c15cc70f6e6bfe062be8bd:
Merge tag 'pull-riscv-to-apply-20230306' of
https://gitlab.com/palmer-dabbelt/qemu into staging (2023-03-07 12:53:00 +)
are available in the Git repository
On 07/03/2023 17:38, Bertrand Marquis wrote:
> Hi Andrei,
>
>> On 7 Mar 2023, at 11:09, Andrei Cherechesu (OSS)
>> wrote:
>>
>> From: Andrei Cherechesu
>>
>> Added support for parsing the ARM generic timer interrupts DT
>> node by the "interrupt-names" property, if it is available.
>>
>> If
From: David Woodhouse
The existing implementation calling into the real libxenevtchn moves to
a new file hw/xen/xen-operations.c, and is called via a function table
which in a subsequent commit will also be able to invoke the emulated
event channel support.
Signed-off-by: David Woodhouse
On Tue, 2023-03-07 at 17:57 +, Paul Durrant wrote:
> I think the series is good to go now so time to send a PR.
Done, thank you!
smime.p7s
Description: S/MIME cryptographic signature
From: David Woodhouse
This implements the basic wire protocol for the XenStore commands, punting
all the actual implementation to xs_impl_* functions which all just return
errors for now.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/meson.build | 1 +
From: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 70 ++
1 file changed, 70 insertions(+)
diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
index
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/char/xen_console.c| 8 +++---
hw/display/xenfb.c | 20 +++---
hw/xen/xen-operations.c | 45
include/hw/xen/xen_backend_ops.h | 26
From: David Woodhouse
This is a fairly simple implementation of a copy-on-write tree.
The node walk function starts off at the root, with 'inplace == true'.
If it ever encounters a node with a refcount greater than one (including
the root node), then that node is shared with other trees, and
From: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
accel/xen/xen-all.c | 11 +-
hw/char/xen_console.c | 2 +-
hw/i386/kvm/xen_xenstore.c | 3 -
hw/i386/kvm/xenstore_impl.h | 8 +-
From: Paul Durrant
The xen-block code ends up calling aio_poll() through blkconf_geometry(),
which means we see watch events during the indirect call to
xendev_class->realize() in xen_device_realize(). Unfortunately this call
is made before populating the initial frontend and backend device
From: Paul Durrant
Store perms as a GList of strings, check permissions.
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 2 +-
hw/i386/kvm/xenstore_impl.c | 259 +---
From: David Woodhouse
XC_PAGE_SIZE comes from the actual Xen libraries, while XEN_PAGE_SIZE is
provided by QEMU itself in xen_backend_ops.h. For backends which may be
built for emulation mode, use the latter.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
docs/system/i386/xen.rst | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/docs/system/i386/xen.rst b/docs/system/i386/xen.rst
index a00523b492..f06765e88c
From: David Woodhouse
We provided the backend-facing evtchn functions very early on as part of
the core Xen platform support, since things like timers and xenstore need
to use them.
By what may or may not be an astonishing coincidence, those functions
just *happen* all to have exactly the right
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5340de0515..640deb2895 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -443,6 +443,15 @@ F:
From: David Woodhouse
Move the existing code using libxengnttab to xen-operations.c and allow
the operations to be redirected so that we can add emulation of grant
table mapping for backend drivers.
In emulation, mapping more than one grant ref to be virtually contiguous
would be fairly
From: David Woodhouse
Now that all the work is done to enable the PV backends to work without
actual Xen, instantiate the bus from pc_basic_device_init() for emulated
mode.
This allows us finally to launch an emulated Xen guest with PV disk.
qemu-system-x86_64 -serial mon:stdio -M q35 -cpu
From: David Woodhouse
Given that the whole thing supported copy on write from the beginning,
transactions end up being fairly simple. On starting a transaction, just
take a ref of the existing root; swap it back in on a successful commit.
The main tree has a transaction ID too, and we keep a
From: David Woodhouse
The previous commit introduced redirectable gnttab operations fairly
much like-for-like, with the exception of the extra arguments to the
->open() call which were always NULL/0 anyway.
This *changes* the arguments to the ->unmap() operation to include the
original ref#
From: David Woodhouse
There's no need for this to be in the Xen accel code, and as we want to
use the Xen console support with KVM-emulated Xen we'll want to have a
platform-agnostic version of it. Make it use GString to build up the
path while we're at it.
Signed-off-by: David Woodhouse
From: David Woodhouse
This header is now only for native Xen code, not PV backends that may be
used in Xen emulation. Since the toolstack libraries may depend on the
specific version of Xen headers that they pull in (and will set the
__XEN_TOOLS__ macro to enable internal definitions that they
From: David Woodhouse
This is limited to mapping a single grant at a time, because under Xen the
pages are mapped *contiguously* into qemu's address space, and that's very
hard to do when those pages actually come from anonymous mappings in qemu
in the first place.
Eventually perhaps we can
From: David Woodhouse
This is only part of it; we will also need to get the PV back end drivers
to tear down their own mappings (or do it for them, but they kind of need
to stop using the pointers too).
Some more work on the actual PV back ends and xen-bus code is going to be
needed to really
From: David Woodhouse
We don't actually access the guest's page through the grant, because
this isn't real Xen, and we can just use the page we gave it in the
first place. Map the grant anyway, mostly for cosmetic purposes so it
*looks* like it's in use in the guest-visible grant table.
From: David Woodhouse
This implements the basic migration support in the back end, with unit
tests that give additional confidence in the node-counting already in
the tree.
However, the existing PV back ends like xen-disk don't support migration
yet. They will reset the ring and fail to
From: David Woodhouse
Whem emulating Xen, multi-page grants are distinctly non-trivial and we
have elected not to support them for the time being. Don't advertise
them to the guest.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/block/xen-block.c | 11 ---
1 file
The following changes since commit 9832009d9dd2386664c15cc70f6e6bfe062be8bd:
Merge tag 'pull-riscv-to-apply-20230306' of
https://gitlab.com/palmer-dabbelt/qemu into staging (2023-03-07 12:53:00 +)
are available in the Git repository at:
git://git.infradead.org/users/dwmw2/qemu.git
From: David Woodhouse
Firing watches on the nodes that still exist is relatively easy; just
walk the tree and look at the nodes with refcount of one.
Firing watches on *deleted* nodes is more fun. We add 'modified_in_tx'
and 'deleted_in_tx' flags to each node. Nodes with those flags cannot
be
From: David Woodhouse
Now that we have the redirectable Xen backend operations we can build the
PV backends even without the Xen libraries.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/9pfs/meson.build| 2 +-
hw/block/dataplane/meson.build | 2 +-
From: David Woodhouse
Starts out fairly simple: a hash table of watches based on the path.
Except there can be multiple watches on the same path, so the watch ends
up being a simple linked list, and the head of that list is in the hash
table. Which makes removal a bit of a PITA but it's not so
From: David Woodhouse
Now that we have an internal implementation of XenStore, we can populate
the xenstore_backend_ops to allow PV backends to talk to it.
Watches can't be processed with immediate callbacks because that would
call back into XenBus code recursively. Defer them to a QEMUBH to be
flight 179462 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179462/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 15
On 07/03/2023 17:17, David Woodhouse wrote:
Following on from the basic platform support which has already been
merged, here's phase 2 which wires up the XenBus and PV back ends.
It starts with a basic single-tenant internal implementation of a
XenStore, with a copy-on-write tree, watches,
On 07/03/2023 17:17, David Woodhouse wrote:
From: David Woodhouse
Now that all the work is done to enable the PV backends to work without
actual Xen, instantiate the bus from pc_basic_device_init() for emulated
mode.
This allows us finally to launch an emulated Xen guest with PV disk.
flight 179498 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179498/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 75fb0cfc82376906243386514be0e4067d702117
baseline version:
ovmf
On 07/03/2023 17:27, Bertrand Marquis wrote:
> Hi Andrei,
>
> When submitting patches, please use the add_maintainer.pl script so that
> maintainers of the code
> modified are added in CC.
Hi Bertrand,
Thank you for reviewing the patches. I apologize for not adding the
maintainers in CC. I
From: David Woodhouse
Firing watches on the nodes that still exist is relatively easy; just
walk the tree and look at the nodes with refcount of one.
Firing watches on *deleted* nodes is more fun. We add 'modified_in_tx'
and 'deleted_in_tx' flags to each node. Nodes with those flags cannot
be
From: David Woodhouse
This header is now only for native Xen code, not PV backends that may be
used in Xen emulation. Since the toolstack libraries may depend on the
specific version of Xen headers that they pull in (and will set the
__XEN_TOOLS__ macro to enable internal definitions that they
From: David Woodhouse
Now that we have an internal implementation of XenStore, we can populate
the xenstore_backend_ops to allow PV backends to talk to it.
Watches can't be processed with immediate callbacks because that would
call back into XenBus code recursively. Defer them to a QEMUBH to be
From: David Woodhouse
Move the existing code using libxengnttab to xen-operations.c and allow
the operations to be redirected so that we can add emulation of grant
table mapping for backend drivers.
In emulation, mapping more than one grant ref to be virtually contiguous
would be fairly
From: David Woodhouse
The previous commit introduced redirectable gnttab operations fairly
much like-for-like, with the exception of the extra arguments to the
->open() call which were always NULL/0 anyway.
This *changes* the arguments to the ->unmap() operation to include the
original ref#
From: David Woodhouse
This implements the basic migration support in the back end, with unit
tests that give additional confidence in the node-counting already in
the tree.
However, the existing PV back ends like xen-disk don't support migration
yet. They will reset the ring and fail to
From: David Woodhouse
Given that the whole thing supported copy on write from the beginning,
transactions end up being fairly simple. On starting a transaction, just
take a ref of the existing root; swap it back in on a successful commit.
The main tree has a transaction ID too, and we keep a
From: David Woodhouse
XC_PAGE_SIZE comes from the actual Xen libraries, while XEN_PAGE_SIZE is
provided by QEMU itself in xen_backend_ops.h. For backends which may be
built for emulation mode, use the latter.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
From: David Woodhouse
The existing implementation calling into the real libxenevtchn moves to
a new file hw/xen/xen-operations.c, and is called via a function table
which in a subsequent commit will also be able to invoke the emulated
event channel support.
Signed-off-by: David Woodhouse
From: David Woodhouse
We provided the backend-facing evtchn functions very early on as part of
the core Xen platform support, since things like timers and xenstore need
to use them.
By what may or may not be an astonishing coincidence, those functions
just *happen* all to have exactly the right
From: David Woodhouse
We don't actually access the guest's page through the grant, because
this isn't real Xen, and we can just use the page we gave it in the
first place. Map the grant anyway, mostly for cosmetic purposes so it
*looks* like it's in use in the guest-visible grant table.
From: Paul Durrant
Store perms as a GList of strings, check permissions.
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 2 +-
hw/i386/kvm/xenstore_impl.c | 259 +---
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5340de0515..640deb2895 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -443,6 +443,15 @@ F:
From: David Woodhouse
This is limited to mapping a single grant at a time, because under Xen the
pages are mapped *contiguously* into qemu's address space, and that's very
hard to do when those pages actually come from anonymous mappings in qemu
in the first place.
Eventually perhaps we can
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/char/xen_console.c| 8 +++---
hw/display/xenfb.c | 20 +++---
hw/xen/xen-operations.c | 45
include/hw/xen/xen_backend_ops.h | 26
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
docs/system/i386/xen.rst | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/docs/system/i386/xen.rst b/docs/system/i386/xen.rst
index a00523b492..f06765e88c
From: David Woodhouse
Now that we have the redirectable Xen backend operations we can build the
PV backends even without the Xen libraries.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/9pfs/meson.build| 2 +-
hw/block/dataplane/meson.build | 2 +-
From: David Woodhouse
This is a fairly simple implementation of a copy-on-write tree.
The node walk function starts off at the root, with 'inplace == true'.
If it ever encounters a node with a refcount greater than one (including
the root node), then that node is shared with other trees, and
From: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
accel/xen/xen-all.c | 11 +-
hw/char/xen_console.c | 2 +-
hw/i386/kvm/xen_xenstore.c | 3 -
hw/i386/kvm/xenstore_impl.h | 8 +-
Following on from the basic platform support which has already been
merged, here's phase 2 which wires up the XenBus and PV back ends.
It starts with a basic single-tenant internal implementation of a
XenStore, with a copy-on-write tree, watches, transactions, quotas.
Then we introduce
From: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 70 ++
1 file changed, 70 insertions(+)
diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
index
From: David Woodhouse
Starts out fairly simple: a hash table of watches based on the path.
Except there can be multiple watches on the same path, so the watch ends
up being a simple linked list, and the head of that list is in the hash
table. Which makes removal a bit of a PITA but it's not so
From: David Woodhouse
There's no need for this to be in the Xen accel code, and as we want to
use the Xen console support with KVM-emulated Xen we'll want to have a
platform-agnostic version of it. Make it use GString to build up the
path while we're at it.
Signed-off-by: David Woodhouse
From: David Woodhouse
This is only part of it; we will also need to get the PV back end drivers
to tear down their own mappings (or do it for them, but they kind of need
to stop using the pointers too).
Some more work on the actual PV back ends and xen-bus code is going to be
needed to really
From: David Woodhouse
This implements the basic wire protocol for the XenStore commands, punting
all the actual implementation to xs_impl_* functions which all just return
errors for now.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/meson.build | 1 +
From: Paul Durrant
The xen-block code ends up calling aio_poll() through blkconf_geometry(),
which means we see watch events during the indirect call to
xendev_class->realize() in xen_device_realize(). Unfortunately this call
is made before populating the initial frontend and backend device
From: David Woodhouse
Now that all the work is done to enable the PV backends to work without
actual Xen, instantiate the bus from pc_basic_device_init() for emulated
mode.
This allows us finally to launch an emulated Xen guest with PV disk.
qemu-system-x86_64 -serial mon:stdio -M q35 -cpu
From: David Woodhouse
Whem emulating Xen, multi-page grants are distinctly non-trivial and we
have elected not to support them for the time being. Don't advertise
them to the guest.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/block/xen-block.c | 11 ---
1 file
On 07/03/2023 16:59, Paul Durrant wrote:
On 07/03/2023 16:52, David Woodhouse wrote:
On Tue, 2023-03-07 at 16:39 +, Paul Durrant wrote:
On 07/03/2023 16:33, David Woodhouse wrote:
On Thu, 2023-03-02 at 15:34 +, David Woodhouse wrote:
From: David Woodhouse
In fact I think we want to
On 07/03/2023 16:52, David Woodhouse wrote:
On Tue, 2023-03-07 at 16:39 +, Paul Durrant wrote:
On 07/03/2023 16:33, David Woodhouse wrote:
On Thu, 2023-03-02 at 15:34 +, David Woodhouse wrote:
From: David Woodhouse
In fact I think we want to only serialize the contents of the
On 07.03.2023 15:44, Matias Ezequiel Vara Larsen wrote:
> On Thu, Feb 23, 2023 at 01:42:08PM +0100, Jan Beulich wrote:
>> On 23.02.2023 13:16, Matias Ezequiel Vara Larsen wrote:
>>> On Fri, Feb 17, 2023 at 03:10:53PM +0100, Jan Beulich wrote:
On 17.02.2023 10:29, Matias Ezequiel Vara Larsen
On Tue, 2023-03-07 at 16:39 +, Paul Durrant wrote:
> On 07/03/2023 16:33, David Woodhouse wrote:
> > On Thu, 2023-03-02 at 15:34 +, David Woodhouse wrote:
> > > From: David Woodhouse
> > >
> > > In fact I think we want to only serialize the contents of the domain's
> > > path in
On 07/03/2023 16:39, Paul Durrant wrote:
On 07/03/2023 16:33, David Woodhouse wrote:
On Thu, 2023-03-02 at 15:34 +, David Woodhouse wrote:
From: David Woodhouse
In fact I think we want to only serialize the contents of the domain's
path in /local/domain/${domid} and leave the rest to be
On 07/03/2023 16:33, David Woodhouse wrote:
On Thu, 2023-03-02 at 15:34 +, David Woodhouse wrote:
From: David Woodhouse
In fact I think we want to only serialize the contents of the domain's
path in /local/domain/${domid} and leave the rest to be recreated? Will
defer to Paul for that.
On Thu, 2023-03-02 at 15:34 +, David Woodhouse wrote:
> From: David Woodhouse
>
> In fact I think we want to only serialize the contents of the domain's
> path in /local/domain/${domid} and leave the rest to be recreated? Will
> defer to Paul for that.
>
> Signed-off-by: David Woodhouse
On 07/03/2023 16:22, David Woodhouse wrote:
From: David Woodhouse
Signed-off-by: David Woodhouse
---
docs/system/i386/xen.rst | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
Reviewed-by: Paul Durrant
On 07/03/2023 16:21, David Woodhouse wrote:
From: David Woodhouse
Signed-off-by: David Woodhouse
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
Reviewed-by: Paul Durrant
On 02/03/2023 15:34, David Woodhouse wrote:
From: David Woodhouse
Now that all the work is done to enable the PV backends to work without
actual Xen, instantiate the bus from pc_basic_device_init() for emulated
mode.
This allows us finally to launch an emulated Xen guest with PV disk.
On 02/03/2023 15:34, David Woodhouse wrote:
From: David Woodhouse
This is only part of it; we will also need to get the PV back end drivers
to tear down their own mappings (or do it for them, but they kind of need
to stop using the pointers too).
Some more work on the actual PV back ends and
On Tue, Mar 07, 2023 at 11:13:36AM +0530, Viresh Kumar wrote:
> On 06-03-23, 10:34, Stefan Hajnoczi wrote:
> > On Mon, Mar 06, 2023 at 04:40:24PM +0530, Viresh Kumar wrote:
> > > +Xen mmap description
> > > +
> > > +
> > > ++---+---+
> > > +| flags | domid |
> > >
On 02/03/2023 15:34, David Woodhouse wrote:
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 16
1 file changed, 16 insertions(+)
diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
index 028f80499e..f9b7387024 100644
From: David Woodhouse
Signed-off-by: David Woodhouse
---
docs/system/i386/xen.rst | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/docs/system/i386/xen.rst b/docs/system/i386/xen.rst
index a00523b492..f06765e88c 100644
---
From: David Woodhouse
Signed-off-by: David Woodhouse
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index da29661b37..76b705e467 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -443,6 +443,15 @@ F: target/i386/kvm/
F: target/i386/sev*
F:
On 02/03/2023 15:34, David Woodhouse wrote:
From: David Woodhouse
Now that we have an internal implementation of XenStore, we can populate
the xenstore_backend_ops to allow PV backends to talk to it.
Watches can't be processed with immediate callbacks because that would
call back into XenBus
On Tue, 2023-03-07 at 16:07 +, Paul Durrant wrote:
> On 02/03/2023 15:34, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > This is limited to mapping a single grant at a time, because under Xen the
> > pages are mapped *contiguously* into qemu's address space, and that's very
> >
On 02/03/2023 15:34, David Woodhouse wrote:
From: David Woodhouse
This is limited to mapping a single grant at a time, because under Xen the
pages are mapped *contiguously* into qemu's address space, and that's very
hard to do when those pages actually come from anonymous mappings in qemu
in
On 07.03.23 16:14, Jan Beulich wrote:
On 07.03.2023 16:02, Juergen Gross wrote:
On 07.03.23 15:34, Jan Beulich wrote:
On 07.03.2023 15:23, Juergen Gross wrote:
On 07.03.23 15:18, Jan Beulich wrote:
On 07.03.2023 15:04, Juergen Gross wrote:
On 07.03.23 11:41, Jan Beulich wrote:
On
The following changes were made:
* Make GENERIC_BUG_FRAME mandatory for X86
* Update asm/bug.h using generic implementation in
* Update do_invalid_op using generic do_bug_frame()
* Define BUG_DEBUGGER_TRAP_FATAL to debugger_trap_fatal(X86_EXC_GP,regs)
* type of eip variable was changed to 'void
A large part of the content of the bug.h is repeated among all
architectures, so it was decided to create a new config
CONFIG_GENERIC_BUG_FRAME.
The version of from x86 was taken as the base version.
The patch introduces the following stuff:
* common bug.h header
* generic implementation of
The following changes were made:
* make GENERIC_BUG_FRAME mandatory for ARM
* As do_bug_frame() returns -EINVAL in case something goes wrong
otherwise id of bug frame. Thereby 'if' cases where do_bug_frame() was
updated to check if the returned value is less than 0
* Switch ARM's
The idea of the patch is to change all to and
keep Xen compilable with adding only minimal amount of changes:
1. It was added "#include " to ARM's "" as it
uses uint_{16,32}t in 'struct bug_frame'.
2. It was added '#define BUG_FRAME_STRUCT' which means that ARM hasn't
been switched to
1 - 100 of 169 matches
Mail list logo
