On 12/01/2019 10:07, Lukas Bulwahn wrote:
> In the linux kernel MAINTAINERS file, largely
> "xen-devel@lists.xenproject.org (moderated for non-subscribers)"
> is used to refer to the xen-devel mailing list.
>
> The DRM DRIVERS FOR XEN section entry mentions
> xen-de...@lists.xen.org instead, but
On Fri, Jan 11, 2019 at 1:27 AM Roger Pau Monné wrote:
> On Fri, Jan 11, 2019 at 7:04 AM Christopher Clark
> wrote:
> >
> > 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:
> > > > +/*
> > > > + * Locking is organi
On Fri, Jan 11, 2019 at 3:54 AM Jan Beulich wrote:
>
> >>> On 07.01.19 at 08:42, wrote:
> > --- a/xen/common/argo.c
> > +++ b/xen/common/argo.c
> > @@ -17,7 +17,177 @@
> > */
> >
> > #include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > #include
> > +#inclu
Hello Jairo,
I was on vacations last week, and a regular CES rush the week before.
Please give me some time to sort out what else has happened during that period,
and I'll get back to you.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-d
>>> On 11.01.19 at 17:58, wrote:
> On Fri, 11 Jan 2019, Jan Beulich wrote:
>> >> > --- a/xen/arch/arm/setup.c
>> >> > +++ b/xen/arch/arm/setup.c
>> >> > @@ -772,8 +772,10 @@ void __init start_xen(unsigned long
>> >> > boot_phys_offset,
>> >> >
>> >> > /* Register Xen's load address as a bo
Hello, Hans!
Could you please take a look at my answers below and kindly let me know
if we are ready for (final?) v4 from your point of view.
Konrad, Xen-devel - do you have any objections/comments on this?
Thank you,
Oleksandr
On 12/17/18 9:37 AM, Oleksandr Andrushchenko wrote:
Hello, Hans!
On 02.01.19 19:15, Andrew Cooper wrote:
On 02/01/2019 16:56, Olaf Hering wrote:
On Mon, Dec 31, Andrew Cooper wrote:
* tbuf_size and tevt_mask
Given that xentrace can set them at runtime, and it is debugging
functionality, I don't see a plausible use the command line options at all.
'tbuf_si
On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
Block interrupts (in vmx_intr_assist()) for the duration of
processing a sync vm_event (similarly to the strategy
currently used for single-stepping). Otherwise, attempting
to emulate an instruction when requ
On 1/14/19 10:23 AM, Oleksandr Andrushchenko wrote:
> Hello, Hans!
> Could you please take a look at my answers below and kindly let me know
> if we are ready for (final?) v4 from your point of view.
Looks good, so I'm looking forward to a v4.
Regards,
Hans
>
> Konrad, Xen-devel - do y
>>> On 11.01.19 at 20:23, wrote:
> CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
> 2006, which was 12 years, 1 month, and 14 days ago.
Thanks for the very precise counting, the latter part which will be
wrong - even if just slightly - by the time you commit it ;-)
> Nevert
>>> On 14.01.19 at 10:34, wrote:
> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>> On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
>>> Block interrupts (in vmx_intr_assist()) for the duration of
>>> processing a sync vm_event (similarly to the strategy
>>> currently used for single-stepping). Otherwise
>>> On 11.01.19 at 19:04, wrote:
> On Fri, 11 Jan 2019, Jan Beulich wrote:
>> >>> On 11.01.19 at 03:14, 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
This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.12 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a fixed
>>> On 14.01.19 at 04:45, wrote:
> So let's keep the linker-accessible variable as a type that works for the
> linker (which really could be anything as long as you use the address, not
> the value), but name it something else - a name that screams "DON'T USE ME
> UNLESS YOU KNOW WHAT YOU'RE DOING
On 1/7/19 7:37 PM, Souptick Joarder wrote:
Remove duplicate header which is included twice.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
arch/arm/xen/mm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index cb44aa2..e1
Hey there!
I'm going to extend openOCD. There is a new lightwight TAP AHB-Controller
(AHBL) from Hilscher Companny. Depending on the chip thre is a ARM9 (netX50), a
RISCV(netIOL), or … below it.
I'm going to add support to openOCD for this TAP-Device. I’m new to openOCD
codebase.
I was look
Hi,
On 14/01/2019 09:34, Razvan Cojocaru wrote:
On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
Block interrupts (in vmx_intr_assist()) for the duration of
processing a sync vm_event (similarly to the strategy
currently used for single-stepping). Otherwi
On 14/01/2019 10:13, Juergen Gross wrote:
> I have started to include the version number of series associated to each
> feature. Can each owner send an update on the version number if the series
> was posted upstream?
>
> = Projects =
>
> == Hypervisor ==
>
> * Improvements to domain creation (v2
flight 131942 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131942/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win10-i386 broken
test-amd64-amd64-xl-qcow2
On 1/14/19 11:53 AM, Jan Beulich wrote:
On 14.01.19 at 10:34, wrote:
On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
Block interrupts (in vmx_intr_assist()) for the duration of
processing a sync vm_event (similarly to the strategy
currently used for sin
On 04/01/2019 14:04, Jan Beulich wrote:
>> dom0 (either PV, or PVH) cannot use the HPET
>> safely, even if it is restricted to just read-only access. Dom0 must
>> under no circumstance interact directly with the hardware HPET, as it is
>> a direct interrupt source.
> But reads don't cause interru
On Sun, Jan 13, 2019 at 09:17:44PM +0100, Olaf Hering wrote:
> On Wed, Nov 28, Wei Liu wrote:
>
> > OVMF has become dependent on OpenSSL, which it is included as a submodule.
> > Initialise submodules before building.
>
> > +++ b/tools/firmware/ovmf-makefile
> > build:
> > + $(GIT) submodule u
On Mon, Jan 14, 2019 at 9:32 AM Christopher Clark
wrote:
>
> On Fri, Jan 11, 2019 at 1:27 AM Roger Pau Monné wrote:
> > On Fri, Jan 11, 2019 at 7:04 AM Christopher Clark
> > wrote:
> > >
> > > On Thu, Jan 10, 2019 at 2:19 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Mon, Jan 7, 2019 at
>>> On 14.01.19 at 12:05, wrote:
> On 04/01/2019 14:04, Jan Beulich wrote:
>>> dom0 (either PV, or PVH) cannot use the HPET
>>> safely, even if it is restricted to just read-only access. Dom0 must
>>> under no circumstance interact directly with the hardware HPET, as it is
>>> a direct interrupt
On Mon, Jan 14, 2019 at 02:47:58AM -0700, Jan Beulich wrote:
> >>> On 11.01.19 at 20:23, wrote:
> > CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
> > 2006, which was 12 years, 1 month, and 14 days ago.
>
> Thanks for the very precise counting, the latter part which will be
For VPSADBW this likely was a result of bad copy-and-paste.
For VPS{L,R}LDQ comment and code were not in line, but then again the
comment also wasn't fully updated from the AVX2 original it got cloned
from.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x
First of all a PCLMULQDQ dependency was missing entirely. Add it as well
as AESNI and SHA to SSE2, as all of them act on vectors of integers,
whereas plain SSE supports vectors of single precision floats only. This
is in line with how e.g. binutils and gcc treat them.
Signed-off-by: Jan Beulich
-
Am Mon, 14 Jan 2019 11:28:57 +
schrieb Wei Liu :
> Are you saying that the breakage is shown when you put a snapshot of
> ovmf under xen.git? How does ovmf distribute their snapshot? How is that
> generated? Does it contain snapshots of submodules it needs already?
I export all required sourc
On 14/01/2019 11:39, Jan Beulich wrote:
> First of all a PCLMULQDQ dependency was missing entirely. Add it as well
> as AESNI and SHA to SSE2, as all of them act on vectors of integers,
> whereas plain SSE supports vectors of single precision floats only. This
> is in line with how e.g. binutils an
On Fri, Jan 11, 2019 at 06:16:45PM +, Peter Maydell wrote:
> On Fri, 11 Jan 2019 at 18:13, Anthony PERARD
> wrote:
> >
> > On Fri, Jan 11, 2019 at 06:09:41PM +, Anthony PERARD wrote:
> > > Patch "xen: add event channel interface for XenDevice-s" makes use of
> > > the type xenevtchn_port_
flight 131945 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131945/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops broken
build-i386
On 11/01/2019 21:35, Boris Ostrovsky wrote:
> On 1/11/19 7:08 AM, Juergen Gross wrote:
>> @@ -421,6 +424,11 @@ void xen_restore_time_memory_area(void)
>> if (ret != 0)
>> pr_notice("Cannot restore secondary vcpu_time_info (err %d)",
>>ret);
>> +
>> +out:
>>
ping?
On 10/12/2018 10:03, Xin Li wrote:
> From: Talons Lee
>
> Commit e657fcc clears cpu capability bit instead of using fake cpuid
> value, the EXTD should always be off for PV guest without depending
> on cpuid value. So remove the cpuid check in xen_read_msr_safe() to
> always clear the X2AP
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
>>> On 14.01.19 at 13:00, wrote:
> On 14/01/2019 11:39, Jan Beulich wrote:
>> First of all a PCLMULQDQ dependency was missing entirely. Add it as well
>> as AESNI and SHA to SSE2, as all of them act on vectors of integers,
>> whereas plain SSE supports vectors of single precision floats only. This
>>> On 07.01.19 at 08:42, wrote:
> Argo doesn't use compat hypercall or argument translation but can use some
> of the infrastructure for validating the hypercall argument structures to
> ensure that the struct sizes, offsets and compositions don't vary between 32
> and 64bit, so add that here in
erard/qemu-dm.git
tags/pull-xen-20190114
for you to fetch changes up to c6025bd197d0dbcc5067553fd12538d8b29383c2:
xen-block: avoid repeated memory allocation (2019-01-14 13:45:40 +)
Xen queue
* Xen PV backend 'qdevificati
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: 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: 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: 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
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
...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
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
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 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
On 1/14/19 7:44 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 ki
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
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
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
...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
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
...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
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: 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
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: 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 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: 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
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 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
>>> On 07.01.19 at 08:42, wrote:
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -23,16 +23,41 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> +#define MAX_RINGS_PER_DOMAIN128U
> +
> +/* All messages on the ring are padded to
Wei Liu writes ("Re: [PATCH v2 2/2] libxl: fix build (missing CLONE_NEWIPC) on
astonishingly old systems"):
> On Mon, Jan 14, 2019 at 02:47:58AM -0700, Jan Beulich wrote:
> > On 11.01.19 at 20:23, wrote:
> > > CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
> > > 2006, which
> On Jan 14, 2019, at 06:32, Roger Pau Monné wrote:
>
> On Mon, Jan 14, 2019 at 9:32 AM Christopher Clark
> wrote:
>>
>> I've written a document about the locking to add to the tree with the
>> series, and a copy is at github here:
>>
>> https://github.com/dozylynx/xen/blob/0cb95385eba696ecf4
>>> On 14.01.19 at 15:22, wrote:
> Wei Liu writes ("Re: [PATCH v2 2/2] libxl: fix build (missing CLONE_NEWIPC)
> on astonishingly old systems"):
>> On Mon, Jan 14, 2019 at 02:47:58AM -0700, Jan Beulich wrote:
>> > On 11.01.19 at 20:23, wrote:
>> > > CLONE_NEWIPC was introduced in Linux 2.6.19, o
On Fri, Dec 14, 2018 at 4:50 AM Razvan Cojocaru
wrote:
>
> Block interrupts (in vmx_intr_assist()) for the duration of
> processing a sync vm_event (similarly to the strategy
> currently used for single-stepping). Otherwise, attempting
> to emulate an instruction when requested by a vm_event
> rep
On 14/01/2019 11:56, Razvan Cojocaru wrote:
> On 1/14/19 11:53 AM, Jan Beulich wrote:
> On 14.01.19 at 10:34, wrote:
>>> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
> Block interrupts (in vmx_intr_assist()) for the duration of
> processi
On 1/14/19 4:42 PM, Juergen Gross wrote:
On 14/01/2019 11:56, Razvan Cojocaru wrote:
On 1/14/19 11:53 AM, Jan Beulich wrote:
On 14.01.19 at 10:34, wrote:
On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
On 12/14/18 6:49 AM, Razvan Cojocaru wrote:
Block interrupts (in vmx_intr_assist()) for the d
Hi all
The locking scheme seems to be remaining sticking point. The rest are
mostly cosmetic issues (FAOD, they still need to be addressed). Frankly
I don't think there is enough time to address all the technical details,
but let me sum up each side's position and see if we can reach an
amicable
flight 131946 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131946/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm broken
test-amd64-amd64-xl-qem
On 07/01/2019 07:42, 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/disable
> the arg
CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
2006, which was 12 years, 1 month, and 14 days ago.
Nevertheless apparently some people are trying to build Xen on systems
whose kernel headers are that old. Placate these people by providing
a fallback #define for CLONE_NEWIPC.
This reverts commit 1bce5f9baf0f4a4e50722f32b44afe4fdefc6b35.
This situation should be handled by disabling the dm restrict
feature, not silently falling back to lower protection.
Also this #ifdeffery is bad style.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_linux.c | 16 ++--
Some early kernesl are known not to reject unknown flags to
unshare(). There may be other problems.
CC: Jan Beulich
Signed-off-by: Ian Jackson
---
v3: New in this version of the series.
---
docs/features/qemu-deprivilege.pandoc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/docs/featur
On Mon, Jan 14, 2019 at 02:59:35PM +, Ian Jackson wrote:
> Some early kernesl are known not to reject unknown flags to
> unshare(). There may be other problems.
>
> CC: Jan Beulich
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
___
Xen-devel ma
On Mon, Jan 14, 2019 at 02:59:36PM +, Ian Jackson wrote:
> This reverts commit 1bce5f9baf0f4a4e50722f32b44afe4fdefc6b35.
>
> This situation should be handled by disabling the dm restrict
> feature, not silently falling back to lower protection.
>
> Also this #ifdeffery is bad style.
>
> Sign
On Mon, Jan 14, 2019 at 02:59:37PM +, Ian Jackson wrote:
> CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
> 2006, which was 12 years, 1 month, and 14 days ago.
>
> Nevertheless apparently some people are trying to build Xen on systems
> whose kernel headers are that old.
>>> On 07.01.19 at 08:42, wrote:
> @@ -666,6 +667,105 @@ ring_find_info(const struct domain *d, const struct
> argo_ring_id *id)
> return NULL;
> }
>
> +static struct argo_send_info *
> +send_find_info(const struct domain *d, const struct argo_ring_id *id)
As per the comment on patch 7,
Jan Beulich writes ("Re: [Xen-devel] [PATCH] x86emul: fix test harness and
fuzzer build dependencies"):
> On 21.12.18 at 15:16, wrote:
> > Why is this particular inter-directory dependency unusual ? Do we
> > plan to introduce similar MAKELEVEL-based invocation of dependency
> > directory makefi
>>> On 14.01.19 at 15:58, wrote:
> On 07/01/2019 07:42, Christopher Clark wrote:
>> --- a/xen/common/argo.c
>> +++ b/xen/common/argo.c
>> long
>> do_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
>
> I know I'm commenting on the wrong patch, but please use unsigned long
> cmd, so
There are ARM changes in here, and this bugfix is needed for 4.12, and
for backporting.
The one change not represented here is switching strncmp() with memcmp()
as recommended by Jan.
~Andrew
On 04/01/2019 17:17, Andrew Cooper wrote:
> When the command line parsing was updated to use const strin
Hi Juergen,
> On 14 Jan 2019, at 10:13, Juergen Gross wrote:
>
> This email only tracks big items for xen.git tree. Please reply for items you
> would like to see in 4.12 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use
Adding Juergen,
to make sure he is aware of the discussion, as this is an excellent summary of
the status of this series.
> On 14 Jan 2019, at 14:46, Wei Liu wrote:
>
> Hi all
>
> The locking scheme seems to be remaining sticking point. The rest are
> mostly cosmetic issues (FAOD, they still
On 07/01/2019 07:42, Christopher Clark wrote:
> diff --git a/docs/misc/xen-command-line.pandoc
> b/docs/misc/xen-command-line.pandoc
> index aea13eb..68d4415 100644
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -193,6 +193,21 @@ This allows domains access
Hi Jan,
On 14/01/2019 10:11, Jan Beulich wrote:
On 11.01.19 at 19:04, wrote:
On Fri, 11 Jan 2019, Jan Beulich wrote:
On 11.01.19 at 03:14, 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 th
>>> On 14.01.19 at 16:09, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH] x86emul: fix test harness and
> fuzzer build dependencies"):
>> On 21.12.18 at 15:16, wrote:
>> > Why is this particular inter-directory dependency unusual ? Do we
>> > plan to introduce similar MAKELEVEL-based invo
>>> On 14.01.19 at 16:41, wrote:
> Hi Jan,
>
> On 14/01/2019 10:11, Jan Beulich wrote:
> On 11.01.19 at 19:04, wrote:
>>> On Fri, 11 Jan 2019, Jan Beulich wrote:
>>> On 11.01.19 at 03:14, wrote:
> Hi Juergen, Jan,
>
> I spoke with Julien: we are both convinced that the unsig
>>> On 20.12.18 at 14:12, wrote:
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -473,6 +473,7 @@ static int vpmu_arch_initialise(struct vcpu *v)
>
> switch ( vendor )
> {
> +case X86_VENDOR_HYGON:
> case X86_VENDOR_AMD:
> ret = svm_vpmu_initialis
Hi Andrew,
On 14/01/2019 15:17, Andrew Cooper wrote:
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index ca655ff..22a86ec 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -212,7 +212,7 @@ EFI_STATUS __init fdt_add_uefi_nodes(EFI_SYSTEM_TABLE
On 1/13/19 10:20 PM, Wen Yang wrote:
> static checker warning:
> drivers/xen/pvcalls-front.c:373 alloc_active_ring()
> error: we previously assumed 'map->active.ring' could be null
>(see line 357)
>
> drivers/xen/pvcalls-front.c
> 351 static int alloc_active_ring(struct soc
>>> On 20.12.18 at 14:12, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce_amd.c
> +++ b/xen/arch/x86/cpu/mcheck/mce_amd.c
> @@ -162,7 +162,8 @@ mcequirk_lookup_amd_quirkdata(struct cpuinfo_x86 *c)
> {
> int i;
>
> -BUG_ON(c->x86_vendor != X86_VENDOR_AMD);
> +if (c->x86_vendor != X86_VEN
On Monday, January 14, 2019 10:53 AM, Jan Beulich wrote:
> > Hi Jan,
> >
> > On 14/01/2019 10:11, Jan Beulich wrote:
> > On 11.01.19 at 19:04, wrote:
> >>> On Fri, 11 Jan 2019, Jan Beulich wrote:
> >>> On 11.01.19 at 03:14, wrote:
> > Hi Juergen, Jan,
> >
> > I spoke with Juli
>>> On 20.12.18 at 14:14, wrote:
> Add Hygon Dhyana support to the acpi cpufreq subsystem by using the code
> path of AMD.
... cpufreq and cpuidle subsystems ...
> @@ -660,8 +661,9 @@ int cpufreq_cpu_init(unsigned int cpuid)
> {
> int ret;
>
> -/* Currently we only handle Intel and A
Hi Jan,
On 14/01/2019 15:52, Jan Beulich wrote:
On 14.01.19 at 16:41, wrote:
Hi Jan,
On 14/01/2019 10:11, Jan Beulich wrote:
On 11.01.19 at 19:04, wrote:
On Fri, 11 Jan 2019, Jan Beulich wrote:
On 11.01.19 at 03:14, wrote:
Hi Juergen, Jan,
I spoke with Julien: we are both convinced tha
The xenstore 'ring-page-order' is used globally for each blkback queue and
therefore should be read from xenstore only once. However, it is obtained
in read_per_ring_refs() which might be called multiple times during the
initialization of each blkback queue.
If the blkfront is malicious and the 'r
As 'be->blkif' is used for many times in connect_ring(), the stack variable
'blkif' is added to substitute 'be-blkif'.
Suggested-by: Paul Durrant
Signed-off-by: Dongli Zhang
Reviewed-by: Paul Durrant
Reviewed-by: Roger Pau Monné
---
drivers/block/xen-blkback/xenbus.c | 27 ++--
>>> On 14.01.19 at 17:26, wrote:
> On Monday, January 14, 2019 10:53 AM, Jan Beulich wrote:
>> > Hi Jan,
>> >
>> > On 14/01/2019 10:11, Jan Beulich wrote:
>> > On 11.01.19 at 19:04, wrote:
>> >>> On Fri, 11 Jan 2019, Jan Beulich wrote:
>> >>> On 11.01.19 at 03:14, wrote:
>> > Hi Juer
>>> On 14.01.19 at 17:28, wrote:
> Hi Jan,
>
> On 14/01/2019 15:52, Jan Beulich wrote:
> On 14.01.19 at 16:41, wrote:
>>> Hi Jan,
>>>
>>> On 14/01/2019 10:11, Jan Beulich wrote:
>>> On 11.01.19 at 19:04, wrote:
> On Fri, 11 Jan 2019, Jan Beulich wrote:
> On 11.01.19 at 03:14
1 - 100 of 149 matches
Mail list logo
