On Thu, 2019-04-11 at 13:35 -0700, Alistair Francis wrote:
> > > > +if (!qtest_enabled()) {
> > > > +info_report("The Spike v1.09.1 machine has been
> > > > depreceated. "
> > > > +"Please use the deneric spike machine and
> > > > specify the ISA "
> >
> >
On Fri, 2019-03-29 at 22:39 +, Alistair Francis wrote:
> +for (i = 0; i < strlen(riscv_cpu); i++) {
> +if (i == 0 && riscv_cpu[i] == 'r' &&
> +riscv_cpu[i + 1] == 'v') {
Dpes something somewhere else enforce a minimum length or can
`riscv_cpu[i + 1]` be past the end of
On Tue, 2016-02-09 at 16:50 +, Stefano Stabellini wrote:
> > @@ -2218,15 +2127,10 @@ EOF
> > fi
> >
> > if test "$xen_pci_passthrough" != "no"; then
> > - if test "$xen" = "yes" && test "$linux" = "yes" &&
> > - test "$xen_ctrl_version" -ge 340; then
> > + if test "$xen" = "yes" &&
This is most easily explained by the commit log of the first patch:
Xen 4.2 become unsupported upstream in 09/2015 (see
http://wiki.xen.org/wiki/Xen_Release_Features). However as far as the
interfaces provided by the toolstack libraries go 4.2 and 4.3 are
indistinguishable.
The xc version is now always present.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
include/hw/xen/xen_common.h | 6 --
xen-hvm.c | 2 +-
2 files changed, 1 insertion(+), 7 deleti
_interface* and remove various uses of &
and *h.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
v2: Mention xenforeignmemory changes in commit message.
---
hw/xen/xen_backend.c | 4 +--
include/hw/xen/xen_
support upstream
QEMU (as a preview) so that makes sense as a cut-off now.
This change drops all the configure-y and resulting ifdefs in a mostly
mechanical way. A follow up will refactor wrappers which are now
unused.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
v2: Don't
Now that we no longer support Xen 4.2 and earlier only the <470 case
needs this so it can live with all the others.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
include/hw/xen/xe
We assume (and check for in configure) 4.2 or later now. In reality
all of the removed checks are for far older versions.
FMT_ioreq_size is no longer needed.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
v2: Drop FMT_ioreq_size too
---
hw/display/xenfb.c | 7 ---
xen
This is most easily explained by the commit log of the first patch:
Xen 4.2 become unsupported upstream in 09/2105 (see
http://wiki.xen.org/wiki/Xen_Release_Features). However as far as the
interfaces provided by the toolstack libraries go 4.2 and 4.3 are
indistinguishable.
The xc version is now always present.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
include/hw/xen/xen_common.h | 6 --
xen-hvm.c | 2 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_co
support upstream
QEMU (as a preview) so that makes sense as a cut-off now.
This change drops all the configure-y and resulting ifdefs in a mostly
mechanical way. A follow up will refactor wrappers which are now
unused.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
con
We assume (and check for in configure) 4.2 or later now. In reality
all of the removed checks are for far older versions.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
hw/display/xenfb.c | 7 ---
xen-hvm.c | 14 +-
2 files changed, 1 insertion(
Now that we no longer support Xen 4.2 and earlier only the <470 case
needs this so it can live with all the others.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
include/hw/xen/xen_common.h | 34 ++
1 file changed, 14 insertions(+), 20
Now that 4.2 and earlier are no longer supported "xc_interface *" is
always the right type for the xc interface handle.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
hw/xen/xen_backend.c | 4 +--
include/hw/xen/xen_backend.h | 2 +-
include/hw/xen/xe
On Tue, 2016-01-19 at 15:44 +, Ian Campbell wrote:
> On Fri, 2016-01-15 at 13:22 +0000, Ian Campbell wrote:
> >
> > Therefore needing attention from Ian and/or Wei are:
> >
> > tools/libs/foreignmemory: Mention restrictions on fork in docs.
> > N
On Fri, 2016-01-15 at 13:22 +, Ian Campbell wrote:
> In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some
> parts of the libxenctrl API/ABI by disaggregating into separate
> libraries.
>
> This is v8 of that set of series against:
> xen
>
On Fri, 2016-01-15 at 13:22 +, Ian Campbell wrote:
>
> Therefore needing attention from Ian and/or Wei are:
>
> tools/libs/foreignmemory: Mention restrictions on fork in docs.
> N tools/libs/evtchn: Use uint32_t for domid arguments
> D tools/libs/gnttab:
In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some
parts of the libxenctrl API/ABI by disaggregating into separate
libraries.
This is v8 of that set of series against:
xen
qemu-xen
qemu-xen-traditional
mini-os
NB: Samuel+minios-devel will only get the mini-os
ated patch series and which
contains more details.
Ian Campbell (8):
xen_console: correctly cleanup primary console on teardown.
xen: Switch to libxenevtchn interface for compat shims.
xen: Switch to libxengnttab interface for compat shims.
xen: Switch uses of xc_map_for
dle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.
Note that this patch does not add any support for actually using
libxengnttab, it just adjusts the existing shims.
Signed-off-by: Ian Campbell <ian.campb...@citr
- xc_domain_destroy
- xc_domain_getinfo
- xc_domain_max_vcpus
- xc_domain_setmaxmem
- xc_domain_unpause
- xc_evtchn_alloc_unbound
- xc_linux_build
This is another step towards only using Xen libraries which provide a
stable inteface.
Signed-off-by: Ian Campbell <ian.ca
ins in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not
ng an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
v8: Move two copies of compat xenforeignmemory_{open,unmap} to the
common location. Guard wi
r neither. For
consistency with con_initialise() with to the former here too.
With this con_initialise and con_disconnect now mirror each other.
Fix up a hard tab in the function while editing.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini &
the
introduction of these new interfaces.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
v8: Use CONFIG_XEN_CTRL_INTERFACE_VERSION == 471 for new interfaces.
Dropped Reviewed-by.
v6: Two minor formatting things.
Rebase onto "xen: fix usage of xc_domain_create in domain
in
effect upcast the pointer from int* to xen_pfn_t*.
In xenfb.c:common_bind we now explicitly launder the mfn into a
xen_pfn_t, so it has the correct type to be passed to
xc_map_foreign_pages and doesn't provoke warnings on 32-bit x86.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Revie
Using an existing libxenctrl handle after a fork was never
particularly safe (especially if foreign mappings existed at the time
of the fork) and the xc fd has been unavailable for many releases.
Reopen the handle after fork and therefore do away with xc_fd().
Signed-off-by: Ian Campbell
On Fri, 2016-01-15 at 14:44 +, Stefano Stabellini wrote:
> What's the status of the libxc side changes? Is the interface stable
> enough for me to commit this series?
I'd recommend waiting. I'll ping you when it looks appropriate to apply
this series.
Thanks for the final acks on this
- xc_domain_destroy
- xc_domain_getinfo
- xc_domain_max_vcpus
- xc_domain_setmaxmem
- xc_domain_unpause
- xc_evtchn_alloc_unbound
- xc_linux_build
This is another step towards only using Xen libraries which provide a
stable inteface.
Signed-off-by: Ian Campbell <ian.ca
Using an existing libxenctrl handle after a fork was never
particularly safe (especially if foreign mappings existed at the time
of the fork) and the xc fd has been unavailable for many releases.
Reopen the handle after fork and therefore do away with xc_fd().
Signed-off-by: Ian Campbell
r neither. For
consistency with con_initialise() with to the former here too.
With this con_initialise and con_disconnect now mirror each other.
Fix up a hard tab in the function while editing.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini &
In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some
parts of the libxenctrl API/ABI by disaggregating into separate
libraries.
This is v7 of that set of series against:
xen
qemu-xen
qemu-xen-traditional
mini-os
NB: Samuel+minios-devel will only get the mini-os
On Wed, 2015-12-16 at 14:39 +, Stefano Stabellini wrote:
>
> Why not move the definition of xenforeignmemory_open and
> xenforeignmemory_unmap here too?
I failed to spot they were also the same. Will do.
Ian.
time.
The only non-obvious bit is that we now open a proper xenforeignmemory
handle for xen_fmem instead of reusing the xen_xc handle.
Build tested with 4.0 .. 4.6 (inclusive) and the patches targetting
4.7 which adds these libraries.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Re
ng an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
v7: Move two copies of compat xenforeignmemory_map to a common location.
Note that the existing xen
ins in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not
dle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.
Note that this patch does not add any support for actually using
libxengnttab, it just adjusts the existing shims.
Signed-off-by: Ian Campbell <ian.campb...@citr
in
effect upcast the pointer from int* to xen_pfn_t*.
In xenfb.c:common_bind we now explicitly launder the mfn into a
xen_pfn_t, so it has the correct type to be passed to
xc_map_foreign_pages and doesn't provoke warnings on 32-bit x86.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Revie
ated patch series and which
contains more details.
Ian Campbell (8):
xen_console: correctly cleanup primary console on teardown.
xen: Switch to libxenevtchn interface for compat shims.
xen: Switch to libxengnttab interface for compat shims.
xen: Switch uses of xc_map_for
On Mon, 2015-12-14 at 11:19 +, Stefano Stabellini wrote:
> On Fri, 11 Dec 2015, Ian Campbell wrote:
> > On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
> > >
> > > It is not possible to do this at runtime. I think we should do this
> > > at
&g
On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
>
> It is not possible to do this at runtime. I think we should do this at
> compile time because in any case it is not supported to run a QEMU built
> for a given Xen version on a different Xen version.
I am currently working pretty
On Fri, 2015-12-11 at 14:26 +, Stefano Stabellini wrote:
> On Wed, 9 Dec 2015, Ian Campbell wrote:
> > On Thu, 2015-12-03 at 11:23 +0000, Ian Campbell wrote:
> > > diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> > > index 5e324ef..c96d974 100644
>
On Thu, 2015-12-03 at 11:21 +, Ian Campbell wrote:
>
> Last time proposed that these precursors (and the corresponding qemu-xen-
> traditional + mini-os patches) should go in now:
>
> tools/Rules.mk: Properly handle libraries with recursive dependencies.
>
On Thu, 2015-12-03 at 11:23 +, Ian Campbell wrote:
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 5e324ef..c96d974 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -104,9 +104,8 @@ static int common_bind(struct common *c)
> if (xenstore_r
On Wed, 2015-12-09 at 13:56 +, Andrew Cooper wrote:
> On 09/12/15 13:41, Ian Campbell wrote:
> > On Thu, 2015-12-03 at 11:23 +0000, Ian Campbell wrote:
> > > diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> > > index 5e324ef..c96d974 100644
> > > ---
In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some
parts of the libxenctrl API/ABI by disaggregating into separate
libraries.
This is v6 of that set of series against:
xen
qemu-xen
qemu-xen-traditional
mini-os
NB: Samuel+minios-devel will only get the mini-os
ated patch series and which
contains more details.
Ian Campbell (8):
xen_console: correctly cleanup primary console on teardown.
xen: Switch to libxenevtchn interface for compat shims.
xen: Switch to libxengnttab interface for compat shims.
xen: Switch uses of xc_map_for
r neither. For
consistency with con_initialise() with to the former here too.
With this con_initialise and con_disconnect now mirror each other.
Fix up a hard tab in the function while editing.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini &
- xc_domain_destroy
- xc_domain_getinfo
- xc_domain_max_vcpus
- xc_domain_setmaxmem
- xc_domain_unpause
- xc_evtchn_alloc_unbound
- xc_linux_build
This is another step towards only using Xen libraries which provide a
stable inteface.
Signed-off-by: Ian Campbell <ian.ca
dle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.
Note that this patch does not add any support for actually using
libxengnttab, it just adjusts the existing shims.
Signed-off-by: Ian Campbell <ian.campb...@citr
in
effect upcast the pointer from int* to xen_pfn_t*.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
v6: Switch to xc_map_foreign_pages rather than _bulk. Switching to
_bulk without checking the value of err[0] risked missing errors.
The new xenforeignmemory_map coming later
Using an existing libxenctrl handle after a fork was never
particularly safe (especially if foreign mappings existed at the time
of the fork) and the xc fd has been unavailable for many releases.
Reopen the handle after fork and therefore do away with xc_fd().
Signed-off-by: Ian Campbell
ins in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not
time.
The only non-obvious bit is that we now open a proper xenforeignmemory
handle for xen_fmem instead of reusing the xen_xc handle.
Build tested with 4.0 .. 4.6 (inclusive) and the patches targetting
4.7 which adds these libraries.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
ng an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
v6: Handle _pages as well as _bulk, due to changes in the previous
patches, including the dropping
On Fri, 2015-11-13 at 13:46 +, Stefano Stabellini wrote:
> On Fri, 13 Nov 2015, Roger Pau Monne wrote:
> > Due to the addition of HVMlite and the requirement to always provide a
> > valid
> > xc_domain_configuration_t, xc_domain_create now always takes an arch
> > domain
> > config, which can
In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some
parts of the libxenctrl API/ABI by disaggregating into separate
libraries.
This is v5 of that set of series against:
xen
qemu-xen
qemu-xen-traditional
mini-os
NB: Samuel+minios-devel will only get the mini-os
this is
thought to be a problem then we could consider adding an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell
r neither. For
consistency with con_initialise() with to the former here too.
With this con_initialise and con_disconnect now mirror each other.
Fix up a hard tab in the function while editing.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini &
time.
The only non-obvious bit is that we now open a proper xenforeignmemory
handle for xen_fmem instead of reusing the xen_xc handle.
Build tested with 4.0 .. 4.6 (inclusive) and the patches targetting
4.7 which adds these libraries.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
-
ins in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not
xendev->dev can be NULL or if anything elsewhere ensures the value
fits into an int. For now I just use a temporary xen_pfn_t to in
effect upcast the pointer from int* to xen_pfn_t*.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabel
ated patch series and which
contains more details.
Ian Campbell (9):
xen_console: correctly cleanup primary console on teardown.
xen: Switch to libxenevtchn interface for compat shims.
xen: Switch to libxengnttab interface for compat shims.
xen: Switch uses of xc_map_for
to xc_map_foreign_bulk.
In preparation for this switch both uses of xc_map_foreign_pages
(which both happen to be in xenfb_map_fb) to xc_map_foreign_bulk. This
simply requires allocating and passing a new err array (the same one
for both calls).
Signed-off-by: Ian Campbell <ian.campb...@citrix.
Using an existing libxenctrl handle after a fork was never
particularly safe (especially if foreign mappings existed at the time
of the fork) and the xc fd has been unavailable for many releases.
Reopen the handle after fork and therefore do away with xc_fd().
Signed-off-by: Ian Campbell
dle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.
Note that this patch does not add any support for actually using
libxengnttab, it just adjusts the existing shims.
Signed-off-by: Ian Campbell <ian.campb...@citr
- xc_domain_destroy
- xc_domain_getinfo
- xc_domain_max_vcpus
- xc_domain_setmaxmem
- xc_domain_unpause
- xc_evtchn_alloc_unbound
- xc_linux_build
This is another step towards only using Xen libraries which provide a
stable inteface.
Signed-off-by: Ian Campbell <ian.ca
On Fri, 2015-10-23 at 12:06 +0100, Stefano Stabellini wrote:
> On Wed, 21 Oct 2015, Ian Campbell wrote:
> > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > separate libraries which will provide backward and forward API and ABI
> > compatiblity.
>
On Fri, 2015-10-23 at 12:12 +0100, Stefano Stabellini wrote:
> @@ -2113,6 +2117,15 @@ if test "$xen_pci_passthrough" != "no"; then
> >fi
> > fi
> >
> > +if test "$xen_pv_domain_build" != "no"; then
> > + if test "$xen_pv_domain_build" = "yes" &&
> > + test "$xen" != "yes"; then
> > +
On Fri, 2015-10-23 at 12:06 +0100, Stefano Stabellini wrote:
> On Wed, 21 Oct 2015, Ian Campbell wrote:
> > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > separate libraries which will provide backward and forward API and ABI
> > compatiblity.
>
On Fri, 2015-10-23 at 12:35 +0100, Stefano Stabellini wrote:
> On Fri, 23 Oct 2015, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 12:12 +0100, Stefano Stabellini wrote:
> > > @@ -2113,6 +2117,15 @@ if test "$xen_pci_passthrough" != "no"; then
> > >
On Fri, 2015-10-23 at 12:31 +0100, Stefano Stabellini wrote:
> > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> > index 2a5f27a..38293b4 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -6,6 +6,17 @@
> > #include
> > #include
>
In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some
parts of the libxenctrl API/ABI by disaggregating into separate
libraries.
This is v4 of that set of series against:
xen
qemu-xen
qemu-xen-traditional
mini-os
NB: Samuel+minios-devel will only get the mini-os
On Wed, 2015-10-21 at 16:23 +0100, Ian Campbell wrote:
> [...]
> v4: Fixed all checkpatch errors.
> Disabled by default.
I botched this and it is no longer possible to turn it on. (I wonder if
anyone would have noticed in practice...)
> @@ -2113,6 +2117,15 @@ if test "$xe
this is
thought to be a problem then we could consider adding an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.
Build tested with 4.0 and 4.5.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
I not
time.
The only non-obvious bit is that we now open a proper xenforeignmemory
handle for xen_fmem instead of reusing the xen_xc handle.
Build tested with 4.0, 4.5 and the patches targetting 4.7 which adds
these libraries.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
dle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.
Build tested with 4.0 and 4.5.
Note that this patch does not add any support for actually using
libxengnttab, it just adjusts the existing shims.
Signed-off-by: Ian Campb
Using an existing libxenctrl handle after a fork was never
particularly safe (especially if foreign mappings existed at the time
of the fork) and the xc fd has been unavailable for many releases.
Reopen the handle after fork and therefore do away with xc_fd().
Signed-off-by: Ian Campbell
r neither. For
consistency with con_initialise() with to the former here too.
With this con_initialise and con_disconnect now mirror each other.
Fix up a hard tab in the function while editing.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
v4: New patch based on feedback to &q
ote that xc_evtchn_alloc_unbound functionality remains in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not size of the ptr)
---
hw/xen/xen_
- xc_domain_destroy
- xc_domain_getinfo
- xc_domain_max_vcpus
- xc_domain_setmaxmem
- xc_domain_unpause
- xc_evtchn_alloc_unbound
- xc_linux_build
This is another step towards only using Xen libraries which provide a
stable inteface.
Signed-off-by: Ian Campbell <ian.ca
ated patch series and which
contains more details.
Ian Campbell (9):
xen_console: correctly cleanup primary console on teardown.
xen: Switch to libxenevtchn interface for compat shims.
xen: Switch to libxengnttab interface for compat shims.
xen: Switch uses of xc_map_for
to xc_map_foreign_bulk.
In preparation for this switch both uses of xc_map_foreign_pages
(which both happen to be in xenfb_map_fb) to xc_map_foreign_bulk. This
simply requires allocating and passing a new err array (the same one
for both calls).
Build tested with 4.0 and 4.5.
Signed-off-by: Ian
xendev->dev can be NULL or if anything elsewhere ensures the value
fits into an int. For now I just use a temporary xen_pfn_t to in
effect upcast the pointer from int* to xen_pfn_t*.
Build tested with 4.0 and 4.5.
Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
---
v4: Ran checkp
On Fri, 2015-10-16 at 10:06 +0100, Stefano Stabellini wrote:
> > What's the reason for the "stumbling block" that requires the BIOS to
> > tear down the Xen ring prior to the OS being able to replace it? The
> > BIOS disk calls are all synchronous, so the ring wont be active when
> > the OS
On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote:
> > Can't you just teach SeaBIOS how to deal with your PV disks and then
> > only add that to your VM and forget about IDE/AHCI? I mean, that's how
> > it's done for virtio-blk, and it doesn't involve any insanities like
> > ripping out
On Fri, 2015-09-18 at 16:30 +0800, Tiejun Chen wrote:
> Although we already have 'gfx_passthru' in b_info, this doesn't suffice
> after we want to handle IGD specifically. Now we define a new field of
> type, gfx_passthru_kind, to indicate we're trying to pass IGD. Actually
> this means we can
On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote:
> On 08/10/15 18:24, Laszlo Ersek wrote:
> > Hi.
> >
> > Let's do an OVMF BoF at this year's KVM Forum too.
>
> Here's a preliminary task list
Thanks for including xen-devel in this. Was anyone from the Xen community
present at the BoF (so
On Tue, 2015-06-02 at 16:47 +0100, Ian Campbell wrote:
ping?
On Tue, 2015-06-02 at 16:08 +0100, Stefano Stabellini wrote:
the following is a collection of QEMU security fixes for PCI Passthrough
on Xen.
Part of this locks down the PCI cfg space emulation, which means we now
need a way
On Wed, 2015-06-17 at 14:52 +0100, Stefano Stabellini wrote:
On Wed, 17 Jun 2015, Ian Campbell wrote:
On Tue, 2015-06-02 at 16:47 +0100, Ian Campbell wrote:
ping?
The QEMU patch series is already upstream in QEMU and qemu-xen, so I
think we can apply this patch to libxl now.
Yes
c395657b03a1e2b7616d987e7078694874981979 Mon Sep 17 00:00:00 2001
From: Ian Campbell ian.campb...@citrix.com
Date: Mon, 1 Jun 2015 11:32:23 +0100
Subject: [PATCH] tools: libxl: allow permissive qemu-upstream pci
passthrough.
EMBARGOED UNTIL 2015-06-02 12:00 (WITH XSA-131 ET AL)
Since XSA-131 qemu-xen now
address
ranges), which (depending on system configuration) may be fatal to the
host.
This is CVE-2015-2756 / XSA-126.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Acked-by: Ian Campbell ian.campb
On Wed, 2015-04-01 at 09:05 +0800, Chen, Tiejun wrote:
@@ -699,9 +699,35 @@ working graphics passthrough. See the
XenVGAPassthroughTestedAdapters
Lhttp://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters wiki page
for currently supported graphics cards for gfx_passthru.
-gfx_passthru
On Wed, 2015-04-01 at 17:18 +0800, Chen, Tiejun wrote:
Currently Qemu maintainers are busy finalizing qemu 2.3, they don't
complete to review all associated qemu patch set. Although that don't
bring any change to our two patches on Xen side, I think we'd better
merge these patches until
On Mon, 2015-03-30 at 09:28 +0800, Chen, Tiejun wrote:
Sounds it should be a legacy fix to qemu-xen-tranditional :) So lets do
it now,
@@ -326,6 +326,10 @@ static char **
libxl__build_device_model_args_old(libxl__gc *gc,
}
if
On Fri, 2015-03-27 at 09:29 +0800, Chen, Tiejun wrote:
On 2015/3/26 18:06, Ian Campbell wrote:
On Thu, 2015-03-26 at 08:53 +0800, Chen, Tiejun wrote:
Hrm, OK. I suppose we can live with autodetect and igd both meaning igd
and whoever adds a new type will have to remember to add a check
On Thu, 2015-03-26 at 08:53 +0800, Chen, Tiejun wrote:
Hrm, OK. I suppose we can live with autodetect and igd both meaning igd
and whoever adds a new type will have to remember to add a check for
qemu-trad then.
When we really have to introduce a new type, this means we probably need
On Wed, 2015-03-25 at 09:10 +0800, Chen, Tiejun wrote:
+But when given as a string the Bgfx_passthru option describes the type
+of device to enable. Not this behavior is only supported with upstream
Note and the upstream...
+=item igd
+
+Enables graphics device PCI passthrough but force
On Wed, 2015-03-25 at 09:18 +0800, Chen, Tiejun wrote:
Actually my problem is that, I need to add a new parameter, 'flag', like
this, xc_assign_device(xxx,xxx,flag). So if I don't refine xc.c, tools
can't be compiled successfully. Or maybe you're suggesting I may isolate
this file while
1 - 100 of 280 matches
Mail list logo
