[Xen-devel] [xen-unstable-smoke baseline test] 122908: tolerable all pass

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 122908 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122908/ Failures

[Xen-devel] [xen-4.10-testing baseline-only test] 74723: regressions - FAIL

This run is configured for baseline tests only. flight 74723 xen-4.10-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74723/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64

[Xen-devel] [xen-unstable-smoke baseline test] 122909: tolerable all pass

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 122909 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122909/ Failures

[Xen-devel] [RFC 0/3] dma-buf support for gntdev

From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if

Re: [Xen-devel] [PATCH v2 for-4.7/4.8] x86: Fix "x86: further CPUID handling adjustments"

>>> On 16.05.18 at 19:27, wrote: > c/s f9616884e (a backport of c/s 0d703a701 "x86/feature: Definitions for > Indirect Branch Controls") missed a CPUID adjustment when calculating the raw > featureset. This impacts host administrator diagnostics. > > Signed-off-by:

[Xen-devel] [PATCH for-4.11] x86/cacheattr: fix mtrr_pat_not_equal

The function is supposed to return whether the MTRR and PAT state of two CPUs match. Currently this is not properly done because the test for the deftype and the enable bits required both the deftype and the enable bits to be different, while just one of those fields being different can already

Re: [Xen-devel] [PATCH v3 6/8] xen_backend: make the xen_feature_grant_copy flag private

On Fri, May 04, 2018 at 08:26:05PM +0100, Paul Durrant wrote: > There is no longer any use of this flag outside of the xen_backend code. > > Signed-off-by: Paul Durrant Acked-by: Anthony PERARD -- Anthony PERARD

Re: [Xen-devel] [PATCH v3 5/8] xen_disk: remove use of grant map/unmap

On Fri, May 04, 2018 at 08:26:04PM +0100, Paul Durrant wrote: > 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

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

Am Mon, 7 May 2018 17:19:46 +0200 schrieb Olaf Hering : > With qemu-2.11 the sender thinks everything is alright and the domU is moved. Another case of breakage in qemu-2.11: if the targethost does not even have access to the diskimage the sender still thinks everything is

