On Mon, Jan 14, 2019 at 6:19 AM Jan Beulich wrote:
>
> >>> 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_RIN
On Mon, Jan 14, 2019 at 7:12 AM Jan Beulich wrote:
>
> >>> 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 c
On Mon, Jan 14, 2019 at 6:58 AM Andrew Cooper wrote:
>
> 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 n
On Thu, Jan 10, 2019 at 4:22 AM Roger Pau Monné wrote:
>
> 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
flight 131953 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131953/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 broken
test-amd64-i386-xl-xsm
Hi all,
Sorry I bring up this question at here if it's duplicate due I googled
and found on the mailing list there have several related discussion for
enabling Xen on Hikey (I use Hikey but not Hikey960); but what I saw it
seems a new issue.
Below is the configuration at my side:
- Linux kernel:
On Tue, Jan 15, 2019 at 5:01 AM Boris Ostrovsky
wrote:
>
> On 1/11/19 10:13 AM, Souptick Joarder wrote:
> > Convert to use vm_insert_range_buggy() to map range of kernel
> > memory to user vma.
> >
> > This driver has ignored vm_pgoff. We could later "fix" these drivers
> > to behave according to
On Tue, Jan 15, 2019 at 4:58 AM Boris Ostrovsky
wrote:
>
> On 1/11/19 10:12 AM, Souptick Joarder wrote:
> > Convert to use vm_insert_range() to map range of kernel
> > memory to user vma.
> >
> > Signed-off-by: Souptick Joarder
>
> Reviewed-by: Boris Ostrovsky
>
> (although it would be good to m
flight 131952 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131952/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm broken
test-amd64-i386-libvirt
flight 131951 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131951/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm broken
test-amd
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 sock_mapping *map)
352 {
353 void *bytes;
flight 131949 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131949/
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-xl-rtds
On 1/14/19 10:48 AM, wangbo wrote:
> Create_active may called inside spinlock,replace GFP_KERNEL with GFP_ATOMIC
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.21&id=9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19
is queued and addresses this problem.
(Please run scrip
On 1/11/19 10:13 AM, Souptick Joarder wrote:
> Convert to use vm_insert_range_buggy() to map range of kernel
> memory to user vma.
>
> This driver has ignored vm_pgoff. We could later "fix" these drivers
> to behave according to the normal vm_pgoff offsetting simply by
> removing the _buggy suffix
On 1/11/19 10:12 AM, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
Reviewed-by: Boris Ostrovsky
(although it would be good to mention in the commit that you are also
replacing count with vma_pages(vma)
flight 131948 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131948/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm broken
build-amd64-pvops
flight 131955 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131955/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
build-amd64-freebs
Hi Jan,
One question below to make a decision on the way forward.
On Mon, 14 Jan 2019, Jan Beulich wrote:
> >>> 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, no
These changes work in conjunction with the signature
verification support for Xen I published recently.
Prior to this change, kexec supported the following
three modes of operation:
kexec_load:
- unverified loading of kernel into Linux (original mode)
- unverified loading of kernel into Xen
kexec
This change adds to Xen the kexec_file_load() entry point. The
kexec_file_load() is nearly identical to kexec_load(), but with the
added code to handle checking and handling of PECOFF Authenticode
signature verification.
Signed-off-by: Eric DeVolder
---
xen/common/kexec.c | 131
This change adds a new entry point in libxenctrl for the
kexec_file_load() operation. The code for kexec_file_load() is nearly
identical to kexec_load() other than the use of hypercall op
KEXEC_CMD_kexec_file_load rather than KEXEC_CMD_kexec_load.
Signed-off-by: Eric DeVolder
---
tools/libxc/xc_
This patch creates a new file that is in turn a patch that contains a
small number of changes needed in order to soldier through the
compilation of all the OpenSSL sources within Xen.
This patch is applied to OpenSSL in xen.spec.
Signed-off-by: Eric DeVolder
---
openssl-1.1.0i.patch | 378 +
This patch contains the files from the standalone utility that
are to be integrated into Xen to provide signature verification
of a PECOFF file.
- TrustedCert.h is the public root certificate for Oracle signed
binaries. This created by taking the DER encoded file at
http://cacerts.digicert.com
Changes needed to the xen/common/Makefile in order to stitch in the
compiling of OpenSSL as well as the PECOFF file decoder and signature
verification code.
Signed-off-by: Eric DeVolder
---
xen/common/Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/xen/common/Makefile b/xen/comm
This is a collection of small changes to Xen sources to
allow compiling of OpenSSL within Xen kernel. There are a
few necessary code stubs, but vast majority is header file
manipulation to pass compilation.
Note I created an include2/ directory to place all the
standard include files needed by the
The changes to xen.spec are needed to unpack, configure and
generate a Makefile for building OpenSSL within Xen.
The changes to xen.spec also apply patches which are primarily
the new files as part of the signature verification effort,
as well as some tweaks to Xen files to facilitate compiling of
On April 20, 2018, I posted to xen-devel an RFC inquiring about
support for signature verification of kexec within Xen:
https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01655.html
Since then, I've worked towards a solution. For the purposes of
understanding signature verification,
This is the Xen compatible makefile for use in building
OpenSSL within Xen.
This file was generated by capturing a "normal" build of
OpenSSL and parsing that build to ensure the correct list of
options and files.
Signed-off-by: Eric DeVolder
---
Makefile.openssl-1.1.0i | 480 +++
On Mon, Jan 14, 2019 at 3:48 PM Wei Liu wrote:
>
> 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
Am Mon, 14 Jan 2019 17:44:57 +
schrieb Wei Liu :
> - $(GIT) submodule update --init --recursive
> + [ -d .git ] && $(GIT) submodule update --init --recursive
This syntax fails, but this works for me:
if test -d .git ; then $(GIT) submodule update --init --recursive ;
flight 131947 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131947/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadowbroken
test-amd6
On Thu, Nov 08, 2018 at 03:23:41PM +0100, Igor Mammedov wrote:
> On Mon, 5 Nov 2018 02:40:39 +0100
> Samuel Ortiz wrote:
>
> > From: Yang Zhong
> >
> > When using the generated memory hotplug AML, the iasl
> > compiler would give the following error:
> >
> > dsdt.dsl 266: Return (MOST (_UID,
On 14/01/2019 17:16, Julien Grall wrote:
> Hi Andrew,
>
> On 14/01/2019 16:59, Andrew Cooper wrote:
>> On 14/01/2019 16:07, Julien Grall wrote:
>>> 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..22a86
On Mon, Jan 14, 2019 at 05:44:57PM +, Wei Liu wrote:
> On Mon, Jan 14, 2019 at 06:27:44PM +0100, Olaf Hering wrote:
> > Am Mon, 14 Jan 2019 17:11:56 +
> > schrieb Anthony PERARD :
> >
> > > I think it's fine to keep the current `submodule update` call where it
> > > is. We could just make
On Mon, Jan 14, 2019 at 6:47 AM Wei Liu wrote:
>
> 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
On 1/14/19 7:43 AM, Igor Druzhinin wrote:
> ping?
Applied to for-linus-4.21 (nka 5.0)
(this should have been copied to linux-ker...@vger.kernel.org and to me,
which is partly the reason why it was missed)
-boris
>
> On 10/12/2018 10:03, Xin Li wrote:
>> From: Talons Lee
>>
>> Commit e657fcc c
On Mon, 14 Jan 2019, Lars Kurth wrote:
> 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 accor
On Mon, Jan 14, 2019 at 06:27:44PM +0100, Olaf Hering wrote:
> Am Mon, 14 Jan 2019 17:11:56 +
> schrieb Anthony PERARD :
>
> > I think it's fine to keep the current `submodule update` call where it
> > is. We could just make it check that it's an actual git worktree by
> > checking for the pre
On Mon, Jan 14, 2019 at 05:11:56PM +, Anthony PERARD wrote:
[...]
>
> I think it's fine to keep the current `submodule update` call where it
> is. We could just make it check that it's an actual git worktree by
> checking for the presence of ".git" (file or directory) before executing
> git.
>
> are available in the Git repository at:
>
> https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git
> tags/pull-xen-20190114
>
> for you to fetch changes up to c6025bd197d0dbcc5067553fd12538d8b29383c2:
>
> xen-block: avoi
flight 131950 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131950/
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
Am Mon, 14 Jan 2019 17:11:56 +
schrieb Anthony PERARD :
> I think it's fine to keep the current `submodule update` call where it
> is. We could just make it check that it's an actual git worktree by
> checking for the presence of ".git" (file or directory) before executing
> git.
>
> Would th
Hi Jan,
On 14/01/2019 16:44, Jan Beulich wrote:
extern struct my_struct __start[];
extern struct my_struct __end[];
void test(const struct my_struct *);
void foo(int i) {
test(i ? __start : __end);
}
Your example doesn't contain any potential undefined behavior. So, how this
releva
On Mon, Jan 14, 2019 at 12:48:52PM +0100, Olaf Hering wrote:
> 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 conta
Hi Andrew,
On 14/01/2019 16:59, Andrew Cooper wrote:
On 14/01/2019 16:07, Julien Grall wrote:
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/
On 14/01/2019 16:07, Julien Grall wrote:
> 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
(+ Stefano and Oleksandr)
On 09/01/2019 06:54, vikram k.s. wrote:
Hello,
Hello,
I have seen this e-mail posted a couple of times. I will only answer to this
e-mail.
First of all, I would recommend to CC people that might be interested with the
topic, so the thread get flagged in our inbox.
Create_active may called inside spinlock,replace GFP_KERNEL with GFP_ATOMIC
Signed-off-by: wangbo
---
drivers/xen/pvcalls-front.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 77224d8..31bd3c9 100644
--- a/
Jan Beulich writes ("Re: [Xen-devel] [PATCH] x86emul: fix test harness and
fuzzer build dependencies"):
> So how do we make progress here? For the two changes that
> you dislike I don't formally need your ack, and I have Andrew's.
> I would (have to) respect an active NAK of yours, of course.
As
>>> 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
>>> 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
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 ++--
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
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
>>> 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
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: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 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
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 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
>>> 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 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
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 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
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
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
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
>>> 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
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 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,
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 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: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
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 ++--
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.
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 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
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
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
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
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 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.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 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
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 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
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: 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: 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: 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: 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 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 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
1 - 100 of 149 matches
Mail list logo
