>>> 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
>> in the code. It can take an array type as a parameter,
>>> 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)); })
>
> +/*
> + * Similar to RELOC_HIDE, but written to be used with symbols such
>>> 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);
> +set_pte_flags_on_range(SYMBOL(__init_begin), len, mg_clear);
> init_domhea
>>> 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 - (long)__per_cpu_start)
> -#define PERCPU_ORDER get_orde
>>> 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 ( __note_gnu_build_id_end <= &n[0] )
> +if ( SYMBOL(__no
On Mon, Jan 7, 2019 at 8:43 AM Christopher Clark
wrote:
>
> A convenience for working on development of the argo subsystem:
> setting a #define variable enables additional debug messages.
>
> Signed-off-by: Christopher Clark
Reviewed-by: Roger Pau Monné
> ---
> v2 #03 feedback, Jan: fix ifdef/
>> +if ( altp2m_active(current->domain) )
>> +p2m = p2m_get_altp2m(current);
>> +if ( !p2m )
>> +p2m = p2m_get_hostp2m(current->domain);
>> +
>> +gfn_lock(p2m, gfn, 0);
>> +mfn = p2m->get_entry(p2m, gfn, &p2mt, &access, 0, NULL, NULL);
>> +gfn_unlock(p2m, gfn, 0
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
> -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
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 fre
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 enable/di
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 addre
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
test-amd64-i386-xl-qemuu-dmrestr
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 notificat
>>> 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 re
>>> 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 al
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 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 anothe
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 insu
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", opt_ar
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
test-amd64-i
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 requests
>>> 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 opt_argo_
>>> 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
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
test-amd64-i386-libvirt-qemuu-de
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
Xen-devel@l
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 follows
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
emu-dm.git
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&#x
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
Si
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 increme
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 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 use
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 same
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 Pe
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. Hence
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(-)
diff
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 PERARD
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 --
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 c
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 ma
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: 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()/
blk_io_un
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 changed,
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 frontend
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 XenD
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
Acked-by:
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 'XenBlockReque
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 removing
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
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 load_linux(
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 necessa
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. Unlike
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 l
> -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 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 = p2m->
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 xen_clocksour
On 06/01/19 at 11:42pm, Christopher Clark wrote:
+partner_rings_remove(struct domain *src_d)
+ring_info = ring_find_info(dst_d, &send_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 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
>>>
>>> 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 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 p2m_
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
> in
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 = xen
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
> >> i
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);
> > +set_pte_flags_on_range(SY
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:
> > --- 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/include/xen/compiler.h
> > +++ b/xen/include/xen/compiler.h
> > @@ -99,6 +99,16 @@
> > __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
> > (typeof(ptr)) (__ptr + (off)); })
> >
> > +/*
> > + * Simila
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 _ete
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 __per_cpu_star
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
imple
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, __ctors_star
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
> > >
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 is
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 m
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 to
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 somewhe
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 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:
> > >
> > >> Int
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;
+void
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() - xen_sc
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 argo_ri
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 Ste
> 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 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 you
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 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 process
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
test-amd64-amd64-pa
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
descripti
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 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 host-install(4
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 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
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 6f782f7..8
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, &send_info->id);
> ring_find_info is defined later (PATCH 07/15), should it be moved to
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 XEN_ARGO_M
1 - 100 of 107 matches
Mail list logo