Re: [Xen-devel] [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers

On 05/17/2018 09:26 AM, Takashi Iwai wrote: On Tue, 15 May 2018 08:02:08 +0200, Oleksandr Andrushchenko wrote: On 05/15/2018 09:01 AM, Takashi Iwai wrote: On Tue, 15 May 2018 07:46:38 +0200, Oleksandr Andrushchenko wrote: On 05/14/2018 11:28 PM, Takashi Iwai wrote: On Mon, 14 May 2018

[Xen-devel] [linux-4.9 test] 122824: FAIL

flight 122824 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122824/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm broken in 122722

Re: [Xen-devel] [PATCH for-4.11] x86/cacheattr: fix mtrr_pat_not_equal

On 17/05/18 11:48, Roger Pau Monne wrote: > The function is supposed to return whether the MTRR and PAT state of > two CPUs match. Currently this is not properly done because the test > for the deftype and the enable bits required both the deftype and the > enable bits to be different, while just

Re: [Xen-devel] [PATCH v2 2/3] xen/store: do not store local values in xen_start_info

On 09/05/18 12:21, Roger Pau Monne wrote: > There's no need to store the xenstore page or event channel in > xen_start_info if they are locally initialized. > > This also fixes PVH local xenstore initialization due to the lack of > xen_start_info in that case. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v5] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

On 09/05/18 15:16, Paul Durrant wrote: > My recent Xen patch series introduces a new HYPERVISOR_memory_op to > support direct priv-mapping of certain guest resources (such as ioreq > pages, used by emulators) by a tools domain, rather than having to access > such resources via the guest P2M. > >

Re: [Xen-devel] [PATCH] xen-netfront: fix xennet_start_xmit()'s return type

On 24/04/18 15:18, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too. > > Signed-off-by: Luc

[Xen-devel] [RFC 2/3] xen/grant-table: Extend API to work with DMA buffers

From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/grant-table.c | 49 +++ include/xen/grant_table.h | 7 ++ 2 files changed, 56 insertions(+) diff

[Xen-devel] [RFC 3/3] xen/gntdev: Add support for Linux dma buffers

From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/gntdev.c | 954 +- include/uapi/xen/gntdev.h | 101 include/xen/gntdev_exp.h | 23 + 3 files

[Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/balloon.c | 214 +++--- drivers/xen/xen-balloon.c | 2 + include/xen/balloon.h | 11 +- 3 files

Re: [Xen-devel] [PATCH] xen: Change return type to vm_fault_t

On 14/04/18 21:15, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler > in struct vm_operations_struct. > > Signed-off-by: Souptick Joarder > Reviewed-by: Matthew Wilcox Pushed to xen/tip.git for-linus-4.18 Juergen

Re: [Xen-devel] [PATCHv3] xen: Add EFI_LOAD_OPTION support

>>> On 07.02.18 at 17:00, wrote: > This patch as-is correctly tells the two possible formats apart. I > tested and Xen boots correctly both from the Shell and from the > firmware boot menu. I would not like to start addressing hypothetical > scenarios that I have no

Re: [Xen-devel] [PATCH v3 7/8] xen_disk: use a single entry iovec

On Fri, May 04, 2018 at 08:26:06PM +0100, Paul Durrant wrote: > 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

Re: [Xen-devel] [PATCH for-4.11] x86/cacheattr: fix mtrr_pat_not_equal

On 17/05/18 12:44, Jan Beulich wrote: On 17.05.18 at 11:48, wrote: >> The function is supposed to return whether the MTRR and PAT state of >> two CPUs match. Currently this is not properly done because the test >> for the deftype and the enable bits required both the

Re: [Xen-devel] [OSSTEST PATCH 06/10] Perl @INC path: fix a few more scripts to use BEGIN

On Thu, May 17, 2018 at 12:16:55PM +0100, Ian Jackson wrote: > Three more files which missed out on > dea987c5ab11 "PERLLIB, @INC: Use BEGIN { }" > > Signed-off-by: Ian Jackson Reviewed-by: Roger Pau Monné

Re: [Xen-devel] [PATCH for-4.11] x86/cacheattr: fix mtrr_pat_not_equal

>>> On 17.05.18 at 11:48, wrote: > The function is supposed to return whether the MTRR and PAT state of > two CPUs match. Currently this is not properly done because the test > for the deftype and the enable bits required both the deftype and the > enable bits to be

Re: [Xen-devel] Test for osstest, features used in Qubes OS

Marek Marczykowski-Górecki writes ("Test for osstest, features used in Qubes OS"): > As discussed some time ago, I'd like to help with adding tests for some > features we use in Qubes OS. > > IMO the easiest thing to test is host suspend. You just need to execute > "rtcwake -s 30 -m mem", and

Re: [Xen-devel] [OSSTEST PATCH 07/10] mg-anoint: Make readonly operations "work" in standalone mode

On Thu, May 17, 2018 at 12:16:56PM +0100, Ian Jackson wrote: > This makes `mg-anoint' in standalone mode a view onto an empty set of > anointments. So now it becomes ok to call mg-anoint in make-*-flight. > > Signed-off-by: Ian Jackson Reviewed-by: Roger Pau Monné

[Xen-devel] [xen-4.7-testing test] 122831: regressions - FAIL

flight 122831 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122831/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm broken in 122678 test-arm64-arm64-xl-xsm

Re: [Xen-devel] [PATCH v2 for-4.7/4.8] x86: Fix "x86: further CPUID handling adjustments"

>>> On 16.05.18 at 19:27, wrote: > c/s 62b187969 "x86: further CPUID handling adjustments" make some adjustments. > However, it breaks levelling of guests, making it impossible for the toolstack > to hide STIBP or IBPB from guests on hardware with up-to-date microcode.

Re: [Xen-devel] [PATCH v4 2/2] xen/kbdif: Add features to disable keyboard and pointer

On Thu, May 17, 2018 at 08:51:38AM +0300, Oleksandr Andrushchenko wrote: > On 05/17/2018 08:50 AM, Juergen Gross wrote: > > On 17/05/18 07:45, Oleksandr Andrushchenko wrote: > > > Hi, Juergen! > > > > > > This patch should go into 4.11 as it is needed for a related Linux > > > kernel patch and

Re: [Xen-devel] [PATCH for-4.11] x86/cacheattr: fix mtrr_pat_not_equal

On Thu, May 17, 2018 at 04:44:04AM -0600, Jan Beulich wrote: > >>> On 17.05.18 at 11:48, wrote: > > The function is supposed to return whether the MTRR and PAT state of > > two CPUs match. Currently this is not properly done because the test > > for the deftype and the

Re: [Xen-devel] [PATCH for-4.11] x86/cacheattr: fix mtrr_pat_not_equal

>>> On 17.05.18 at 13:46, wrote: > Nothing good will come of trying to formally support different MSR > capabilities on different vcpus, because you won't find any hardware > where you can do this in practice. I agree, but it's not really clear to me how you want to

Re: [Xen-devel] [PATCH for-4.11] x86/cacheattr: fix mtrr_pat_not_equal

>>> On 17.05.18 at 13:49, wrote: > On 17/05/18 12:44, Jan Beulich wrote: > On 17.05.18 at 11:48, wrote: >>> The function is supposed to return whether the MTRR and PAT state of >>> two CPUs match. Currently this is not properly done because the test >>>

[Xen-devel] [PATCH] libxc/x86: don't hand through CPUID leaf 0x80000008 as is

Just like for HVM the feature set should be used for EBX output, while EAX should be restricted to the low 16 bits and ECX/EDX should be zero. Short of there being white listing in place just like on the HVM side, also zap leaves 6, 9, and 0x8007 as well as unknown / reserved ones.

[Xen-devel] [OSSTEST PATCH 01/10] Osstest/TestSupport: Use right arch for UEFI grub setup

Signed-off-by: Ian Jackson --- Osstest/TestSupport.pm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm index 6d5e667..983bb17 100644 --- a/Osstest/TestSupport.pm +++ b/Osstest/TestSupport.pm @@

[Xen-devel] [OSSTEST PATCH 06/10] Perl @INC path: fix a few more scripts to use BEGIN

Three more files which missed out on dea987c5ab11 "PERLLIB, @INC: Use BEGIN { }" Signed-off-by: Ian Jackson CC: Roger Pau Monné --- mg-anoint | 2 +- ts-examine-hostprops-save | 2 +- ts-freebsd-host-install | 2 +- 3 files

Re: [Xen-devel] [PATCH for-4.11] x86/cacheattr: fix mtrr_pat_not_equal

>>> On 17.05.18 at 13:10, wrote: > On Thu, May 17, 2018 at 04:44:04AM -0600, Jan Beulich wrote: >> >>> On 17.05.18 at 11:48, wrote: >> > The function is supposed to return whether the MTRR and PAT state of >> > two CPUs match. Currently this is not

Re: [Xen-devel] [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration

On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote: > I will go with the change you suggested and > I'll send v4 tomorrow then. Please make sure your changes to kbdif.h are in Xen first. I believe you submitted a patch there but I don't see it in the staging tree yet. -boris

[Xen-devel] [OSSTEST PATCH 02/10] Osstest/Debian: preseed: Force UEFI install regardless

This suppresses: Partition disks --- This machine's firmware has started the installer in UEFI mode but it looks like there may be existing operating systems already installed using "BIOS compatibility mode". If you continue to install Debian in UEFI mode, it might

[Xen-devel] [OSSTEST PATCH 03/10] README.dev: Fix a typo

Signed-off-by: Ian Jackson --- README.dev | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.dev b/README.dev index 95fc66c..0f7fccd 100644 --- a/README.dev +++ b/README.dev @@ -30,8 +30,8 @@ Keeps running for the duration, so run it in a

[Xen-devel] [OSSTEST PATCH 04/10] README.dev: Discuss setting Firmware for UEFI machines

This must occur before mknetbootdir, or mknetbootdir does not set things up for UEFI booting. Signed-off-by: Ian Jackson --- README.dev | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/README.dev b/README.dev index 0f7fccd..a2b93e0 100644 ---

[Xen-devel] [OSSTEST PATCH 10/10] mfi-common: Fall back to anointed builds in Executive mode

Previously, `make-*-flight' would not work unless FREEBSD_*_BUILDJOB was set. Now we use the anointed values if we can find them. If we can't, mg-anoint retrieve will print a warning. Signed-off-by: Ian Jackson CC: Roger Pau Monné ---

[Xen-devel] [OSSTEST PATCH 05/10] README.dev: Make example commisioning runes use $hn variable

This makes them better for cutting-and-pasting. Signed-off-by: Ian Jackson --- README.dev | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/README.dev b/README.dev index a2b93e0..441eee8 100644 --- a/README.dev +++ b/README.dev @@ -112,9

[Xen-devel] [OSSTEST PATCH 00/10] UEFI and commissioning fixes

From: Ian Jackson I am trying to commission some new hosts. These patches fix problems I encountered. There are fixes to: * Better support UEFI x86 hosts. * Improve the commissioning instructions in README.dev. * Handle the new FreeBSD anointments system in

[Xen-devel] [OSSTEST PATCH 07/10] mg-anoint: Make readonly operations "work" in standalone mode

This makes `mg-anoint' in standalone mode a view onto an empty set of anointments. So now it becomes ok to call mg-anoint in make-*-flight. Signed-off-by: Ian Jackson CC: Roger Pau Monné --- Osstest/JobDB/Executive.pm | 2 ++

[Xen-devel] [OSSTEST PATCH 08/10] mg-anoint: Support mg-anoint retrieve --tolerate-unprepared

make-*-flight is going to want this. Signed-off-by: Ian Jackson CC: Roger Pau Monné --- mg-anoint | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/mg-anoint b/mg-anoint index 522cbdd..d09124b 100755 ---

[Xen-devel] [OSSTEST PATCH 09/10] mfi-common: set_freebsd_runvars: Never set freebsd_distpath to `/amd64' etc.

Logically, the final branch of the if should be qualified with a check for the emptiness of FreeBSDDist. This is awkward in the current structure, since we really want to do the distpath lookup only if needed. (This is not very important right now, but we are about to add another case which will

Re: [Xen-devel] [PATCH for-4.11] x86/cacheattr: fix mtrr_pat_not_equal

On 17/05/18 12:33, Jan Beulich wrote: On 17.05.18 at 13:10, wrote: >> On Thu, May 17, 2018 at 04:44:04AM -0600, Jan Beulich wrote: >> On 17.05.18 at 11:48, wrote: The function is supposed to return whether the MTRR and PAT state of

Re: [Xen-devel] [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration

On 05/17/2018 04:08 PM, Boris Ostrovsky wrote: On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote: I will go with the change you suggested and I'll send v4 tomorrow then. Please make sure your changes to kbdif.h are in Xen first. I believe you submitted a patch there but I don't see it in

Re: [Xen-devel] [PATCH] libxc/x86: don't hand through CPUID leaf 0x80000008 as is

On 17/05/18 14:20, Jan Beulich wrote: > Just like for HVM the feature set should be used for EBX output, while > EAX should be restricted to the low 16 bits and ECX/EDX should be zero. > > Short of there being white listing in place just like on the HVM side, > also zap leaves 6, 9, and 0x8007

Re: [Xen-devel] [PATCH v3 8/8] xen_disk: be consistent with use of xendev and blkdev->xendev

On Fri, May 04, 2018 at 08:26:07PM +0100, Paul Durrant wrote: > Certain functions in xen_disk are called with a pointer to xendev > (struct XenDevice *). They then use continer_of() to acces the surrounding ^ container_of > blkdev (struct XenBlkDev) but then

Re: [Xen-devel] [xen-unstable test] 122804: FAIL

Juergen Gross writes ("Re: [Xen-devel] [xen-unstable test] 122804: FAIL"): > On 17/05/18 01:57, osstest service owner wrote: > > Tests which are failing intermittently (not blocking): > > test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail > > pass in 122715 > >

Re: [Xen-devel] [PATCH] libxc/x86: don't hand through CPUID leaf 0x80000008 as is

On 17/05/18 14:38, Jan Beulich wrote: On 17.05.18 at 15:26, wrote: >> On 17/05/18 14:20, Jan Beulich wrote: >>> Just like for HVM the feature set should be used for EBX output, while >>> EAX should be restricted to the low 16 bits and ECX/EDX should be zero. >>>

Re: [Xen-devel] [PATCH for-4.11] x86/cacheattr: fix mtrr_pat_not_equal

>>> On 17.05.18 at 13:46, wrote: > Nothing good will come of trying to formally support different MSR > capabilities on different vcpus, because you won't find any hardware > where you can do this in practice. Thinking of it - allowing this would be a nice way to allow

[Xen-devel] how to recognize in libxl that a domU has qemu-xen attached?

In the other thread about the unsolved migration bugs in qemu-xen it became clear that "xen-save-devices-state" must not only be called for HVM, but for every domU that has qemu-xen attached to it. I wonder how to check for that fact from the migration code. While it can continue to rely on

Re: [Xen-devel] how to recognize in libxl that a domU has qemu-xen attached?

On 17/05/18 14:33, Olaf Hering wrote: > In the other thread about the unsolved migration bugs in qemu-xen it became > clear that "xen-save-devices-state" must not only be called for HVM, but for > every domU that has qemu-xen attached to it. I wonder how to check for that > fact from the

Re: [Xen-devel] [PATCH] libxc/x86: don't hand through CPUID leaf 0x80000008 as is

>>> On 17.05.18 at 15:26, wrote: > On 17/05/18 14:20, Jan Beulich wrote: >> Just like for HVM the feature set should be used for EBX output, while >> EAX should be restricted to the low 16 bits and ECX/EDX should be zero. >> >> Short of there being white listing in

Re: [Xen-devel] [OSSTEST PATCH 10/10] mfi-common: Fall back to anointed builds in Executive mode

On Thu, May 17, 2018 at 12:16:59PM +0100, Ian Jackson wrote: > Previously, `make-*-flight' would not work unless FREEBSD_*_BUILDJOB > was set. Now we use the anointed values if we can find them. > > If we can't, mg-anoint retrieve will print a warning. > > Signed-off-by: Ian Jackson

[Xen-devel] [PATCH v1] libxl: fix return code in qmp_synchronous_send

Use error code from libxl namespace, a plain -1 is not valid in this context. Signed-off-by: Olaf Hering --- tools/libxl/libxl_qmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c index be1fda18ba..0fe42813bf

Re: [Xen-devel] [PATCH v4 9/9] xen_disk: be consistent with use of xendev and blkdev->xendev

> -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 17 May 2018 16:36 > To: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu- > de...@nongnu.org > Cc: Paul Durrant ; Stefano Stabellini > ; Anthony

Re: [Xen-devel] [OSSTEST PATCH 08/10] mg-anoint: Support mg-anoint retrieve --tolerate-unprepared

On Thu, May 17, 2018 at 12:16:57PM +0100, Ian Jackson wrote: > make-*-flight is going to want this. > > Signed-off-by: Ian Jackson Reviewed-by: Roger Pau Monné Just a style comment below. > --- > mg-anoint | 12 ++-- > 1 file changed,

[Xen-devel] [PATCH v3 2/2] xen/PVH: Make GDT selectors PVH-specific

We don't need to share PVH GDT layout with other GDTs, especially since we now have a PVH-speciific entry (for stack canary segment). Define PVH's own selectors. (As a side effect of this change we are also fixing improper reference to __KERNEL_CS) Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v3 1/2] xen/PVH: Set up GS segment for stack canary

>>> On 17.05.18 at 16:47, wrote: > @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen) > mov %eax,%es > mov %eax,%ss > > + mov $PVH_CANARY_SEL,%eax > + mov %eax,%gs I doubt this is needed for 64-bit (you could equally well load zero or leave in place what's

[Xen-devel] [PATCH v4 2/9] xen_backend: add grant table helpers

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

[Xen-devel] [PATCH v4 3/9] xen_disk: remove open-coded use of libxengnttab

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 Acked-by: Anthony Perard

[Xen-devel] [PATCH v4 7/9] xen_backend: make the xen_feature_grant_copy flag private

There is no longer any use of this flag outside of the xen_backend code. Signed-off-by: Paul Durrant Acked-by: Anthony Perard --- Cc: Stefano Stabellini v2: - New in v2 --- hw/xen/xen_backend.c | 2 +-

[Xen-devel] [PATCH v4 9/9] xen_disk: be consistent with use of xendev and blkdev->xendev

Certain functions in xen_disk are called with a pointer to xendev (struct XenDevice *). They then use container_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

[Xen-devel] [PATCH v4 5/9] xen_backend: add an emulation of grant copy

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

[Xen-devel] [PATCH v4 1/9] xen: add a meaningful declaration of grant_copy_segment into xen_common.h

Currently the xen_disk source has to carry #ifdef exclusions to compile against Xen older then 4.8. This is a bit messy so this patch lifts the definition of struct xengnttab_grant_copy_segment and adds it into the pre-4.8 compat area in xen_common.h, which allows xen_disk to be cleaned up.

[Xen-devel] [PATCH v4 6/9] xen_disk: remove use of grant map/unmap

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 Acked-by: Anthony Perard

[Xen-devel] [PATCH v4 0/9] xen_disk: legacy code removal and cleanup

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

Re: [Xen-devel] how to recognize in libxl that a domU has qemu-xen attached?

Am Thu, 17 May 2018 14:55:10 +0200 schrieb Juergen Gross : > libxl__need_xenpv_qemu() is used to determine whether a pv domain needs > a qemu process for at least one backend. Thanks. Too bad, d_config is not available in that context. It is probably known somewhere by the

Re: [Xen-devel] [PATCH v2 09/10] x86/SVM: Introduce svm command line option

>>> On 07.05.18 at 23:07, wrote: > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -64,6 +64,16 @@ > #include > #include > > +static int parse_svm_param(const char *s); This is unnecessary if you move ... > +/* > + * The 'svm'

Re: [Xen-devel] Test for osstest, features used in Qubes OS

Marek Marczykowski-Górecki writes ("Re: Test for osstest, features used in Qubes OS"): > On Thu, May 17, 2018 at 01:26:30PM +0100, Ian Jackson wrote: > > Is it likely that this will depend on non-buggy host firmware ? If so > > then we need to make arrangements to test it and only do it on hosts

Re: [Xen-devel] [PATCH v1] xl: show full value of cpu_khz in xl info output

On Thu, May 17, 2018 at 04:25:58PM +0200, Olaf Hering wrote: > Am Tue, 3 Apr 2018 13:14:11 +0200 > schrieb Olaf Hering : > > > The exact value of cpu_khz can only be obtained via 'xl dmesg', and > > therefore can be lost after some time. 'xl info' truncates the value to > > full

[Xen-devel] [PATCH v3 1/2] xen/PVH: Set up GS segment for stack canary

We are making calls to C code (e.g. xen_prepare_pvh()) which may use stack canary (stored in GS segment). Signed-off-by: Boris Ostrovsky --- arch/x86/xen/xen-pvh.S | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git

[Xen-devel] [PATCH v3 0/2] PVH GDT fixes

Fix stack canary handling (in the first patch) and re-index PVH GDT to make it explicit that the GDT PVH-specific v3: - Use GS base MSR for 64-bit mode Boris Ostrovsky (2): xen/PVH: Set up GS segment for stack canary xen/PVH: Make GDT selectors PVH-specific arch/x86/xen/xen-pvh.S | 46

Re: [Xen-devel] [PATCH v2 07/10] x86/SVM: Add interrupt management code via AVIC

>>> On 07.05.18 at 23:07, wrote: > +void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vec) > +{ > +struct vlapic *vlapic = vcpu_vlapic(v); > + > +/* Fallback to use non-AVIC if vcpu is not enabled with AVIC. */ > +if ( !svm_avic_vcpu_enabled(v) ) > +

Re: [Xen-devel] how to recognize in libxl that a domU has qemu-xen attached?

Am Thu, 17 May 2018 16:54:00 +0200 schrieb Olaf Hering : > Am Thu, 17 May 2018 14:55:10 +0200 > schrieb Juergen Gross : > > libxl__need_xenpv_qemu() is used to determine whether a pv domain needs > > a qemu process for at least one backend. > Thanks. Too bad,

Re: [Xen-devel] [OSSTEST PATCH 09/10] mfi-common: set_freebsd_runvars: Never set freebsd_distpath to `/amd64' etc.

On Thu, May 17, 2018 at 12:16:58PM +0100, Ian Jackson wrote: > Logically, the final branch of the if should be qualified with a check > for the emptiness of FreeBSDDist. This is awkward in the current > structure, since we really want to do the distpath lookup only if > needed. (This is not very

Re: [Xen-devel] [PATCH v4 1/2] x86/hvm: Introduce *save_one() functions

>>> On 07.05.18 at 10:24, wrote: > This patch introduces save_one() functions. They will be called in the > *save() so we can extract data for a single instance. Mostly fine, but please split up into one patch per save type. > --- a/xen/arch/x86/cpu/mcheck/vmce.c > +++

Re: [Xen-devel] [PATCH v2 06/10] x86/SVM: Add vcpu scheduling support for AVIC

>>> On 07.05.18 at 23:07, wrote: > @@ -65,6 +66,51 @@ avic_get_physical_id_entry(struct svm_domain *d, unsigned > int index) > return >avic_physical_id_table[index]; > } > > +static void avic_vcpu_load(struct vcpu *v) > +{ > +struct arch_svm_struct *s =

Re: [Xen-devel] Draft NVDIMM proposal

On 05/15/2018 07:06 PM, Dan Williams wrote: > On Tue, May 15, 2018 at 7:19 AM, George Dunlap > wrote: >> So, who decides what this SPA range and interleave set is? Can the >> operating system change these interleave sets and mappings, or change >> data from PMEM to

Re: [Xen-devel] [PATCH v2 10/10] x86/SVM: Append AMD AVIC related data to IRQ keyhandler 'i'

>>> On 07.05.18 at 23:07, wrote: > @@ -2351,6 +2352,7 @@ static void dump_irqs(unsigned char key) > printk(" %#02x -> %ps()\n", i, direct_apic_vector[i]); > > dump_ioapic_irq_info(); > +dump_avic_info(); > } While this is better than a

Re: [Xen-devel] Test for osstest, features used in Qubes OS

On Thu, May 17, 2018 at 01:26:30PM +0100, Ian Jackson wrote: > Marek Marczykowski-Górecki writes ("Test for osstest, features used in Qubes > OS"): > > As discussed some time ago, I'd like to help with adding tests for some > > features we use in Qubes OS. > > > > IMO the easiest thing to test

Re: [Xen-devel] [PATCH v1] xl: show full value of cpu_khz in xl info output

Am Tue, 3 Apr 2018 13:14:11 +0200 schrieb Olaf Hering : > The exact value of cpu_khz can only be obtained via 'xl dmesg', and > therefore can be lost after some time. 'xl info' truncates the value to > full MHz. Adjust the output to show the full khz value. > This helps the host

Re: [Xen-devel] [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration

On Thu, May 17, 2018 at 04:09:04PM +0300, Oleksandr Andrushchenko wrote: > On 05/17/2018 04:08 PM, Boris Ostrovsky wrote: > > On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote: > > > I will go with the change you suggested and > > > I'll send v4 tomorrow then. > > > > > > Please make sure

[Xen-devel] XSM in osstest, grub config, outstanding patch

Hi, I'm emailing you because I know you have an interest in XSM (and therefore in its testing in osstest). osstest manages the booting of its test hosts using the distro-supplied bootloader arrangements for its dom0s. For Debian that is update-grub. Currently, osstest has a hacked-up local copy

[Xen-devel] [PATCH v1] libxl: always call qemus xen-save-devices-state in suspend/resume

If a domU has a qemu-xen instance attached, it is required to call qemus "xen-save-devices-state" method. Without it, the receiving side of a PV migration may be unable to lock the image: xen be: qdisk-51712: xen be: qdisk-51712: error: Failed to get "write" lock error: Failed to get "write" lock

[Xen-devel] [xen-unstable-smoke test] 122898: tolerable all pass - PUSHED

flight 122898 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122898/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

Re: [Xen-devel] [RFC][PATCH] KVM: APPLES can improve the performance of applications and virtualized systems by up to 49%

On Sat, 2018-05-12 at 16:27 +0800, Weiwei Jia wrote: > We already have a prototype implementation based on KVM (Linux Kernel > 3.19.8). Our patch for Linux Kernel 3.19.8 and the paper describing > our idea are available in Github repository [1][2][3]. We are pleased > to revise our patch in order

[Xen-devel] [xen-unstable-smoke baseline test] 122899: tolerable all pass

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 122899 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122899/ Failures

Re: [Xen-devel] [PATCH] xen-hvm: stop faking I/O to access PCI config space

On Thu, May 03, 2018 at 12:18:40PM +0100, Paul Durrant wrote: > This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG > reqyests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it ^ requests > with direct calls to pci_host_config_read/write_common(). > Doing so

[Xen-devel] [distros-debian-wheezy test] 74722: all pass

flight 74722 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74722/ Perfect :-) All tests in this flight passed as required baseline version: flight 74702 jobs: build-amd64 pass

Re: [Xen-devel] [PATCHv3] xen: Add EFI_LOAD_OPTION support

On Thu, May 17, 2018 at 2:03 AM, Jan Beulich wrote: On 07.02.18 at 17:00, wrote: >> This patch as-is correctly tells the two possible formats apart. I >> tested and Xen boots correctly both from the Shell and from the >> firmware boot menu. I would

Re: [Xen-devel] Test for osstest, features used in Qubes OS

Marek / Ian, Nice to see PCI-passthrough getting some attention again. On 17/05/18 17:12, Ian Jackson wrote: > Marek Marczykowski-Górecki writes ("Re: Test for osstest, features used in > Qubes OS"): >> On Thu, May 17, 2018 at 01:26:30PM +0100, Ian Jackson wrote: >>> Is it likely that this will

Re: [Xen-devel] [PATCH] xen_pt: Present the size of 64 bit BARs correctly

On Mon, May 14, 2018 at 10:57:46AM +0100, Ross Lagerwall wrote: > The full size of the BAR is stored in the lower PCIIORegion.size. The > upper PCIIORegion.size is 0. Calculate the size of the upper half > correctly from the lower half otherwise the size read by the guest will > be incorrect. >

Re: [Xen-devel] [PATCH UPSTREAM] xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

On Thu, May 17, 2018 at 11:45:57AM -0700, Joe Jin wrote: > When run raidconfig from Dom0 we found that the Xen DMA heap is reduced, > but Dom Heap is increased by the same size. Tracing raidconfig we found > that the related ioctl() in megaraid_sas will call dma_alloc_coherent() > to apply memory.

[Xen-devel] [xen-unstable-smoke baseline test] 122901: tolerable all pass

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 122901 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122901/ Failures

[Xen-devel] ViryaOS: proposal for a new Xen Project sub-project

Hi all, Following up from previous conversations with the committers, I am appending a proposal for a new Xen Project sub-project aimed at embedded and IoT. Let me know if you have questions or suggestions. Also, sponsors are very welcome! :-) FYI, I also have a presentation on ViryaOS at Xen

[Xen-devel] [PATCH UPSTREAM] xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

When run raidconfig from Dom0 we found that the Xen DMA heap is reduced, but Dom Heap is increased by the same size. Tracing raidconfig we found that the related ioctl() in megaraid_sas will call dma_alloc_coherent() to apply memory. If the memory allocated by Dom0 is not in the DMA area, it will

  1   2   >