On 11/01/2019 08:15, Juergen Gross wrote:
> On 11/01/2019 00:10, Boris Ostrovsky wrote:
>> On 1/10/19 12:17 PM, Boris Ostrovsky wrote:
>>> On 1/10/19 11:14 AM, Juergen Gross wrote:
On 10/01/2019 16:34, Boris Ostrovsky wrote:
> On 1/10/19 5:07 AM, Juergen Gross wrote:
>>
>> +void
On 11/01/2019 00:10, Boris Ostrovsky wrote:
> On 1/10/19 12:17 PM, Boris Ostrovsky wrote:
>> On 1/10/19 11:14 AM, Juergen Gross wrote:
>>> On 10/01/2019 16:34, Boris Ostrovsky wrote:
On 1/10/19 5:07 AM, Juergen Gross wrote:
>
> +void xen_clocksource_suspend(void)
> +{
> +
On Thu, Jan 10, 2019 at 1:41 PM Eric Chanudet wrote:
>
> On 06/01/19 at 11:42pm, Christopher Clark wrote:
> >+memcpy_to_guest_ring(struct argo_ring_info *ring_info, uint32_t offset,
> >+ const void *src, XEN_GUEST_HANDLE(uint8_t) src_hnd,
> >+ uint32_t len)
On 11/01/2019 03:14, Stefano Stabellini wrote:
> Hi Juergen, Jan,
>
> I spoke with Julien: we are both convinced that the unsigned long
> solution is best. But Julien also did some research and he thinks that
> Jan's version (returning pointer type) not only does not help with
> MISRA-C, but also
On Thu, Jan 10, 2019 at 4:53 AM Jan Beulich wrote:
>
> >>> On 10.01.19 at 13:40, wrote:
> > On Thu, Jan 10, 2019 at 1:13 PM Jan Beulich wrote:
> >>
> >> >>> On 10.01.19 at 13:01, wrote:
> >> > On Thu, Jan 10, 2019 at 4:10 AM Christopher Clark
> > wrote:
> >> >>
> >> >> The second reason is
On Thu, Jan 10, 2019 at 3:57 AM Jan Beulich wrote:
>
> >>> On 10.01.19 at 12:24, wrote:
> > On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> > wrote:
> >> +static long
> >> +register_ring(struct domain *currd,
> >
> > If this is indeed the current domain (as the name suggests), why do
> >
On Thu, Jan 10, 2019 at 3:25 AM Roger Pau Monné wrote:
>
> On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> wrote:
> >
> > The register op is used by a domain to register a region of memory for
> > receiving messages from either a specified other domain, or, if specifying a
> > wildcard, any
On Thu, Jan 10, 2019 at 12:11 PM Eric Chanudet wrote:
>
> On 06/01/19 at 11:42pm, Christopher Clark wrote:
> >+/*
> >+ * The maximum size of an Argo ring is defined to be: 16GB
> >+ * -- which is 0x100 bytes.
> >+ * A byte index into the ring is at most 24 bits.
> >+ */
> >+#define
On Thu, Jan 10, 2019 at 8:16 AM Eric Chanudet wrote:
>
> On 06/01/19 at 11:42pm, Christopher Clark wrote:
> >+partner_rings_remove(struct domain *src_d)
>
> >+ring_info = ring_find_info(dst_d, _info->id);
> ring_find_info is defined later (PATCH 07/15), should it be moved to
>
On Thu, Jan 10, 2019 at 2:19 AM Roger Pau Monné wrote:
>
> On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> wrote:
> >
> > Initialises basic data structures and performs teardown of argo state
> > for domain shutdown.
> > diff --git a/xen/common/argo.c b/xen/common/argo.c
> > index
flight 131893 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131893/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2broken
test-amd64-amd64-libvirt-vhd
flight 131887 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131887/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair broken
test-amd64-i386-libvirt-pair
flight 131894 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131894/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm broken
test-amd64-amd64-libvirt-xsm 4
flight 131886 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131886/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsmbroken
test-amd64-i386-xl-pvshim
flight 131892 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131892/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386 broken
Hi Juergen, Jan,
I spoke with Julien: we are both convinced that the unsigned long
solution is best. But Julien also did some research and he thinks that
Jan's version (returning pointer type) not only does not help with
MISRA-C, but also doesn't solve the potential GCC problem either. A
> On Jan 9, 2019, at 10:24 PM, Razvan Cojocaru
> wrote:
>
> finish_type_change() returns a negative int on error, but the
> current code checks if ( !rc ). We also need to treat
> finish_type_change()'s return codes cumulatively in the
> success case (don't overwrite a 1 returned while
flight 131895 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131895/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
> On Jan 9, 2019, at 9:16 PM, Jan Beulich wrote:
>
On 09.01.19 at 11:41, wrote:
>> finish_type_change() returns a negative int on error, but the
>> current code checks if ( !rc ).
>
> For the purpose of determining the backporting scope (none here)
> it would be nice if in such a case
> On Jan 9, 2019, at 8:41 PM, Razvan Cojocaru wrote:
>
> finish_type_change() returns a negative int on error, but the
> current code checks if ( !rc ). Also properly indent the out:
> label while at it.
>
> Signed-off-by: Razvan Cojocaru
Acked-by: George Dunlap
On Thu, 10 Jan 2019, 15:36 Stefano Stabellini,
wrote:
> On Thu, 10 Jan 2019, Julien Grall wrote:
> > On Thu, 10 Jan 2019, 12:29 Stefano Stabellini,
> wrote:
> > On Thu, 10 Jan 2019, Jan Beulich wrote:
> > > >>> On 10.01.19 at 03:40, wrote:
> > > > On Wed, 9 Jan 2019, 18:43
On Wed, Jan 9, 2019 at 6:38 AM Jan Beulich wrote:
>
> >>> On 09.01.19 at 15:26, wrote:
> > On Wed, Jan 9, 2019 at 4:35 AM Jan Beulich wrote:
> >> >>> On 08.01.19 at 23:54, wrote:
> >> > On Mon, Jan 7, 2019 at 2:43 AM Christopher Clark
> >> > wrote:
> >> >> + */
> >> >> +struct
On 1/10/19 12:17 PM, Boris Ostrovsky wrote:
> On 1/10/19 11:14 AM, Juergen Gross wrote:
>> On 10/01/2019 16:34, Boris Ostrovsky wrote:
>>> On 1/10/19 5:07 AM, Juergen Gross wrote:
+void xen_clocksource_suspend(void)
+{
+ xen_clock_value_saved = xen_clocksource_read() -
On 06/01/19 at 11:42pm, Christopher Clark wrote:
+memcpy_to_guest_ring(struct argo_ring_info *ring_info, uint32_t offset,
+ const void *src, XEN_GUEST_HANDLE(uint8_t) src_hnd,
+ uint32_t len)
+{
+unsigned int mfns_index = offset >> PAGE_SHIFT;
+
On Thu, 10 Jan 2019, Julien Grall wrote:
> On Thu, 10 Jan 2019, 12:29 Stefano Stabellini, wrote:
> On Thu, 10 Jan 2019, Jan Beulich wrote:
> > >>> On 10.01.19 at 03:40, wrote:
> > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
>
> > > wrote:
> > >
> > >>
flight 131882 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131882/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm broken
test-amd64-amd64-pygrub
On 06/01/19 at 11:42pm, Christopher Clark wrote:
+/*
+ * The maximum size of an Argo ring is defined to be: 16GB
+ * -- which is 0x100 bytes.
+ * A byte index into the ring is at most 24 bits.
+ */
+#define XEN_ARGO_MAX_RING_SIZE (0x100ULL)
It looks like 16MB. Did I miss a <<10
On Thu, 10 Jan 2019, 12:29 Stefano Stabellini,
wrote:
> On Thu, 10 Jan 2019, Jan Beulich wrote:
> > >>> On 10.01.19 at 03:40, wrote:
> > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
> > > wrote:
> > >
> > >> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> > >> meant
On Thu, 10 Jan 2019, Stewart Hildebrand wrote:
> On Thursday, January 10, 2019 12:30 PM, Stefano Stabellini wrote:
> > On Thu, 10 Jan 2019, Jan Beulich wrote:
> > > >>> On 10.01.19 at 03:40, wrote:
> > > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
> > > > wrote:
> > > >
> > > >> Introduce a
On Thu, 10 Jan 2019, Stefano Stabellini wrote:
> diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h
> index 548b64d..3fa56ff 100644
> --- a/xen/include/xen/kernel.h
> +++ b/xen/include/xen/kernel.h
> @@ -66,27 +66,27 @@
> })
>
> extern char _start[], _end[], start[];
> -#define
On Thursday, January 10, 2019 12:30 PM, Stefano Stabellini wrote:
> On Thu, 10 Jan 2019, Jan Beulich wrote:
> > >>> On 10.01.19 at 03:40, wrote:
> > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
> > > wrote:
> > >
> > >> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> >
Use SYMBOL_HIDE in cases of comparisons and subtractions of:
_start, _end, _stext, _etext, _srodata, _erodata, _sinittext,
_einittext, __note_gnu_build_id_start, __note_gnu_build_id_end,
__lock_profile_start, __lock_profile_end, __initcall_start,
__initcall_end, __presmp_initcall_end,
Hi all,
This version of the series addresses all the latest comments by Jan. It
simplifies the implementation of SYMBOL and rename SYMBOL to
SYMBOL_HIDE.
I would like to note that I don't believe this implementation of
SYMBOL_HIDE gives us MISRA-C compliance. We'll likely have to change the
Use SYMBOL_HIDE in cases of comparisons and subtractions of:
_start, _end, __init_begin, __init_end, _stext, _etext,
__alt_instructions, __alt_instructions_end, __per_cpu_start,
__per_cpu_data_end, _splatform, _eplatform, _sdevice, _edevice,
_asdevice, _aedevice.
as by the C standard [1].
M3CM:
Use SYMBOL_HIDE in cases of comparisons and subtractions of:
_start, _end, __2M_rwdata_start, __2M_rwdata_end, _stext, _etext,
__end_vpci_array, __start_vpci_array, _stextentry, _etextentry,
__trampoline_rel_start, __trampoline_rel_stop, __trampoline_seg_start,
__trampoline_seg_stop
Introduce a macro, SYMBOL_HIDE, which is similar to RELOC_HIDE, but it
is meant to be used everywhere symbols such as _stext and _etext are
used in the code. It can take an array type as a parameter, and it
returns the same type.
SYMBOL_HIDE is needed when accessing symbols such as _stext and
On Thu, 10 Jan 2019, Jan Beulich wrote:
> >>> On 10.01.19 at 00:42, wrote:
> > --- a/xen/include/xen/compiler.h
> > +++ b/xen/include/xen/compiler.h
> > @@ -99,6 +99,16 @@
> > __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
> > (typeof(ptr)) (__ptr + (off)); })
> >
> > +/*
> > + *
On Thu, 10 Jan 2019, Jan Beulich wrote:
> >>> On 10.01.19 at 00:42, wrote:
> > --- a/xen/common/version.c
> > +++ b/xen/common/version.c
> > @@ -147,14 +147,14 @@ static int __init xen_build_init(void)
> > int rc;
> >
> > /* --build-id invoked with wrong parameters. */
> > -if (
On Thu, 10 Jan 2019, Jan Beulich wrote:
> >>> On 10.01.19 at 00:42, wrote:
> > --- a/xen/arch/x86/percpu.c
> > +++ b/xen/arch/x86/percpu.c
> > @@ -13,7 +13,7 @@ unsigned long __per_cpu_offset[NR_CPUS];
> > * context of PV guests.
> > */
> > #define INVALID_PERCPU_AREA (0x8000L -
On Thu, 10 Jan 2019, Jan Beulich wrote:
> >>> On 10.01.19 at 00:42, wrote:
> > @@ -1138,9 +1138,10 @@ void free_init_memory(void)
> > for ( i = 0; i < nr; i++ )
> > *(p + i) = insn;
> >
> > -set_pte_flags_on_range(__init_begin, len, mg_clear);
> > +
On Thu, 10 Jan 2019, Jan Beulich wrote:
> >>> On 10.01.19 at 03:40, wrote:
> > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini,
> > wrote:
> >
> >> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> >> meant to be used everywhere symbols such as _stext and _etext are used
> >>
On 1/10/19 11:14 AM, Juergen Gross wrote:
> On 10/01/2019 16:34, Boris Ostrovsky wrote:
>> On 1/10/19 5:07 AM, Juergen Gross wrote:
>>>
>>> +void xen_clocksource_suspend(void)
>>> +{
>>> + xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
>>
>> xen_clock_value_saved =
On Wed, 9 Jan 2019, Julien Grall wrote:
> Hi,
> Sorry for the formatting.
>
> On Wed, 9 Jan 2019, 18:43 Stefano Stabellini, wrote:
> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
> meant to be used everywhere symbols such as _stext and _etext are used
>
On Thu, Jan 10, 2019 at 5:40 PM Alexandru Stefan ISAILA
wrote:
>
>
> >>>
> >>> Newline.
> >>>
> +default:
> +return false;
> +}
> >>>
> >>> I'm not sure the switch is needed, you can't have a PFEC_write_access
> >>> for example if the p2m type is p2m_access_w or
>>>
>>> Newline.
>>>
+default:
+return false;
+}
>>>
>>> I'm not sure the switch is needed, you can't have a PFEC_write_access
>>> for example if the p2m type is p2m_access_w or p2m_access_rw, hence it
>>> seems like it could be simplified to only take the pfec into
>>>
>>> Newline.
>>>
+default:
+return false;
+}
>>>
>>> I'm not sure the switch is needed, you can't have a PFEC_write_access
>>> for example if the p2m type is p2m_access_w or p2m_access_rw, hence it
>>> seems like it could be simplified to only take the pfec into
On 1/10/19 11:07 AM, Juergen Gross wrote:
> Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable'
> sched_clock() interface") broke Xen guest time handling across
> migration:
>
> [ 187.249951] Freezing user space processes ... (elapsed 0.001 seconds) done.
> [ 187.251137] OOM
On 06/01/19 at 11:42pm, Christopher Clark wrote:
+partner_rings_remove(struct domain *src_d)
+ring_info = ring_find_info(dst_d, _info->id);
ring_find_info is defined later (PATCH 07/15), should it be moved to
this patch since it is now used here?
--
Eric Chanudet
On 10/01/2019 16:34, Boris Ostrovsky wrote:
> On 1/10/19 5:07 AM, Juergen Gross wrote:
>>
>> +void xen_clocksource_suspend(void)
>> +{
>> +xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
>
>
> xen_clock_value_saved = xen_sched_clock() maybe?
I wanted
On Thu, Jan 10, 2019 at 10:41 AM Alexandru Stefan ISAILA
wrote:
>
>
> >> +if ( altp2m_active(current->domain) )
> >> +p2m = p2m_get_altp2m(current);
> >> +if ( !p2m )
> >> +p2m = p2m_get_hostp2m(current->domain);
> >> +
> >> +gfn_lock(p2m, gfn, 0);
> >> +mfn =
> -Original Message-
> From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com]
> Sent: 10 January 2019 15:31
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu
> ; Razvan Cojocaru ; Konrad
> Rzeszutek Wilk ; George Dunlap
> ; Andrew Cooper ; Ian
On 1/10/19 5:07 AM, Juergen Gross wrote:
>
> +void xen_clocksource_suspend(void)
> +{
> + xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
xen_clock_value_saved = xen_sched_clock() maybe?
-boris
___
Xen-devel mailing
On Thu, 2018-12-20 at 12:05 +, Paul Durrant wrote:
> > -Original Message-
> >
> > The memory for the asynchronous ring and the synchronous channels
> > will
> > be allocated from domheap and mapped to the controlling domain
> > using the
> > foreignmemory_map_resource interface.
On 1/10/19 11:58 AM, Paul Durrant wrote:
-Original Message-
Why re-invent the wheel here? The ioreq infrastructure already does
pretty much everything you need AFAICT.
Paul
I wanted preseve as much as possible from the existing vm_event DOMCTL
interface and add only the
On Wed, Jan 09, 2019 at 01:18:12PM -0800, Maran Wilson wrote:
> On 1/9/2019 11:53 AM, Boris Ostrovsky wrote:
> > On 1/9/19 6:53 AM, Stefano Garzarella wrote:
> > > Hi Liam,
> > >
> > > On Tue, Jan 8, 2019 at 3:47 PM Liam Merwick
> > > wrote:
> > > > QEMU sets the hvm_modlist_entry in
From: Paul Durrant
This patch adds the transformations necessary to get dataplane/xen-block.c
to build against the new XenBus/XenDevice framework. MAINTAINERS is also
updated due to the introduction of dataplane/xen-block.h.
NOTE: Existing data structure names are retained for the moment. These
From: Paul Durrant
I have made many significant contributions to the Xen code in QEMU,
particularly the recent patches introducing a new PV device framework.
I intend to make further significant contributions, porting other PV back-
ends to the new framework with the intent of eventually
From: Paul Durrant
This is a purely cosmetic patch that purges the name 'ioreq' from struct,
variable and field names. (This name has been problematic for a long time
as 'ioreq' is the name used for generic I/O requests coming from Xen).
The patch replaces 'struct ioreq' with a new
From: Paul Durrant
The new xen-block XenDevice implementation requires the same core
dataplane as the legacy xen_disk implementation it will eventually replace.
This patch therefore copies the legacy xen_disk.c source module into a new
dataplane/xen-block.c source module as the basis for the new
From: Paul Durrant
...that maintains compatibility with existing Xen toolstacks.
Xen toolstacks instantiate PV backends by simply writing information into
xenstore and expecting a backend implementation to be watching for this.
This patch adds a new 'xen-backend' module to allow individual
From: Paul Durrant
This is a purely cosmetic patch that substitutes the old 'struct XenBlkDev'
name with 'XenBlockDataPlane' and 'blkdev' field/variable names with
'dataplane', and then does necessary fix-up to adhere to coding style.
No functional change.
Signed-off-by: Paul Durrant
From: Paul Durrant
...and wire in the dataplane.
This patch adds the remaining code to make the xen-block XenDevice
functional. The parameters that a block frontend expects to find are
populated in the backend xenstore area, and the 'ring-ref' and
'event-channel' values specified in the
From: Tim Smith
When I/O consists of many small requests, performance is improved by
batching them together in a single io_submit() call. When there are
relatively few requests, the extra overhead is not worth it. This
introduces a check to start batching I/O requests via blk_io_plug()/
From: Paul Durrant
This backend has now been replaced by the 'xen-qdisk' XenDevice.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
Signed-off-by: Anthony PERARD
---
hw/block/Makefile.objs |1 -
hw/block/xen_disk.c| 1011
2 files
From: Tim Smith
The xen-block dataplane currently allocates memory to hold the data for
each request as that request is used, and frees it afterwards. Because
it requires page-aligned blocks, this interacts poorly with non-page-
aligned allocations and balloons the heap.
Instead, allocate the
From: Paul Durrant
Not all of the code duplicated from xen_disk.c is required as the basis for
the new dataplane implementation so this patch removes extraneous code,
along with the legacy #includes and calls to the legacy xen_pv_printf()
function. Error messages are changed to be reported using
From: Tim Smith
If the I/O ring is full, the guest cannot send any more requests
until some responses are sent. Only sending all available responses
just before checking for new work does not leave much time for the
guest to supply new work, so this will cause stalls if the ring gets
full. Also,
From: Paul Durrant
This patch adds create and destroy function for XenBlockDevice-s so that
they can be created automatically when the Xen toolstack instantiates a new
PV backend via xenstore. When the XenBlockDevice is created this way it is
also necessary to create a 'drive' which matches the
From: Paul Durrant
This is a purely cosmetic patch that purges remaining use of 'blk' and
'ioreq' in local function names, and then makes sure all functions are
prefixed with 'xen_block_'.
No functional change.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
Signed-off-by: Anthony
It is broken since Xen 4.9 [1] and it will not build in Xen 4.12. Also,
it is not built by default since QEMU 2.6.
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-09/msg00313.html
Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellini
---
configure | 17 --
xend have been replaced by libxenlight (libxl) for many Xen releases
now.
Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellini
---
hw/xenpv/xen_machine_pv.c | 2 +-
include/hw/xen/xen.h | 2 +-
qemu-options.hx | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
From: Paul Durrant
...and xen_backend.h to xen-legacy-backend.h
Rather than attempting to convert the existing backend infrastructure to
be QOM compliant (which would be hard to do in an incremental fashion),
subsequent patches will introduce a completely new framework for Xen PV
backends.
From: Paul Durrant
The legacy PV backend infrastructure provides functions to bind, unbind
and send notifications to event channnels. Similar functionality will be
required by XenDevice implementations so this patch adds the necessary
support.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony
From: Paul Durrant
This patch adds the basic boilerplate for a 'XenBus' object that will act
as a parent to 'XenDevice' PV backends.
A new 'XenBridge' object is also added to connect XenBus to the system bus.
The XenBus object is instantiated by a new xen_bus_init() function called
from the
From: Paul Durrant
This patch adds a new source module, xen-bus-helper.c, which builds on
basic libxenstore primitives to provide functions to create (setting
permissions appropriately) and destroy xenstore areas, and functions to
'printf' and 'scanf' nodes therein. The main xen-bus code then
From: Paul Durrant
The legacy PV backend infrastructure provides functions to map, unmap and
copy pages granted by frontends. Similar functionality will be required
by XenDevice implementations so this patch adds the necessary support.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
From: Paul Durrant
This patch adds new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived
from a common 'xen-block' parent type. These will eventually replace the
'xen_disk' (note the underscore rather than hyphen) legacy PV backend but
it is illustrative to build up the implementation
From: Peter Maydell
Coverity (CID 796599) points out that xen_pt_setup_vga() trusts
the rom->size field in the BIOS ROM from a PCI passthrough VGA
device, and uses it as an index into the memory which contains
the BIOS image. A corrupt BIOS ROM could therefore cause us to
index off the end of
tags/pull-xen-20190110
for you to fetch changes up to 24edb91f5009fa941e1294aaf4bb2103d9ad077e:
xen-block: avoid repeated memory allocation (2019-01-10 11:25:17 +)
xen queue
* Xen PV backend 'qdevification'.
Starting
From: Zhao Yan
For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
doesn't support INTx mode, so its machine irq read from host sysfs is 0.
In that case, report PCI_INTERRUPT_PIN as 0 to guest and let passthrough
continue.
Reviewed-by: Roger Pau Monné
Signed-off-by: Zhao Yan
From: Paul Durrant
A Xen PV frontend communicates its state to the PV backend by writing to
the 'state' key in the frontend area in xenstore. It is therefore
necessary for a XenDevice implementation to be notified whenever the
value of this key changes.
This patch adds code to do this as
Hi all,
just a quick note to let you know that the next developer summit will be held
in the US (in Chicago) from July 9-11. The event website including the CfP
should be up in the next 2-3 weeks
Best Regards
Lars
___
Xen-devel mailing list
flight 131884 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131884/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 broken
>>> On 10.01.19 at 13:40, wrote:
> On Thu, Jan 10, 2019 at 1:13 PM Jan Beulich wrote:
>>
>> >>> On 10.01.19 at 13:01, wrote:
>> > On Thu, Jan 10, 2019 at 4:10 AM Christopher Clark
> wrote:
>> >>
>> >> The second reason is about avoiding exposing the Xen virtual memory
>> >> allocator directly
>>> On 10.01.19 at 13:26, wrote:
> On Thu, Jan 10, 2019 at 12:52 PM Jan Beulich wrote:
>>
>> >>> On 10.01.19 at 11:19, wrote:
>> > aOn Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
>> > wrote:
>> >>
>> >> +/* Xen command line option to enable argo */
>> >> +static bool __read_mostly
On Thu, Jan 10, 2019 at 1:13 PM Jan Beulich wrote:
>
> >>> On 10.01.19 at 13:01, wrote:
> > On Thu, Jan 10, 2019 at 4:10 AM Christopher Clark
> > wrote:
> >>
> >> The second reason is about avoiding exposing the Xen virtual memory
> >> allocator directly to frequent guest-supplied size
flight 131883 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131883/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64-xsmbroken
On Thu, Jan 10, 2019 at 12:52 PM Jan Beulich wrote:
>
> >>> On 10.01.19 at 11:19, wrote:
> > aOn Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> > wrote:
> >>
> >> +/* Xen command line option to enable argo */
> >> +static bool __read_mostly opt_argo_enabled;
> >> +boolean_param("argo",
On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
wrote:
>
> Queries for data about space availability in registered rings and
> causes notification to be sent when space has become available.
>
> The hypercall op populates a supplied data structure with information about
> ring state, and if
>>> On 10.01.19 at 13:01, wrote:
> On Thu, Jan 10, 2019 at 4:10 AM Christopher Clark
> wrote:
>>
>> The second reason is about avoiding exposing the Xen virtual memory
>> allocator directly to frequent guest-supplied size requests for
>> contiguous regions (of up to 16GB).
>
> As said in
On Thu, Jan 10, 2019 at 4:10 AM Christopher Clark
wrote:
>
> Thanks for the review, Roger. Replies inline below.
>
> On Wed, Jan 9, 2019 at 10:57 AM Roger Pau Monné wrote:
> >
> > to.On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> > wrote:
> > >
> > > sendv operation is invoked to perform a
>>> On 10.01.19 at 12:24, wrote:
> On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> wrote:
>> +static long
>> +register_ring(struct domain *currd,
>
> If this is indeed the current domain (as the name suggests), why do
> you need to pass it around? Or else just name the parameter d.
When
>>> On 10.01.19 at 11:19, wrote:
> aOn Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> wrote:
>>
>> +/* Xen command line option to enable argo */
>> +static bool __read_mostly opt_argo_enabled;
>> +boolean_param("argo", opt_argo_enabled);
>
> I would drop the opt_* prefix, new options added
On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
wrote:
>
> Takes a single argument: a handle to the ring unregistration struct,
> which specifies the port and partner domain id or wildcard.
>
> The ring's entry is removed from the hashtable of registered rings;
> any entries for pending
flight 131874 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131874/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64broken
On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
wrote:
>
> The register op is used by a domain to register a region of memory for
> receiving messages from either a specified other domain, or, if specifying a
> wildcard, any domain.
>
> This operation creates a mapping within Xen's private
aOn Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
wrote:
>
> Initialises basic data structures and performs teardown of argo state
> for domain shutdown.
>
> Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
>
> Introduces a new Xen command line parameter 'argo': bool to
Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable'
sched_clock() interface") broke Xen guest time handling across
migration:
[ 187.249951] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 187.251137] OOM killer disabled.
[ 187.251137] Freezing remaining
> -Original Message-
> >>>
> >>> Why re-invent the wheel here? The ioreq infrastructure already does
> >>> pretty much everything you need AFAICT.
> >>>
> >>>Paul
> >>
> >> I wanted preseve as much as possible from the existing vm_event DOMCTL
> >> interface and add only the necessary
flight 131890 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131890/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
1 - 100 of 107 matches
Mail list logo
