On Thu, Dec 20, 2018 at 12:33 AM Jan Beulich wrote:
>
> >>> On 20.12.18 at 06:58, wrote:
> > On Wed, Dec 12, 2018 at 3:53 AM Jan Beulich wrote:
> >> >>> On 01.12.18 at 02:32, wrote:
> >> > +static struct argo_ring_info *
> >> > +argo_ring_find_info_by_match(const struct domain *d, uint32_t port
On Fri, Jan 04, 2019 at 12:13:09AM -0800, Christopher Clark wrote:
> 2) the p2m type of the guest-supplied memory for the ring.
>
> Roger raised a query about not pinning the p2m type of memory
> used for the ring, and my response on 21st December is here:
>
> https://lists.xenproject.org/archive
flight 131723 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131723/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 131518
test-amd64-amd64-xl-qemuu-win7-amd6
>>> On 02.01.19 at 19:20, wrote:
> On Wed, 14 Nov 2018, Jan Beulich wrote:
>> >>> On 13.11.18 at 23:02, wrote:
>> > On Tue, 13 Nov 2018, Jan Beulich wrote:
>> >> >>> On 13.11.18 at 14:17, wrote:
>> >> > On 13/11/2018 12:56, Jan Beulich wrote:
>> >> > On 13.11.18 at 00:06, wrote:
>> >> >>> @
> -Original Message-
> On 12/19/2018 09:23 PM, Dongli Zhang wrote:
> > 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 time
On Fri, Dec 21, 2018 at 03:05:03PM -0800, Christopher Clark wrote:
> On Thu, Dec 20, 2018 at 4:52 AM Roger Pau Monné wrote:
> >
> > On Wed, Dec 19, 2018 at 09:41:59PM -0800, Christopher Clark wrote:
> > > On Wed, Dec 12, 2018 at 8:48 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Fri, Nov 30
>>> On 28.12.18 at 17:30, wrote:
> On 06/12/2018 10:59, Jan Beulich wrote:
> On 03.12.18 at 17:18, wrote:
>>> --- a/xen/include/asm-x86/cpufeatures.h
>>> +++ b/xen/include/asm-x86/cpufeatures.h
>>> @@ -25,6 +25,7 @@ XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /*
> SMAP gets used by
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 03 January 2019 18:20
> To: Andrew Cooper
> Cc: Stefano Stabellini ; xen-de...@lists.xen.org;
> julien.gr...@arm.com; jbeul...@suse.com; Paul Durrant
>
> Subject: Re: [Xen-devel] [PATCH for-4.12] xen/i
>>> On 21.12.18 at 13:44, wrote:
> On 21/12/2018 12:08, Jan Beulich wrote:
> On 21.12.18 at 00:40, wrote:
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -636,55 +636,76 @@ trace feature is only enabled in debugging builds of
>>> Xen.
>>>
Ping Anthony?
I dropped your R-b on v6 since I screwed it up. Are you ok with v7? It should
be back to how it was but with some whitespace fixes.
Paul
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 20 December 2018 17:15
> To: qemu-de...@nongnu.org;
Andrii,
Sorry for not responding sooner.
First of all happy new year!
I seriously overlooked the firmware update. I will attempt that next week
and see if the boot is successful.
Thanks for the help.
Best regards,
Jairo
2018年12月28日(金) 17:39 Andrii Anisov :
>
>
> On 28.12.18 10:28, Andrii A
>>> On 21.12.18 at 13:55, wrote:
> On 21/12/2018 12:13, Jan Beulich wrote:
> On 21.12.18 at 00:40, wrote:
>>> @@ -271,6 +272,26 @@ int parse_boolean(const char *name, const char *s,
>>> const char *e)
>>> return -1;
>>> }
>>>
>>> +int cmdline_strcmp(const char *frag, const char *name
Ping Anthony & Kevin?
I believe this version is purged of all legacy interface use.
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 20 December 2018 17:15
> To: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org
> Cc: Paul Du
On Thu, Jan 03, 2019 at 03:42:18PM -0500, Boris Ostrovsky wrote:
> On 1/3/19 12:45 PM, Roger Pau Monné wrote:
> > Hello,
> >
> > While looking at some tangential issues I realized that the 'VGA Not
> > Present' flag that Xen currently sets for PVH DomUs might be slightly
> > different from what we
>>> On 21.12.18 at 16:21, wrote:
> On Fri, Dec 21, 2018 at 03:13:50AM -0700, Jan Beulich wrote:
> On 20.12.18 at 16:29, wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -1514,6 +1514,55 @@ static int assign_device(struct domain *d, u16 seg,
>>> u8
>>> On 21.12.18 at 15:16, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH] x86emul: fix test harness and
> fuzzer build dependencies"):
>> On 20.12.18 at 17:05, wrote:
>>> On 20.12.18 at 16:23, wrote:
>> >> Ie, it is there to satisfy the requirement I mention above, that the
>> >> dependen
The patch introduces a cached attribute (next_elem) in csched2_runqueue_data
which will keep track of next runq candidate which has the maximum credit
score within the runqueue. This will save unnecessary tree traversal during
the time of scheduling. This element will be populated during the remova
The patch optimized the sorted credit2 runq from simple linked list to
rb-tree implementation. This way we will gain performance and
scalability when the number of vCPUs are huge.
Signed-off-by: Praveen Kumar
---
Changes since v1:
* Renamed the rb_runq_insert
* Corrected the next probable runq
Hi All,
This is the continued work with respect to rb-tree usage in Credit2, as
mentioned in previous conversations
https://lists.xen.org/archives/html/xen-devel/2017-06/msg01968.html
https://lists.xen.org/archives/html/xen-devel/2018-04/msg00119.html
The patch optimized the Credit2 runqueue fro
>>> On 01.01.19 at 20:46, wrote:
> On Fri, Dec 21, 2018 at 06:55:38PM +, Andy Smith wrote:
>> Is it worth me moving this guest to a test host without pcid=0 to
>> see if it crashes it, meanwhile keeping production hosts with
>> pcid=0? And then putting pcid=0 on the test host to see if it
>> s
>>> On 28.12.18 at 17:11, wrote:
> On 28/12/2018 15:43, Roger Pau Monné wrote:
>> On Fri, Dec 28, 2018 at 12:39:35PM +, Andrew Cooper wrote:
>>> AMD hardware before Zen doesn't safe/restore the FPU error pointers
>>> unless an unmasked FPU exception is pending. Zen processors have a
>>> featu
>>> On 31.12.18 at 12:57, wrote:
> On 31/12/2018 11:37, Andrew Cooper wrote:
>> +/*
>> + * Encoding for svm_get_insn_len(). We take X86EMUL_OPC() for the main
>> + * opcode, shifted left to make room for the ModRM byte.
>> + */
>> +#define INSTR_ENC(opc, modrm) (((unsigned int)(opc) << 8) | (modr
As that seems to be the prevailing style.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
MAINTAINERS | 66 ++--
Hello,
Current arrangement of the PCI code puts it under vendor agnostic IOMMU
maintainership, which is IMO not very accurate. The aim of this series
is to add a new maintainership section containing the PCI code in Xen,
and add myself as reviewer.
Due to my work on PVH Dom0, which makes heavy us
It makes no sense for io.c to be on the top level passthrough
directory, since it's x86 specific.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
---
xen/drivers/passthrough/Makefile | 3 ---
xen/drivers/passthrough/x86/Makefile | 1 +
xen/drivers/passthrough/{
And add myself as reviewer.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
passthrough/x86 is tied to the x86 code, and as such put it under x86
maintainership.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
M
On Thu, Jan 03, 2019 at 12:40:18PM +, Anthony PERARD wrote:
> On Fri, Dec 21, 2018 at 03:36:18PM +, Ian Jackson wrote:
> > Anthony PERARD writes ("[PATCH v7 06/14] libxl_qmp: Implementation of
> > libxl__ev_qmp_*"):
> > > +static void qmp_ev_set_state(libxl__gc *gc, libxl__ev_qmp *ev,
> >
(Skipping the parts where you were just agreeing with me...)
Anthony PERARD writes ("Re: [PATCH v7 06/14] libxl_qmp: Implementation of
libxl__ev_qmp_*"):
> On Fri, Dec 21, 2018 at 03:36:18PM +, Ian Jackson wrote:
> > > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>
On Fri, Jan 04, 2019 at 11:21:11AM +, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [PATCH v7 06/14] libxl_qmp: Implementation of
> libxl__ev_qmp_*"):
> > On Fri, Dec 21, 2018 at 03:36:18PM +, Ian Jackson wrote:
> > > > +while (ev->tx_buf_off < ev->tx_buf_len) {
> > > > +r =
On Mon, Dec 24, 2018 at 12:46:06PM +, Andrew Cooper wrote:
> When it comes to the IOMMU setup, there should not be a difference
> between PV and PVH, because the difference in virtulisation mode is not
> relevant to how the devices on the system behave.
>
> IMO, map-inclusive should be disable
On 04/01/2019 12:04, Roger Pau Monné wrote:
> On Mon, Dec 24, 2018 at 12:46:06PM +, Andrew Cooper wrote:
>> When it comes to the IOMMU setup, there should not be a difference
>> between PV and PVH, because the difference in virtulisation mode is not
>> relevant to how the devices on the system
On Fri, Dec 21, 2018 at 02:30:05PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v7 01/14] libxl: Enhance libxl__sendmsg_fds to
> deal with EINTR and EWOULDBLOCK"):
> > This patch change the behavior of libxl__sendmsg_fds to retry sendmsg on
> > EINTR error.
> >
> > This patch also a
On Mon, Dec 31, 2018 at 03:16:20PM +, Andrew Cooper wrote:
> +Controls for the dom0 IOMMU setup.
> +
> +* The `passthrough` boolean controls whether IOMMU translation
> functionality
> +is disabled for devices in dom0 (`passthrough=1`) or whether the IOMMU is
> +used to ensure that d
On Mon, Dec 31, 2018 at 03:16:21PM +, Andrew Cooper wrote:
> Having a pvh boolean isn't ideal. If we gain a 3rd virtulsation mode,
> what does `dom0=no-pvh` mean?
>
> Change the syntax to be "dom0 = pv | pvh" which offers an option to more
> obviously select PV mode. Hide both options behind
Hello,
On Fri, Jan 04, 2019 at 03:16:32AM -0700, Jan Beulich wrote:
> >>> On 01.01.19 at 20:46, wrote:
> > I did move the suspect guest to a test host that does not have
> > pcid=0 and 10 days later it crashed too:
>
> Thanks for trying this. It is now pretty clear that we need a means
> to repr
On Mon, Dec 31, 2018 at 03:16:22PM +, Andrew Cooper wrote:
> This option is unique to x86 PV dom0's, but it is not sensible to have a
> catch-all which blindly maps all non-RAM regions into the IOMMU.
>
> The map-reserved option remains, and covers all the buggy firmware issues that
> I am awa
On Mon, Dec 31, 2018 at 03:16:23PM +, Andrew Cooper wrote:
> For development purposes, it is very convenient to boot Xen as a PVH guest,
> with an XTF PV or PVH "dom0". The edit-compile-go cycle is a matter of
> seconds, and you can reasonably insert printk() debugging in places which
> which
On 04/01/2019 12:33, Roger Pau Monné wrote:
> On Mon, Dec 31, 2018 at 03:16:22PM +, Andrew Cooper wrote:
>> This option is unique to x86 PV dom0's, but it is not sensible to have a
>> catch-all which blindly maps all non-RAM regions into the IOMMU.
>>
>> The map-reserved option remains, and cov
On Fri, Jan 04, 2019 at 12:46:27PM +, Andrew Cooper wrote:
> On 04/01/2019 12:33, Roger Pau Monné wrote:
> > On Mon, Dec 31, 2018 at 03:16:22PM +, Andrew Cooper wrote:
> >> This option is unique to x86 PV dom0's, but it is not sensible to have a
> >> catch-all which blindly maps all non-RAM
>>> On 03.01.19 at 18:45, wrote:
> While looking at some tangential issues I realized that the 'VGA Not
> Present' flag that Xen currently sets for PVH DomUs might be slightly
> different from what we expect it to mean. The purpose was that Xen
> would set this flag to denote there's no VGA MMIO r
>>> On 04.01.19 at 09:57, wrote:
> On Fri, Dec 21, 2018 at 03:05:03PM -0800, Christopher Clark wrote:
>> On Thu, Dec 20, 2018 at 4:52 AM Roger Pau Monné wrote:
>> >
>> > On Wed, Dec 19, 2018 at 09:41:59PM -0800, Christopher Clark wrote:
>> > > On Wed, Dec 12, 2018 at 8:48 AM Roger Pau Monné
>>
>>> On 04.01.19 at 09:13, wrote:
> ok, I'm at the point where I'm close to having a version three of the
> series to post that addresses all the feedback so far, plus some
> additional improvements, with the following two items remaining to
> discuss:
>
> 1) the domain_cookie, with Jan's question
On Mon, Dec 31, 2018 at 03:16:22PM +, Andrew Cooper wrote:
> diff --git a/xen/drivers/passthrough/x86/iommu.c
> b/xen/drivers/passthrough/x86/iommu.c
> index c68a722..0ccb754 100644
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -169,10 +169,10 @@
>>> On 31.12.18 at 19:46, wrote:
> As I've spent a while staring at the command line docs recently, I've
> come to the conclusion that we should probably remove these:
>
> * ro-hpet
>
> I'm afraid that I didn't spot this one going in, and would have objected
> to it if I'd found it.
Not how the
flight 131733 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131733/
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
On Fri, Jan 04, 2019 at 06:10:29AM -0700, Jan Beulich wrote:
> >>> On 03.01.19 at 18:45, wrote:
> > While looking at some tangential issues I realized that the 'VGA Not
> > Present' flag that Xen currently sets for PVH DomUs might be slightly
> > different from what we expect it to mean. The purpo
>>> On 27.12.18 at 16:26, wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -124,7 +124,7 @@ static int __init pvh_populate_memory_range(struct domain
> *d,
> order);
> if ( rc != 0 )
> {
> -p
>>> On 28.12.18 at 12:18, wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -91,16 +91,54 @@ static int __init pvh_populate_memory_range(struct domain
> *d,
> unsigned long start,
>
>>> On 21.12.18 at 10:41, wrote:
> paging_log_dirty_op function takes mm locks from a subject domain and
> then attempts to perform copy to operations against the caller domain
> in order to copy the result of the hypercall into the caller provided
> buffer.
>
> This works fine when the caller is
flight 131718 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 125898
test-amd64-amd64-li
There's no reason to use long to store the alignment, since the bigger
page size is 1GB, and the alignment is stored as a frame number.
Reported-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/hvm/dom0_build.c | 3 +--
1 file
On Fri, Jan 04, 2019 at 07:42:35AM -0700, Jan Beulich wrote:
> >>> On 28.12.18 at 12:18, wrote:
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -91,16 +91,54 @@ static int __init pvh_populate_memory_range(struct
> > domain *d,
> >
These two new functions libxl__domain_build_state_{init,dispose} should
be called every time a new libxl__domain_build_state comes to existance.
There seems to be two of them, one with the domain creation machinery,
and one in the stub_dm_spawn.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackso
.. to be able to re-use qmp_prepare_cmd with libxl__ev_qmp.
This patch also add the QMP end of command '\r\n' into the generated
string as every caller will needs this.
There should be no functional change.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
Notes:
v8:
Acked
This patch change the behavior of libxl__sendmsg_fds to retry sendmsg on
EINTR error and return an error on short writes.
This patch allow a caller of libxl__sendmsg_fds to deal with EWOULDBLOCK
and short writes. The function now requires to send only 1 byte of data
so that when dealing with non-b
This patch implement the API libxl__ev_qmp documented in the previous
patch, "libxl: Design of an async API to issue QMP commands to QEMU".
Since this API is to interact with QEMU via the QMP protocol, it also
implement a QMP client. The specification for the QEMU Machine Protocol
(QMP) can be fou
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.libxl-ev-qmp-v8
Changes in v8:
libxl_qmp: Implementation of libxl__ev_qmp_*:
- few changes
Then 3 patches have been added but are not necessary, they are follow-up
p
This patch makes the function simpler to read. It also add the ability
for a caller to tell if QEMU is newer or have the exact version.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
Notes:
v6:
new patch
tools/libxl/libxl_qmp.c | 28 +---
1 file ch
All the functions will be implemented in later patches.
This patch includes the API that libxl can use to send QMP commands to
QEMU.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
Notes:
v7:
acked, but with:
fd field renamed to payload_fd
libxl__ao
This function can be used by user of libxl__spawn_* when they setup a
notification other than xenstore. The parent can already report success
via libxl__spawn_initiate_detach(), this new function can be used for
failure instead of waiting for the timeout.
Signed-off-by: Anthony PERARD
Acked-by: I
That wrapper is going to be used to safely log a json_object, as
libxl__json_object_to_json return NULL on error. In the error case,
JSON() will return an invalid json string.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
Notes:
v8:
Acked
v7:
new patch
This patch moves the creation of the QMP unix socket from QEMU to libxl.
But libxl doesn't rely on this yet.
When starting QEMU with dm_restrict=1, pre-open the QMP socket before
exec QEMU. That socket will be useful to find out if QEMU is ready, and
pre-opening it means that libxl can connect to
>>> On 31.12.18 at 18:35, wrote:
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -61,42 +61,31 @@ static unsigned vpmu_count;
>
> static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>
> -static int parse_vpmu_param(const char *s, unsigned int len)
> -{
> -if ( !*s || !le
As with the serialise side, Xen's copy_from_guest API is used, with a
compatibility wrapper for the userspace build.
Signed-off-by: Andrew Cooper
Signed-off-by: Sergey Dyasli
Signed-off-by: Roger Pau Monné
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
---
xen/includ
The AFL harness currently notices that there are cases where we optimse the
serialised stream by omitting data beyond the various maximum leaves.
Both sets of tests will be extended with further libx86 work.
Fix the sorting of the CPUID_GUEST_NR_* constants, noticed while writing the
unit tests.
From: Roger Pau Monné
Signed-off-by: Sergey Dyasli
Signed-off-by: Roger Pau Monné
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
---
xen/include/xen/lib/x86/msr.h | 21 ++
xen/lib/x86/msr.c | 67 ++
I've lost count of exactly which version this is, due to multiple postings of
various sub series, and several substantial rebases.
I think I've addressed all outstanding review content, so lets start from v1
again.
Andrew Cooper (2):
libx86: Introduce a helper to deserialise cpuid_policy object
On Fri, Jan 04, 2019 at 06:22:19AM -0700, Jan Beulich wrote:
> >>> On 04.01.19 at 09:57, wrote:
> > On Fri, Dec 21, 2018 at 03:05:03PM -0800, Christopher Clark wrote:
> >> On Thu, Dec 20, 2018 at 4:52 AM Roger Pau Monné
> >> wrote:
> >> >
> >> > On Wed, Dec 19, 2018 at 09:41:59PM -0800, Christop
>>> On 04.01.19 at 16:14, wrote:
> There's no reason to use long to store the alignment, since the bigger
biggest?
> page size is 1GB, and the alignment is stored as a frame number.
>
> Reported-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> C
>>> On 04.01.19 at 15:09, wrote:
> Do you agree however that PVH DomU could maybe use reduced hardware
> ACPI while Dom0 using whatever mode (reduced or not) is set by the
> native ACPI tables?
Yes, it's certainly worth exploring.
Jan
___
Xen-devel
>>> On 04.01.19 at 16:35, wrote:
> On Fri, Jan 04, 2019 at 06:22:19AM -0700, Jan Beulich wrote:
>> >>> On 04.01.19 at 09:57, wrote:
>> > On Fri, Dec 21, 2018 at 03:05:03PM -0800, Christopher Clark wrote:
>> >> On Thu, Dec 20, 2018 at 4:52 AM Roger Pau Monné
>> >> wrote:
>> >> >
>> >> > On Wed,
On 04/01/2019 15:32, Jan Beulich wrote:
On 31.12.18 at 18:35, wrote:
>> --- a/xen/arch/x86/cpu/vpmu.c
>> +++ b/xen/arch/x86/cpu/vpmu.c
>> @@ -61,42 +61,31 @@ static unsigned vpmu_count;
>>
>> static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>>
>> -static int parse_vpmu_param(const char *
On Thu, Dec 20, 2018 at 05:14:30PM +, Paul Durrant wrote:
> 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.
Anthony PERARD writes ("Re: [PATCH v7 01/14] libxl: Enhance libxl__sendmsg_fds
to deal with EINTR and EWOULDBLOCK"):
> On Fri, Dec 21, 2018 at 02:30:05PM +, Ian Jackson wrote:
> > Even with a blocking fd, sendmsg may in principle report a short
> > write. (So the commit message should talk ab
With 'xl migrate' the migration is always live, while 'virsh migrate' will do
an offline migration unless '--live' is used. Such non-live migration will
break with HVM because the sending side does not seem to unlock the qcow2 image.
I wonder if its worth keeping (and fixing) the concept of an "
The re-implementation is done because we want to be able to send the
file description that QEMU can use to save its state. When QEMU is
restricted, it would not be able to write to a path.
This replace both libxl__qmp_stop() and libxl__qmp_save().
qmp_qemu_check_version() was only used by libxl__
From: Anthony PERARD
Now that `datalen' needs to be 1, we can remove it. Also change `data'
parameter to be a singe byte.
Signed-off-by: Anthony PERARD
---
Notes:
v8:
new patch, just a follow-up
tools/libxl/libxl_aoutils.c | 2 +-
tools/libxl/libxl_internal.h | 4 ++--
tools/lib
These two functions, dmss_init and dmss_dispose, need to be called to
initialise the private parts of a libxl__dm_spawn_state (dmss) as well
as dispose of them before giving back control to a caller.
There are 3 functions that can start using a dmss, the classic
libxl__spawn_local_dm, the one for
This will be used in a later patch.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
Notes:
v8:
Acked
v7:
Add do{}while around the MACRO.
formating nits changes.
v6:
new local macro GRAB_VERSION
better definition of qemu_versi
This is only activated when dm_restrict=1, as explained in a previous
patch "libxl_dm: Pre-open QMP socket for QEMU"
Signed-off-by: Anthony PERARD
Reviewed-by: Roger Pau Monné
Acked-by: Ian Jackson
---
Notes:
v8:
Acked
v7:
fixed _dispose call in device_model_spawn_
This create an extra step for the two call sites of the function.
libxl__domain_suspend_device_model() in this patch gets an extra error
variable (there is ret and rc), but ret goes away in the next patch.
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
libxl_domain_soft_reset() haven'
It isn't possible to use libxl__json_object_append_to() outside of
libxl_json.c as there is no way to allocate a struct libxl__yajl_ctx.
So also remove libxl__yajl_ctx typedef from the internal header.
Signed-off-by: Anthony PERARD
---
Notes:
v8:
New follow-up patch
tools/libxl/lib
This comments that libxl__json_object_get_* and libxl__json_*_get
functions accept the libxl__json_object parameter to be NULL.
libxl__json_object_to_json also works with NULL.
This also move libxl__json_object_alloc declaration closer to similar
functions, and closer to libxl__json_object_free.
Anthony PERARD writes ("[PATCH v8 15/17] libxl: Remove unused arg from
libxl__sendmsg_fds"):
> From: Anthony PERARD
>
> Now that `datalen' needs to be 1, we can remove it. Also change `data'
> parameter to be a singe byte.
Acked-by: Ian Jackson
___
flight 131720 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131720/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 131670
test-amd64-i386-mi
Anthony PERARD writes ("[PATCH v8 16/17] libxl_json: Remove
libxl__json_object_append_to from header"):
> It isn't possible to use libxl__json_object_append_to() outside of
> libxl_json.c as there is no way to allocate a struct libxl__yajl_ctx.
> So also remove libxl__yajl_ctx typedef from the int
On 1/4/19 1:03 AM, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/xen/pvcalls-back.c: In function 'pvcalls_sk_state_change':
> drivers/xen/pvcalls-back.c:286:28: warning:
> variable 'intf' set but not used [-Wunused-but-set-variable]
>
> It not used since e6587cdbd7
On 04/01/2019 15:55, Andrew Cooper wrote:
> On 04/01/2019 15:32, Jan Beulich wrote:
>>> +{
>>> +int res = (*frag - *name);
>> With the result of this being implementation defined (due to plain
>> char's implementation defined - often command line controlled
>> with an implementation def
Almost done, there is one thing left which I believe is an issue.
Whenever I attach a raw file to QEMU, it print:
qemu-system-i386: warning: Opening a block device as a file using the
'file' driver is deprecated
So, I think the comment below isn't true. We should create a "raw"
driver for "ra
When evex.opmsk is required to be zero there's no need for this, as it
won't have been set to true in the first place.
Signed-off-by: Jan Beulich
---
I've made similar changes to patches 16, 45, and 46 of v7 of the main
AVX512 series.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 04 January 2019 16:31
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v7 16/
>>> On 04.01.19 at 16:55, wrote:
> On 04/01/2019 15:32, Jan Beulich wrote:
> On 31.12.18 at 18:35, wrote:
>>> +{
>>> +int res = (*frag - *name);
>> With the result of this being implementation defined (due to plain
>> char's implementation defined - often command line controlled
>
Am Fri, 4 Jan 2019 16:57:55 +0100
schrieb Olaf Hering :
> worth keeping (and fixing) the concept of an "offline migration"
And regarding the fix, it looks like qmp_xen_save_devices_state does not need
the concept of "live". Just shutdown the blockdevices and be done with it?
+++ b/migration/sav
flight 131730 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131730/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 131710
test-armhf-armhf-libvirt-raw 13 saveresto
>>> On 21.12.18 at 14:46, wrote:
> All of this code lives inside CONFIG_PV which means gfn == mfn, and the
> fill_ro_mpt() calls clearly show that the value is used untranslated.
>
> Change cr3_gfn to a suitably typed cr3_mfn, and replace get_page_from_gfn()
> with a straight mfn_to_page/get_page
>>> On 04.01.19 at 11:33, wrote:
> As that seems to be the prevailing style.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
Thanks for doing this; I too have been meaning to.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
The C spec requires that the comarison be done in terms of unsigned char.
The code style in this file is terrible, but does claim to be Xen BSD style,
so fix up these functions while rewriting them.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/comm
>>> On 04.01.19 at 11:33, wrote:
> It makes no sense for io.c to be on the top level passthrough
> directory, since it's x86 specific.
I'm not sure it really is. It's largely about interrupt arrangements
for guests, which (being PCI-related) may or may not be re-
usable by Arm once they get to su
On Fri, 4 Jan 2019, Jan Beulich wrote:
> >>> On 02.01.19 at 19:20, wrote:
> > On Wed, 14 Nov 2018, Jan Beulich wrote:
> >> >>> On 13.11.18 at 23:02, wrote:
> >> > On Tue, 13 Nov 2018, Jan Beulich wrote:
> >> >> >>> On 13.11.18 at 14:17, wrote:
> >> >> > On 13/11/2018 12:56, Jan Beulich wrote:
>
1 - 100 of 108 matches
Mail list logo
