flight 122592 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
flight 122607 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122607/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
flight 122589 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122589/
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 broken
This run is configured for baseline tests only.
flight 74673 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74673/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 16
flight 122604 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122604/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
On Fri, May 04, 2018 at 06:13:25PM -0400, Rich Persaud wrote:
> > On May 1, 2018, at 08:53, Jason Cooper wrote:
> >
> > add the link to xen-users thread of me talking to myself. :-))
> >
> >> On Tue, May 01, 2018 at 12:37:51PM +, Jason Cooper wrote:
> >> When I was
> On May 1, 2018, at 08:53, Jason Cooper wrote:
>
> add the link to xen-users thread of me talking to myself. :-))
>
>> On Tue, May 01, 2018 at 12:37:51PM +, Jason Cooper wrote:
>> When I was first digging into this, I started a thread on xen-users [1],
>> I've
CC'ing xen-devel in case Xen maintainers have a need for something that
will that conflict with this proposal wrt supported build platforms.
On Fri, May 04, 2018 at 05:00:23PM +0100, Daniel P. Berrangé wrote:
> This short series is a followup the discussions around min glib version
> when Olaf
flight 122602 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122602/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
This patch adds grant table helper functions to the xen_backend code to
localize error reporting and use of xen_domid.
The patch also defers the call to xengnttab_open() until just before the
initialise method in XenDevOps is invoked. This method is responsible for
mapping the shared ring. No
Now that the (native or emulated) xen_be_copy_grant_refs() helper is
always available, the xen_disk code can be significantly simplified by
removing direct use of grant map and unmap operations.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
There is no longer any use of this flag outside of the xen_backend code.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
v2:
- New in v2
---
hw/xen/xen_backend.c | 2 +-
The grant copy operation was added to libxengnttab in Xen 4.8.0 (released
nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying
a significant amount of code purely to remain compatible with older
versions of Xen.
As can be inferred from the diff stats below, removing this
Now that helpers are present in xen_backend, this patch removes open-coded
calls to libxengnttab from the xen_disk code.
This patch also fixes one whitspace error in the assignment of the
XenDevOps initialise method.
Signed-off-by: Paul Durrant
---
Cc: Stefano
Now that helpers are available in xen_backend, use them throughout all
Xen PV backends.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Greg Kurz
Cc: Paolo Bonzini
Not all Xen environments support the xengnttab_grant_copy() operation.
E.g. where the OS is FreeBSD or Xen is older than 4.8.0.
This patch introduces an emulation of that operation using
xengnttab_map_domain_grant_refs() and memcpy() for those environments.
Signed-off-by: Paul Durrant
Certain functions in xen_disk are called with a pointer to xendev
(struct XenDevice *). They then use continer_of() to acces the surrounding
blkdev (struct XenBlkDev) but then in various places use >xendev
when use of the original xendev pointer is shorter to express and clearly
equivalent.
This
Since xen_disk now always copies data to and from a guest there is no need
to maintain a vector entry corresponding to every page of a request.
This means there is less per-request state to maintain so the ioreq
structure can shrink significantly.
Signed-off-by: Paul Durrant
On 04/05/18 19:45, Boris Ostrovsky wrote:
> On 05/04/2018 01:28 PM, Andrew Cooper wrote:
>> --- a/xen/include/asm-x86/msr-index.h
>> +++ b/xen/include/asm-x86/msr-index.h
>> @@ -31,6 +31,9 @@
>> #define EFER_LMSLE (1<<_EFER_LMSLE)
>> #define EFER_FFXSE (1<<_EFER_FFXSE)
>>
>>
On 05/04/2018 01:28 PM, Andrew Cooper wrote:
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -31,6 +31,9 @@
> #define EFER_LMSLE (1<<_EFER_LMSLE)
> #define EFER_FFXSE (1<<_EFER_FFXSE)
>
> +#define EFER_KNOWN_MASK (EFER_SCE |
On 05/04/2018 11:07 AM, Jan Beulich wrote:
> Only patch 1 is clearly meant for 4.11. The second patch, however, eliminates
> a (theoretical) window the first patch still leaves, so should at least be
> considered.
> Furthermore previous discussion suggests that it might even be desirable to
>
On 04/05/18 16:07, Jan Beulich wrote:
> Only patch 1 is clearly meant for 4.11. The second patch, however, eliminates
> a (theoretical) window the first patch still leaves, so should at least be
> considered.
> Furthermore previous discussion suggests that it might even be desirable to
> fold
>
Thanks. This is much better :-). I have reviewed this for style,
obvious bugs, and the semantics in the doc comment. I haven't tried
to follow the algorithm in detail, but I reckon it's probably OK.
I have reordered the patch (and hence the file) to make the grouping
of my comments make more
We don't advertise SVM in CPUID so a PV guest shouldn't be under the
impression that it can use SVM functionality, but despite this, it really
shouldn't see SVME set when reading EFER.
Introduce EFER_KNOWN_MASK to whitelist the features Xen knows about, and use
this to clamp the guests view.
>>> On 08.07.17 at 23:53, wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -383,9 +383,13 @@ __efi64_mb2_start:
> jmp x86_32_switch
>
> .Lefi_multiboot2_proto:
> -/* Zero EFI SystemTable and EFI ImageHandle addresses.
>>> On 08.07.17 at 23:53, wrote:
> In comparison to ELF the PE format is not supported by the Multiboot
> protocol. So, if we wish to load xen.efi using this protocol we have
> to put header_addr, load_addr, load_end_addr, bss_end_addr and
> entry_addr data into Multiboot
>>> On 08.07.17 at 23:53, wrote:
> This is the first step to get:
> - one binary which can be loaded by the EFI loader,
> Multiboot and Multiboot2 protocols,
> - if we wish, in the future we can drop xen/xen.gz
> and build xen.efi only,
If anything, generate
>>> On 04.05.18 at 16:51, wrote:
> A bit more than a week ago, I put out for initial review the proposal for
> “Graduation Review: Windows PV Driver” at
> https://xen.markmail.org/thread/vcbvln7aa3ocikx4
+1
Jan
___
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 04 May 2018 14:56
> To: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; Anthony
>>> On 04.05.18 at 17:09, wrote:
> Signed-off-by: Wei Liu
I don't think a change like this really needs an ack, but here you go:
Acked-by: Jan Beulich
Jan
___
Xen-devel mailing list
Neither the register values copying nor the trace entry generation need
doing in assembly. The VMLOAD invocation can also be further deferred
(and centralized). Therefore replace the svm_asid_handle_vmrun()
invocation with one of the new helper.
Similarly move the VM exit side register value
While the main problem to be addressed here is the issue of what so far
was named "vmcb_in_sync" starting out with the wrong value (should have
been true instead of false, to prevent performing a VMSAVE without ever
having VMLOADed the vCPU's state), go a step further and make the
sync-ed state a
Signed-off-by: Wei Liu
---
docs/misc/xen-command-line.markdown | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index e7a8bd66e7..616dc9d34c 100644
---
Only patch 1 is clearly meant for 4.11. The second patch, however, eliminates
a (theoretical) window the first patch still leaves, so should at least be
considered.
Furthermore previous discussion suggests that it might even be desirable to fold
both patches into one (or swap their order).
1:
On Fri, Apr 27, 2018 at 02:15:25AM -0600, Jan Beulich wrote:
> >>> On 27.04.18 at 09:59, wrote:
> > On 27/04/18 09:55, Sergey Dyasli wrote:
> >> On Thu, 2018-04-26 at 13:33 +0200, Juergen Gross wrote:
> >>> index b353352adf..220d1ba020 100644
> >>> ---
+1 from me.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Thu, Apr 26, 2018 at 01:33:09PM +0200, Juergen Gross wrote:
> Juergen Gross (9):
> x86/xpti: avoid copying L4 page table contents when possible
> xen/x86: add a function for modifying cr3
> xen/x86: support per-domain flag for xpti
> xen/x86: use invpcid for flushing the TLB
>
On 04/05/18 15:51, Lars Kurth wrote:
> Hi all,
>
> A bit more than a week ago, I put out for initial review the proposal for
> “Graduation Review: Windows PV Driver” at
> https://xen.markmail.org/thread/vcbvln7aa3ocikx4
> There has not been feedback, except for two recorded votes from the Xen
Hi all,
A bit more than a week ago, I put out for initial review the proposal for
“Graduation Review: Windows PV Driver” at
https://xen.markmail.org/thread/vcbvln7aa3ocikx4
There has not been feedback, except for two recorded votes from the Xen Project
Hypervisor Team by Ian Jackson and
Hi all,
Xen 4.11 rc3 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.11.0-rc3
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.11.0-rc3/xen-4.11.0-rc3.tar.gz
And the signature is at:
The grant copy operation was added to libxengnttab in Xen 4.8.0 (released
nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying
a significant amount of code purely to remain compatible with older
versions of Xen.
As can be inferred from the diff stats below, removing this
Since xen_disk now always copies data to and from a guest there is no need
to maintain a vector entry corresponding to every page of a request.
This means there is less per-request state to maintain so the ioreq
structure can shrink significantly.
Signed-off-by: Paul Durrant
Now that the (native or emulated) xen_be_copy_grant_refs() helper is
always available, the xen_disk code can be significantly simplified by
removing direct use of grant map and unmap operations.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Certain functions in xen_disk are called with a pointer to xendev
(struct XenDevice *). They then use continer_of() to acces the surrounding
blkdev (struct XenBlkDev) but then in various places use >xendev
when use of the original xendev pointer is shorter to express and clearly
equivalent.
This
This patch adds grant table helper functions to the xen_backend code to
localize error reporting and use of xen_domid.
The patch also defers the call to xengnttab_open() until just before the
initialise method in XenDevOps is invoked. This method is responsible for
mapping the shared ring. No
Now that helpers are present in xen_backend, this patch removes open-coded
calls to libxengnttab from the xen_disk code.
This patch also fixes one whitspace error in the assignment of the
XenDevOps initialise method.
Signed-off-by: Paul Durrant
---
Cc: Stefano
Not all Xen environments support the xengnttab_grant_copy() operation.
E.g. where the OS is FreeBSD or Xen is older than 4.8.0.
This patch introduces an emulation of that operation using
xengnttab_map_domain_grant_refs() and memcpy() for those environments.
Signed-off-by: Paul Durrant
Now that helpers are available in xen_backend, use them throughout all
Xen PV backends.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Greg Kurz
Cc: Paolo Bonzini
There is no longer any use of this flag outside of the xen_backend code.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
v2:
- New in v2
---
hw/xen/xen_backend.c | 2 +-
flight 122580 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122580/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122493
>>> On 04.05.18 at 05:53, wrote:
>> > Thanks for your clarification. Please correct me if I have
>> > something wrong. Guest may execute an instruction and this instruction
>> > may produce an PT packet save in PT output buffer. An EPT violation
>> > will be generated
>>> On 04.05.18 at 04:54, wrote:
> 发件人: Jan Beulich
> 发送时间: 2018年5月3日 23:09
>> +if ( cpu_has(c, X86_FEATURE_ITSC) )
>> +{
>> +__set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
>> +__set_bit(X86_FEATURE_NONSTOP_TSC,
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.17-rc4-tag
xen: one cleanup for 4.17-rc4
It contains one cleanup to remove VLAs from the kernel.
Thanks.
Juergen
arch/x86/xen/enlighten_pv.c | 86
flight 74672 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74672/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like
74644
baseline version:
flight 122578 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122578/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324
This version of this series addresses all comments on the mailing list, as well
as some feedback I got in various personal conversations and/or on IRC. For
the people who asked for specific features/workflows:
Ian Jackson: use ./scripts/add_maintainers.pl -p none [-c top]
Reads CCs from
The tool covers step 2 of the following workflow
Step 1: git format-patch ... -o ...
Step 2: ./scripts/add_maintainers.pl -d
This overwrites *.patch files in
Step 3: git send-email -to xen-devel@lists.xenproject.org /*.patchxm
I manually tested all options and the most common
This run is configured for baseline tests only.
flight 74668 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 22
58 matches
Mail list logo