On 13.08.2020 11:45, Roger Pau Monné wrote:
> On Thu, Aug 13, 2020 at 09:10:31AM +0100, Paul Durrant wrote:
>>> -Original Message-
>>> From: Xen-devel On Behalf Of David
>>> Woodhouse
>>> Sent: 11 August 2020 14:25
>>> To: Paul Durrant ; xen-devel@lists.xenproject.org;
>>> Roger Pau Monn
On 18.08.2020 14:47, Roger Pau Monné wrote:
> On Tue, Aug 18, 2020 at 02:01:35PM +0200, Marek Marczykowski-Górecki wrote:
>> On Mon, Aug 17, 2020 at 11:00:13AM +0200, Roger Pau Monné wrote:
>>> On Sun, Aug 16, 2020 at 02:19:49AM +0200, Marek Marczykowski-Górecki wrote:
In case of Xen PV dom0,
On 18.08.2020 15:00, Roger Pau Monné wrote:
> On Fri, Aug 07, 2020 at 01:32:38PM +0200, Jan Beulich wrote:
>> There's no need for xen.efi at all, and there's also no need for EFI
>> support in xen.gz since the shim runs in PVH mode, i.e. without any
>> firmware (and hence by implication also withou
On 18.08.2020 15:08, Roger Pau Monné wrote:
> On Fri, Aug 07, 2020 at 01:35:08PM +0200, Jan Beulich wrote:
>> There is no need for platform-wide, system-wide, or per-domain control
>> in this case. Hence avoid including this dead code in the build.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by
> On 18 Aug 2020, at 18:34, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 18/08/2020 18:06, Bertrand Marquis wrote:
>>> On 18 Aug 2020, at 17:43, Julien Grall wrote:
>>>
>>>
>>>
>>> On 18/08/2020 17:35, Bertrand Marquis wrote:
Hi Julien,
>>>
>>> Hi Bertrand,
>>>
Somehow we stoppe
On 19.08.2020 09:59, Bertrand Marquis wrote:
>> On 18 Aug 2020, at 18:34, Julien Grall wrote:
Btw - is there any need for this thread to be cross posted to both
xen-devel@ and security@? (I've dropped the latter here.)
Jan
>> On 18/08/2020 18:06, Bertrand Marquis wrote:
On 18 Aug 2020, at
> On 18 Aug 2020, at 20:29, Hubert Jasudowicz wrote:
>
> When ipxe.bin is missing, make uninstall will fail due to
> wrong switch (-r) passed to rm command. Replace it with -f.
>
Having a make uninstall is quite unusual.
But the modification looks right so ...
> Signed-off-by: Hubert Jasud
On 07.08.2020 19:14, Andrew Cooper wrote:
> On 07/08/2020 12:33, Jan Beulich wrote:
>> While this won't affect overall memory overhead (struct vcpu as well as
>> struct domain get allocated as single pages) nor code size (the offsets
>> into the base structures are too large to be representable as
On 07.08.2020 19:50, Andrew Cooper wrote:
> On 07/08/2020 12:33, Jan Beulich wrote:
>> --- a/xen/common/bitmap.c
>> +++ b/xen/common/bitmap.c
>> @@ -384,3 +386,87 @@ void bitmap_byte_to_long(unsigned long *
>> }
>>
>> #endif
>> +
>> +int bitmap_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_bitm
(Adding back security)
Hi Jan,
On 19/08/2020 09:02, Jan Beulich wrote:
On 19.08.2020 09:59, Bertrand Marquis wrote:
On 18 Aug 2020, at 18:34, Julien Grall wrote:
Btw - is there any need for this thread to be cross posted to both
xen-devel@ and security@? (I've dropped the latter here.)
Fr
On 19.08.2020 10:50, Julien Grall wrote:
> On 19/08/2020 09:02, Jan Beulich wrote:
>> On 19.08.2020 09:59, Bertrand Marquis wrote:
On 18 Aug 2020, at 18:34, Julien Grall wrote:
>>
>> Btw - is there any need for this thread to be cross posted to both
>> xen-devel@ and security@? (I've dropped
On 19.08.2020 11:09, Roger Pau Monne wrote:
> vpic_elcr_mask wasn't using the v parameter, and instead worked
> because in the context of the callers v would be vpic. Fix this by
> correctly using the parameter. While there also remove the unneeded
> casts to uint8_t and the ending semicolon.
>
>
On 17.08.2020 13:50, Roger Pau Monné wrote:
> FWIW x86 already has a specific handler for 128bit values: cmpxchg16b.
> Maybe it would be better to name this cmpxchg8b? Or rename the
> existing one to cmpxchg128 for coherence.
cmpxchg16b() is named after the underlying insn. If we gain
cmpxchg64(),
On 17.08.2020 15:03, Julien Grall wrote:
> On 17/08/2020 12:50, Roger Pau Monné wrote:
>> On Mon, Aug 17, 2020 at 12:05:54PM +0100, Julien Grall wrote:
>>> The only way I could see to make it work would be to use the same trick as
>>> we do for {read, write}_atomic() (see asm-arm/atomic.h). We are
On Tue, Aug 18, 2020 at 08:43:56PM -0700, Elliott Mitchell wrote:
> On Wed, Aug 19, 2020 at 04:00:36AM +0200, Marek Marczykowski-G??recki wrote:
> > diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> > index f360f5e228..b039143b8a 100644
> > --- a/tools/libxl/libxl_utils.c
> > +++
On 19/08/2020 09:58, Jan Beulich wrote:
On 19.08.2020 10:50, Julien Grall wrote:
On 19/08/2020 09:02, Jan Beulich wrote:
On 19.08.2020 09:59, Bertrand Marquis wrote:
On 18 Aug 2020, at 18:34, Julien Grall wrote:
Btw - is there any need for this thread to be cross posted to both
xen-devel@ a
flight 152618 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152618/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 391a8b6d20b72c4f24f8511f78ef75a6119cbe22
baseline version:
xen 7a4d
Hi,
On 13/08/2020 11:36, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in omapdrm.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/omap
On Wed, Aug 19, 2020 at 11:30:57AM +0100, Ian Jackson wrote:
> Marek Marczykowski-G??recki writes ("Re: [PATCH 2/2] libxl: fix
> -Werror=stringop-truncation in libxl__prepare_sockaddr_un"):
> > On Tue, Aug 18, 2020 at 08:43:56PM -0700, Elliott Mitchell wrote:
> > > On Wed, Aug 19, 2020 at 04:00:36
On 19.08.2020 10:19, Roger Pau Monné wrote:
On Tue, Aug 18, 2020 at 08:40:18PM +0200, Marek Marczykowski-Górecki wrote:
On Tue, Aug 18, 2020 at 07:21:14PM +0200, Roger Pau Monné wrote:
Let me draw the picture from the beginning.
Thanks, greatly appreciated.
EFI memory map contains various
flight 152613 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152613/
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 1
On Wed, Aug 19, 2020 at 09:33:47AM +0200, Jan Beulich wrote:
> On 18.08.2020 15:00, Roger Pau Monné wrote:
> > On Fri, Aug 07, 2020 at 01:32:38PM +0200, Jan Beulich wrote:
> >> There's no need for xen.efi at all, and there's also no need for EFI
> >> support in xen.gz since the shim runs in PVH mod
On Tue, Aug 18, 2020 at 08:40:18PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 18, 2020 at 07:21:14PM +0200, Roger Pau Monné wrote:
> > > Let me draw the picture from the beginning.
> >
> > Thanks, greatly appreciated.
> >
> > > EFI memory map contains various memory regions. Some of t
On Wed, Aug 19, 2020 at 09:12:02AM +0200, Jan Beulich wrote:
> On 13.08.2020 11:45, Roger Pau Monné wrote:
> > On Thu, Aug 13, 2020 at 09:10:31AM +0100, Paul Durrant wrote:
> >>> -Original Message-
> >>> From: Xen-devel On Behalf Of
> >>> David Woodhouse
> >>> Sent: 11 August 2020 14:25
>
Currently I only know how to get this assert with debug=y and hvm_fep
enabled. The attached test code should reproduce this. This happens
when any guest does the "ud2 xen" inl that uses QEMU. Port 0x3f1 is
what I use to reproduce this.
My understanding is that it is possible to get to the x8
The upgrades are now done and I have just restarted osstest.
There are still some loose ends but I think we should be able to deal
with them without another big outage.
Thanks,
Ian.
vpic_elcr_mask wasn't using the v parameter, and instead worked
because in the context of the callers v would be vpic. Fix this by
correctly using the parameter. While there also remove the unneeded
casts to uint8_t and the ending semicolon.
No functional change intended.
Signed-off-by: Roger Pau
Marek Marczykowski-Górecki writes ("[PATCH 1/2] libxl: workaround gcc 10.2
maybe-uninitialized warning"):
> It seems xlu_pci_parse_bdf has a state machine that is too complex for
> gcc to understand. The build fails with:
Reviewed-by: Ian Jackson
Marek Marczykowski-G??recki writes ("Re: [PATCH 2/2] libxl: fix
-Werror=stringop-truncation in libxl__prepare_sockaddr_un"):
> On Tue, Aug 18, 2020 at 08:43:56PM -0700, Elliott Mitchell wrote:
> > On Wed, Aug 19, 2020 at 04:00:36AM +0200, Marek Marczykowski-G??recki wrote:
> > > diff --git a/tools
Hi Manikandan,
> On 19 Aug 2020, at 15:00, Manikandan Chockalingam (RBEI/ECF3)
> wrote:
>
> Hello Bertrand,
>
> I tried to build Xen on RCAR with the following build configuration.
>
> Build Configuration:
> BB_VERSION= "1.30.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING
This works better with some quirk of the networking we seem to now
have after the buster upgrade to the colo systems.
To avoid blocking on resolving that issue, change the the config.
Signed-off-by: Ian Jackson
---
production-config | 1 +
1 file changed, 1 insertion(+)
diff --git a/production
flight 152622 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152622/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
From: Don Slutz
This allows use of QEMU's VMware emulated video card
NOTE: vga=vmware is not supported by device_model_version=qemu-xen-traditional
Signed-off-by: Don Slutz
CC: Don Slutz
---
Acked-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk
v14:
Reworked to current code.
Added
From: Don Slutz
This is used to set xen_arch_domainconfig vmware_hw. It is set to
the emulated VMware virtual hardware version.
Currently 0, 3-4, 6-11 are good values. However the code only
checks for == 0, != 0, or < 7.
Signed-off-by: Don Slutz
CC: Don Slutz
---
Acked-by: Ian Campbell
v14
From: Don Slutz
This is done by adding xen_arch_domainconfig vmware_hw. It is set to
the VMware virtual hardware version.
Currently 0, 3-4, 6-11 are good values. However the
code only checks for == 0 or != 0 or >= 7.
If non-zero then
Return VMware's cpuid leaves. If >= 7 return data, else
From: Don Slutz
https://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01105.html
Is the last message on the list. I do not have this message to directly
reply to. I plan to try and continue this as part of this version.
Changes v13 to v14:
Rebased on staging (not a simple rebase,
From: Don Slutz
This includes adding is_vmware_port_enabled
This is a new xen_arch_domainconfig flag,
XEN_DOMCTL_CONFIG_VMWARE_PORT_MASK.
This enables limited support of VMware's hyper-call.
This is both a more complete support then in currently provided by
QEMU and/or KVM and less. The missi
From: Don Slutz
This adds synchronization of the 6 vcpu registers (only 32bits of
them) that QEMU's vmport.c and vmmouse.c needs between Xen and QEMU.
This is how VMware defined the use of these registers.
This is to avoid a 2nd and 3rd exchange between QEMU and Xen to
fetch and put these 6 vcpu
From: Don Slutz
Also added missing TRAP_DEBUG & VLAPIC.
Signed-off-by: Don Slutz
CC: Don Slutz
---
Acked-by: Ian Campbell
v14:
Reworked to current code.
Added VMPORT_SEND because I wanted to see it during testing.
v13:
Please do this by extending the existing infrastructure rather
From: Don Slutz
This file: backdoor_def.h comes from:
http://packages.vmware.com/tools/esx/3.5latest/rhel4/SRPMS/index.html
open-vm-tools-kmod-7.4.8-396269.423167.src.rpm
open-vm-tools-kmod-7.4.8.tar.gz
vmhgfs/backdoor_def.h
and is unchanged.
Added the badly named include file includeChe
From: Don Slutz
This new libxl_domain_create_info field is used to set
XEN_DOMCTL_CONFIG_VMWARE_PORT_MASK in the xc_domain_configuration_t
for x86.
In xen it is is_vmware_port_enabled.
If is_vmware_port_enabled then
enable a limited support of VMware's hyper-call.
VMware's hyper-call is also
On 7/10/20 5:01 AM, Jürgen Groß wrote:
On 10.07.20 13:55, Jan Beulich wrote:
On 10.07.2020 12:50, Jürgen Groß wrote:
On 10.07.20 11:49, Jan Beulich wrote:
On 10.07.2020 09:50, Juergen Gross wrote:
For support of long running hypercalls xen_maybe_preempt_hcall() is
calling cond_resched() in ca
On Wed, Aug 19, 2020 at 11:30:57AM +0100, Ian Jackson wrote:
> Marek Marczykowski-G??recki writes ("Re: [PATCH 2/2] libxl: fix
> -Werror=stringop-truncation in libxl__prepare_sockaddr_un"):
> > On Tue, Aug 18, 2020 at 08:43:56PM -0700, Elliott Mitchell wrote:
> > > On Wed, Aug 19, 2020 at 04:00:36
flight 152615 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152615/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 152573
test-armhf-armhf-xl-rtds 16 gue
Hello Bertrand,
I tried to build Xen on RCAR with the following build configuration.
Build Configuration:
BB_VERSION= "1.30.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS= "aarch64-poky-linux"
MACHINE = "salvator-x"
DISTRO= "
On Tue, Aug 18, 2020 at 03:53:16PM +0100, Andrew Cooper wrote:
> On 17/08/2020 16:57, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> > index ca3bbfcbb3..671cdcb724 100644
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> >
Ian Jackson (7):
ts-hosts-allocate-Executive: Fix broken call to $duration_estimator
resource allocation: Provide OSSTEST_ALLOC_FAKE_PLAN test facility
ts-hosts-allocate-Executive: Do a pre-check
duration estimates: Memoise results
host allocation: Memoise duration estimates
host alloca
Call attempt_allocation with an empty plan and $mayalloc=0.
In the usual case this will arrange to prime our memoisation caches
before we get involved with the queueing system.
It will also arrange for various errors to be reported sooner.
Signed-off-by: Ian Jackson
---
ts-hosts-allocate-Execu
We look at our own branch to estimate durations. If somehow we are
one of multiple concurrent flights on this branch with the appropriate
blessing, we don't mind not noticing the doing of our peer flights so
that if our estimates are a bit out of date.
So it is fine to use an estimate no older th
This provides a very significant speedup.
Signed-off-by: Ian Jackson
---
ts-hosts-allocate-Executive | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 39c66346..a47bc499 100755
--- a/ts-hosts-allocate-Ex
We often use flight number as a proxy for ordering, but this is not
always appropriate and not always done (and sometimes it's a bit of a
bodge).
Provide an index to find flights by start time. This significantly
speeds up the host allocation $equivstatusq query, and the duration
estimator.
(I h
Set this variable (to a data-plan.final.pl, say) and it becomes
possible to test host allocation programs without actually allocating
anything and without engaging with the queue system.
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 26 ++
1 file changed, 26 inser
The caller may provide a memoisation hash. If they don't we embed
one in the estimator.
The estimator contains a db statement handle so shouldn't be so
long-lived that this gives significantly wrong answers.
I am aiming this work at ts-hosts-allocate-Executive, but it is
possible that this might
The debug subref is passed to the constructor (and indeed we do that).
The final argument to the actual estimator is $uptoincl_testid (but we
didn't say $will_uptoincl_testid, so it is ignored).
The code was wrong, but with no effect. So no functional change.
Signed-off-by: Ian Jackson
---
ts-
flight 152614 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152614/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 152562
Tests which did not succeed, b
Hi!
below you can see a trace of Xen 4.14.0 failing on Dell IoT Gateway 3001
without efi=no-rs. Please let me know if I can provide any additional
information.
One interesting point is that even though Xen tries to reboot the box in 5
seconds
it simply freezes it completely.
Thanks,
Roman.
Xen
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
frontend").
The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58, v4.19.139.
v5.8.1: Build OK!
v5.7.15: Buil
From: Boris Ostrovsky
[ Upstream commit 8b1e868f66076490189a36d984fcce286cdd6295 ]
xen_alloc_coherent_pages might return pages for which virt_to_phys and
virt_to_page don't work, e.g. ioremap'ed pages.
So in xen_swiotlb_free_coherent we can't assume that virt_to_page works.
Instead add a is_vma
From: Boris Ostrovsky
[ Upstream commit 8b1e868f66076490189a36d984fcce286cdd6295 ]
xen_alloc_coherent_pages might return pages for which virt_to_phys and
virt_to_page don't work, e.g. ioremap'ed pages.
So in xen_swiotlb_free_coherent we can't assume that virt_to_page works.
Instead add a is_vma
From: Boris Ostrovsky
[ Upstream commit 8b1e868f66076490189a36d984fcce286cdd6295 ]
xen_alloc_coherent_pages might return pages for which virt_to_phys and
virt_to_page don't work, e.g. ioremap'ed pages.
So in xen_swiotlb_free_coherent we can't assume that virt_to_page works.
Instead add a is_vma
The typedef was used in the XENBACKEND_DEVICE macro, but it was
never defined. Define the typedef close to the type checking
macro.
Signed-off-by: Eduardo Habkost
---
Changes series v1 -> v2: new patch in series v2
---
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Paul Durrant
Cc: xen-devel@
On 8/18/20 12:32 AM, Souptick Joarder wrote:
> In 2019, we introduced pin_user_pages*() and now we are converting
> get_user_pages*() to the new API as appropriate. [1] & [2] could
> be referred for more information. This is case 5 as per document [1].
>
> [1] Documentation/core-api/pin_user_page
Hi Konrad,
ping.
I am still seeing this build error. It looks like this is
in your territory to merge...
On 8/13/20 4:00 PM, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix build error when CONFIG_ACPI is not set/enabled:
>
> ../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
> ../arch/x86/
flight 152617 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152617/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a048af3c9073e4b8108e6cf920bbb35574059639
baseline version:
ovmf 7f7f511c5a74676523ed4
Hi xen-devel,
I am very interesting about the VIRTIO on Xen. And from one meeting report
of AGL Virtualization Expert Group (EG-VIRT)
https://wiki.automotivelinux.org/eg-virt-meetings#pm_cest_meeting4, I got
the information that ARM and Linaro are
upstreaming XEN work incorporating VirtIO. But I c
On 19.08.20 18:57, Sarah Newman wrote:
On 7/10/20 5:01 AM, Jürgen Groß wrote:
On 10.07.20 13:55, Jan Beulich wrote:
On 10.07.2020 12:50, Jürgen Groß wrote:
On 10.07.20 11:49, Jan Beulich wrote:
On 10.07.2020 09:50, Juergen Gross wrote:
For support of long running hypercalls xen_maybe_preempt
On Thu, Aug 20, 2020 at 07:13:00AM +0200, Jürgen Groß wrote:
> On 19.08.20 18:57, Sarah Newman wrote:
> > On 7/10/20 5:01 AM, Jürgen Groß wrote:
> > > On 10.07.20 13:55, Jan Beulich wrote:
> > > > On 10.07.2020 12:50, Jürgen Groß wrote:
> > > > > On 10.07.20 11:49, Jan Beulich wrote:
> > > > > > On
flight 152616 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152616/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
test-amd64-i386-xl-
On 20.08.20 07:44, Greg Kroah-Hartman wrote:
On Thu, Aug 20, 2020 at 07:13:00AM +0200, Jürgen Groß wrote:
On 19.08.20 18:57, Sarah Newman wrote:
On 7/10/20 5:01 AM, Jürgen Groß wrote:
On 10.07.20 13:55, Jan Beulich wrote:
On 10.07.2020 12:50, Jürgen Groß wrote:
On 10.07.20 11:49, Jan Beulich
On Thu, Aug 20, 2020 at 07:58:55AM +0200, Jürgen Groß wrote:
> On 20.08.20 07:44, Greg Kroah-Hartman wrote:
> > On Thu, Aug 20, 2020 at 07:13:00AM +0200, Jürgen Groß wrote:
> > > On 19.08.20 18:57, Sarah Newman wrote:
> > > > On 7/10/20 5:01 AM, Jürgen Groß wrote:
> > > > > On 10.07.20 13:55, Jan B
70 matches
Mail list logo
