On 15/11/2019 15:23, George Dunlap wrote:
> On 11/15/19 2:59 PM, Andrew Cooper wrote:
>> On 15/11/2019 14:55, George Dunlap wrote:
> +p->basic.htt = false;
I think everything below here indeed simply undoes what said old
commit did, but I can't match up this one. And toget
On 11/15/19 3:34 PM, Jan Beulich wrote:
> On 15.11.2019 16:30, George Dunlap wrote:
>> On 11/15/19 3:27 PM, Jan Beulich wrote:
>>> On 15.11.2019 16:05, George Dunlap wrote:
FTR, please avoid top-posting. :-)
On 11/15/19 2:31 PM, Steven Haigh wrote:
> Just regarding the use of a s
On 11/15/19 3:26 PM, Nick Rosbrook wrote:
>> If we do have to keep the C pointer around for some reason, I think
>> using SetFinalizer is a necessary backstop to keep the library from
>> leaking. It's all well and good to say, "Make sure you call Dispose()",
>> but I think for a GC'd language that
> Yes, let's do that.
Okay, will do.
As a point of clarification, should I be waiting until you've reviewed
all patches in v1 before I send v2 of this series? Or do you prefer
that I send a v2 that addresses your review so far?
Thanks,
-NR
___
Xen-dev
On 11/15/19 3:51 PM, Nick Rosbrook wrote:
>> Yes, let's do that.
>
> Okay, will do.
>
> As a point of clarification, should I be waiting until you've reviewed
> all patches in v1 before I send v2 of this series? Or do you prefer
> that I send a v2 that addresses your review so far?
On the whole
Anthony PERARD writes ("[XEN PATCH for-4.13 v2 1/6] libxl: Introduce
libxl__ev_child_kill_deregister"):
> Allow to deregister the callback associated with a child death event.
>
> The death isn't immediate will need to be collected later, so the
> ev_child machinery register its own callback.
>
Anthony PERARD writes ("[XEN PATCH for-4.13 v2 2/6] libxl: Move
libxl__ev_devlock declaration"):
> We are going to want to include libxl__ev_devlock into libxl__ev_qmp.
>
> No functional changes.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-d
> On the whole I think sending v2 earlier is better, since I'll have the
> discussions more recently in my head, and so will (hopefully) be able to
> get an Ack or R-b more quickly.
>
> When the development window is open, stuff can be checked in as it's
> reviewed, making the whole thing easier.
>
Anthony PERARD writes ("[XEN PATCH for-4.13 v2 3/6] libxl: Rename ev_devlock to
ev_slowlock"):
> We are going to introduce a different lock based on the same
> implementation as the ev_devlock but with a different path. The
> different slowlock will be differentiated by calling different _init()
>
Anthony PERARD writes ("[XEN PATCH for-4.13 v2 4/6] libxl: Introduce
libxl__ev_slowlock_dispose"):
> Which allow to cancel the lock operation while it is in Active state.
>
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
___
Xen-devel mailing
https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
> To embed Python into an application, a new --embed option must be
> passed to python3-config --libs --embed to get -lpython3.8 (link the
> application to libpython). To support both 3.8 and older, try
>
On Fri, Nov 15, 2019 at 04:15:32PM +, Anthony PERARD wrote:
> https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
>
> > To embed Python into an application, a new --embed option must be
> > passed to python3-config --libs --embed to get -lpython3.8 (lin
flight 144144 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144144/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 143023
test-armhf-armhf-libvirt-raw 13 saveresto
Hello All,
I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
3700X and found only very few differences. I added
cpuid = [ "0x8008:ecx=0100" ]
to xl.cfg and then Windows runs great with 16 vCPUs. Cinebench R15 score
is >2050 which is more o
Anthony PERARD writes ("[XEN PATCH for-4.13 v2 6/6] libxl_qmp: Have a lock for
QMP socket access"):
> Background:
> This happens when attempting to create a guest with multiple
> pci devices passthrough, libxl creates one connection per device to
> attach and execute connect() on all a
On 11/15/19 5:06 PM, Andreas Kinzler wrote:
> Hello All,
>
> I compared the CPUID listings from Ryzen 2700X (attached as tar.xz) to
> 3700X and found only very few differences. I added
>
> cpuid = [ "0x8008:ecx=0100" ]
>
> to xl.cfg and then Windows runs great wit
On Fri, Nov 15, 2019 at 04:23:30PM +0100, Jan Beulich wrote:
> On 02.10.2019 19:16, Hongyan Xia wrote:
> > @@ -4847,22 +4848,50 @@ int mmcfg_intercept_write(
> > }
> >
> > void *alloc_xen_pagetable(void)
> > +{
> > +mfn_t mfn;
> > +
> > +mfn = alloc_xen_pagetable_new();
> > +ASSERT(
Can add weight to these findings. Tested with Xen 4.12.1 and the cpuid
line suggested and it looks like my Windows VM has come up with 4 vCPUS.
I can't RDP in to make sure its 100% booted, but it certainly isn't
doing the crash dump cycle - and CPU usage is consistent with being
successfully b
Anthony PERARD writes ("[XEN PATCH for-4.13] libxl_pci: Don't hold QMP
connection while waiting"):
> After sending the 'device_del' command for a PCI passthrough device,
> we wait until QEMU has effectively deleted the device, this involves
> executing more QMP commands. While waiting, libxl hold
flight 144141 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144141/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144035
Tests
From: Paul Durrant
Dropping the pcidevs lock between calling device_assigned() and
assign_device() means that the latter has to do the same check as the
former for no obvious gain. Also, since long running operations under
pcidevs lock already drop the lock and return -ERESTART periodically there
flight 144157 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144157/
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 Thu, Nov 14, 2019 at 10:05 PM Jan Beulich wrote:
>
> On 14.11.2019 17:07, Rishi wrote:
> > In some of our hosts, Xen is not correctly exposing processor thermal
> > capabilities to Dom0.
> > Please refer: https://bugzilla.kernel.org/show_bug.cgi?id=205347
> >
> > The flag
> > /* Thermal and Pow
Oleksandr Grytsov writes ("Re: [PATCH v1 1/2] libxl: introduce new backend type
VINPUT"):
> 1. Move QEMU_BACKEND macro to libxl__device_type structure as function
> and let the device to decide it has QEMU backend:
>
> struct libxl__device_type {
> ...
> device_qemu_backend_fn_t qemu_
From: Nick Rosbrook
After Xen summit, we started the discussion in this[1] RFC thread
to figure out how to generate Go bindings for libxl. This series
implements that Go code generation using the existing IDL, and updates
the existing hand-written code in xenlight.go to use the generated
code.
T
From: Nick Rosbrook
Define CpuidPolicyList as a string so that libxl_cpuid_parse_config can
be used in the toC function.
For now, fromC is a no-op since libxl does not support a way to read a
policy, modify it,and then give it back to libxl.
Signed-off-by: Nick Rosbrook
---
Changes in v2:
- Re
From: Nick Rosbrook
Re-name and modify signature of toGo function to fromC. The reason for
using 'fromC' rather than 'toGo' is that it is not a good idea to define
methods on the C types. Also, add error return type to Bitmap's toC function.
Finally, as code-cleanup, re-organize the Bitmap type'
From: Nick Rosbrook
Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
---
tools/golang/xenlight/xenlight.go | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/golang/xenlight/xenlight.go
b/tools/golang/xenlight/xenlight.go
index 640d82f35f..8ac26e63f0 100644
--- a/tools/golang
From: Nick Rosbrook
Define MsVmGenid as [int(C.LIBXL_MS_VM_GENID_LEN)]byte and implement fromC and
toC functions.
Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
---
tools/golang/xenlight/xenlight.go | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/g
From: Nick Rosbrook
Re-define Uuid as [16]byte and implement fromC, toC, and String functions.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 37 +--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/tools/golang/xenlight/xenlight.
From: Nick Rosbrook
Define StringList as []string an implement fromC and toC functions.
Signed-off-by: Nick Rosbrook
---
Changes in v2:
- Define fromC with a pointer receiver since a newly-allocated slice
is being assigned to the StringList.
tools/golang/xenlight/xenlight.go | 29 ++
From: Nick Rosbrook
Signed-off-by: Nick Rosbrook
Acked-by: George Dunlap
---
tools/golang/xenlight/xenlight.go | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/golang/xenlight/xenlight.go
b/tools/golang/xenlight/xenlight.go
index c2764af277..9420197bfb 100644
--- a/tools/golang/xenl
From: Nick Rosbrook
Add struct and keyed union generation to gengotypes.py. For keyed unions,
use a method similar to gRPC's oneof to interpret C unions as Go types.
Meaning, for a given struct with a union field, generate a struct for
each sub-struct defined in the union. Then, define an interfa
From: Nick Rosbrook
Define Mac as [6]byte and implement fromC, toC, and String functions.
Signed-off-by: Nick Rosbrook
---
Changes in v2:
- Fix the format string in String function to use %02x.
- Use a value reciever for the toC function.
tools/golang/xenlight/xenlight.go | 35 +++
From: Nick Rosbrook
Define KeyValueList as empty struct as there is currently no reason for
this type to be available in the Go package.
Implement fromC and toC functions as no-ops.
Signed-off-by: Nick Rosbrook
---
Changes in v2:
- Re-define KeyValueList as empty struct, as it was decided this
From: Nick Rosbrook
Define Defbool as struct analagous to the C type, and define the type
'defboolVal' that represent true, false, and default defbool values.
Implement Set, Unset, SetIfDefault, IsDefault, Val, and String functions
on Defbool so that the type can be used in Go analagously to how
From: Nick Rosbrook
Re-define Hwcap as [8]uint32, and implement toC function. Also, re-name and
modify signature of toGo function to fromC.
Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
---
Changes in v2:
- Fix comment in fromC since an array is being used now, not a slice.
- Use a c
From: Nick Rosbrook
Introduce gengotypes.py to generate Go code the from IDL. As a first step,
implement 'enum' type generation.
As a result of the newly-generated code, remove the existing, and now
conflicting definitions in xenlight.go. In the case of the Error type,
rename the slice 'errors'
From: Nick Rosbrook
Define EvLink as empty struct as there is currently no reason the internal of
this type should be used in Go.
Implement fromC and toC functions as no-ops.
Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
---
tools/golang/xenlight/xenlight.go | 10 ++
1 file
From: Nick Rosbrook
A previous commit that removed Context.CheckOpen revealed
an ineffectual assignent to err in Context.Cpupoolinfo, as
there is no error return type.
Since it appears that the intent is to return an error here,
add an error return value to the function signature.
Signed-off-by
From: Nick Rosbrook
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes.py | 39 +++-
tools/golang/xenlight/helpers.gen.go | 300 +++
2 files changed, 338 insertions(+), 1 deletion(-)
diff --git a/tools/golang/xenlight/gengotypes.py
b/tools/golang/xenli
From: Nick Rosbrook
Switch over union key to determine how to populate 'union' in Go struct.
Since the unions of C types cannot be directly accessed, add C structs in
cgo preamble to assist in marshaling keyed unions. This allows the C
type defined in the preamble to be populated first, and then
From: Nick Rosbrook
Implement conversion of basic type conversions such as strings
and integer types in toC functions.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes.py | 80 ++
tools/golang/xenlight/helpers.gen.go | 1015 ++
2 files changed, 1095
From: Nick Rosbrook
Since the C union cannot be directly populated, populate the fields of the
corresponding C struct defined in the cgo preamble, and then copy that
struct as bytes into the byte slice that Go uses as the union.
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes
From: Nick Rosbrook
Implement basic type conversion in fromC functions such as strings and
integer types. Also, remove existing toGo functions from xenlight.go in
favor of the new generated functions.
Signed-off-by: Nick Rosbrook
---
Changes in v2:
- Add Makefile changes for helpers.gen.go.
- R
From: Nick Rosbrook
Signed-off-by: Nick Rosbrook
---
tools/golang/xenlight/gengotypes.py | 44 +++-
tools/golang/xenlight/helpers.gen.go | 359 +++
2 files changed, 402 insertions(+), 1 deletion(-)
diff --git a/tools/golang/xenlight/gengotypes.py
b/tools/golang/xenli
From: Nick Rosbrook
Remove the exported global context variable, 'Ctx.' Generally, it is
better to not export global variables for use through a Go package.
However, there are some exceptions that can be found in the standard
library.
Add a NewContext function instead, and remove the Open, IsOpe
On Fri, Nov 15, 2019 at 6:30 AM Jan Beulich wrote:
>
> Andy,
>
> On 29.10.2019 10:28, Jan Beulich wrote:
> > Once again RPL checks have been introduced which don't account for a
> > 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> > case in FIXUP_FRAME has been preventing boot
This is an update to Ian Campbell's work to route timer PPIs to guests
[1].
I attempted to address most of the feedback on v2 of the series. There
are a couple of comments I was unsure about - instances of this are
noted in the individual patches.
Highlights in v3:
* Rebase
* Tested on QEMU
From: Ian Campbell
Split out the bit which allocates the struct irqaction and calls
__setup_irq into a new function (setup_guest_irq). I'm going to want
to call this a second time in a subsequent patch.
Note that the action is now allocated and initialised with the desc
lock held (since it is ta
From: Ian Campbell
s/it/if/ makes more sense.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall [1]
Acked-by: Stefano Stabellini [2]
[1] https://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00986.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02645.ht
From: Ian Campbell
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall [1]
Acked-by: Stefano Stabellini [2]
[1] https://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00985.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02646.html
---
v3:
* Rebase (no c
It only had 1 caller.
Reverse the condition for readability.
Signed-off-by: Stewart Hildebrand
---
v3: new patch
---
xen/arch/arm/irq.c| 9 ++---
xen/include/asm-arm/irq.h | 2 --
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
There are some IRQs that happen to have multiple "interrupts = < ... >;"
properties with the same IRQ in the device tree. For example:
interrupts = <0 123 4>,
<0 123 4>,
<0 123 4>,
<0 123 4>,
<0 123 4>;
In this case it seems that we are invoking
Allow vgic_get_hw_irq_desc to be called with a vcpu argument.
Use vcpu argument in vgic_connect_hw_irq.
vgic_connect_hw_irq is called for PPIs and SPIs, not SGIs. Enforce with
ASSERTs.
Signed-off-by: Stewart Hildebrand
---
v3: new patch
---
Note: I have only modified the old vgic to allow del
From: Ian Campbell
Make use of the GICD I[SC]ACTIVER registers to save and
restore the active state of the interrupt.
For edge triggered interrupts we also need to context switch the
pending bit via I[SC]PENDR. Note that for level triggered interrupts
SPENDR sets a latch which is only cleared by
These will be used in a follow-up patch.
Signed-off-by: Stewart Hildebrand
---
v3: new patch
---
xen/include/asm-arm/irq.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 3b37a21c06..367fe6269c 100644
--- a/xen/in
From: Ian Campbell
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does).
By using the newly added hwppi save/restore functionality we make use
of the GICD I[SC]ACTIVER r
From: Ian Campbell
That is whichever vcpu is resident when the interrupt fires. An
interrupt is in this state when both IRQ_GUEST and IRQ_PER_CPU are set
in the descriptor status. Only PPIs can be in this mode.
This requires some peripheral specific code to make use of the
previously introduced
From: Ian Campbell
Just for testing so the guest vtimer ppi it isn't the same as the
physical virt timer PPI on my platform, and therefore allows to
exercise the non-1:1 bits of the code.
---
xen/include/public/arch-arm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/in
flight 144151 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144151/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0b9ad0bc030bbd79073a26fc9b3527ff9128b9da
baseline version:
ovmf 6fe77f347ed820c5924f2
NOTE: this may or may not be a hair on fire problem, reporting it
anyway since I'd hate to pass on something that maybe a serious issue.
I haven't had time to debug this just yet -- so just reporting it here
pretty raw.
Software:
Xen 4.13 RC2
Linux kernel 4.19.5
Hardware:
Supermicro E300
flight 144149 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144149/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144042
test-amd64
On 11/15/19 6:06 AM, Roger Pau Monné wrote:
> On Fri, Nov 15, 2019 at 05:23:51AM +, Tian, Kevin wrote:
>>> From: Roger Pau Monne [mailto:roger@citrix.com]
>>> Sent: Friday, November 8, 2019 9:34 PM
>>>
>>> When using posted interrupts and the guest migrates MSI from vCPUs Xen
>>> needs to f
flight 144152 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144152/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
Hi,
I am not commenting on the code itself but the process.
On Thu, 14 Nov 2019, 07:59 Julian Tuminaro,
wrote:
> From: Julian Tuminaro and Jenish Rakholiya rakholiyajenish...@gmail.com>
>
AFAICT this is the first time we have such format for "From".
We usually have one person listed per tag
CC Wei's correct e-mail address.
On Sat, 16 Nov 2019, 05:44 Julien Grall, wrote:
> Hi,
>
> I am not commenting on the code itself but the process.
>
> On Thu, 14 Nov 2019, 07:59 Julian Tuminaro,
> wrote:
>
>> From: Julian Tuminaro and Jenish Rakholiya > and rakholiyajenish...@gmail.com>
>>
>
>
flight 144154 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144154/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 144120
test-amd64-amd64-xl-qemuu-win7-amd6
Hi!
as I've reported earlier -- part of my testing of Xen 4.13 RC2 failed
in a massive way with Dom0 never coming up. I've traced that problem
to the option that we're using to boot Xen:
efi=no-rs
We've been using this option for quite sometime and Xen 4.13 RC2
is the first one that seems to m
The current code is a pretty good wtf moment, since we drop the
reference before we use it. It's not a big deal, because a) we only
use the pointer, so doesn't blow up and the real reason b) fb->obj[0]
already holds a full reference for us.
Might as well take the real pointer ins't of complicated
On 11/14/19 10:44 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> These functions now have a third parameter of type const *libxl_asyncop_how.
>
> Pass nil for this argument to fix compilation and maintain the
> synchronous behavior.
>
> Signed-off-by: Nick Rosbrook
Actually this has alrea
On 14.11.2019 18:29, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 14 November 2019 16:42
>> To: xen-devel@lists.xenproject.org
>> Cc: Juergen Gross ; Sander Eikelenboom
>> ; Andrew Cooper
>> Subject: [Xen-devel] [PATCH v2 0/2] AMD/IO
On 14.11.2019 20:28, Andrew Cooper wrote:
> On 14/11/2019 15:22, Jan Beulich wrote:
>> As per SDM rev 071 Cannon Lake has
>> - no CC3 residency MSR at 3FC,
>> - a CC1 residency MSR ar 660 (like various Atoms),
>> - a useless (always zero) CC3 residency MSR at 662.
>>
>> Signed-off-by: Jan Beulich
flight 144124 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144042
Tests whic
On 14.11.2019 19:10, Roger Pau Monné wrote:
> On Thu, Nov 14, 2019 at 04:56:35PM +0100, Jan Beulich wrote:
>> On 14.11.2019 14:12, Roger Pau Monné wrote:
>>> On Thu, Nov 14, 2019 at 12:43:33PM +0100, Jan Beulich wrote:
On 14.11.2019 10:38, Roger Pau Monné wrote:
> On Wed, Nov 13, 2019 a
branch xen-4.12-testing
xenbranch xen-4.12-testing
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-install/l1/l2
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree:
On Fri, Nov 15, 2019 at 10:44:22AM +0100, Jan Beulich wrote:
> On 14.11.2019 19:10, Roger Pau Monné wrote:
> > On Thu, Nov 14, 2019 at 04:56:35PM +0100, Jan Beulich wrote:
> >> On 14.11.2019 14:12, Roger Pau Monné wrote:
> >>> On Thu, Nov 14, 2019 at 12:43:33PM +0100, Jan Beulich wrote:
> On
On 14.11.2019 19:05, Anthony PERARD wrote:
> With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile
> will attempt to build that object. This result in the dependency file
> been generated with relocs-dummy.o depending on efi/relocs-dummy.o.
I cannot confirm this, what I see is
efi
On Fri, Nov 15, 2019 at 08:04:14AM +0100, Juergen Gross wrote:
> libxl__dm_resume() is using a wrong timeout for the start of the
> device model. Instead of 60 seconds the timeout is set to 60
> milliseconds.
>
> Reported-by: Roman Shaposhnik
> Fixes: 6298f0eb8f4437 ("libxl: Re-introduce libxl__d
On 15.11.19 11:26, Wei Liu wrote:
On Fri, Nov 15, 2019 at 08:04:14AM +0100, Juergen Gross wrote:
libxl__dm_resume() is using a wrong timeout for the start of the
device model. Instead of 60 seconds the timeout is set to 60
milliseconds.
Reported-by: Roman Shaposhnik
Fixes: 6298f0eb8f4437 ("lib
On 11/15/19 11:21 AM, Daniel Vetter wrote:
> The current code is a pretty good wtf moment, since we drop the
> reference before we use it. It's not a big deal, because a) we only
> use the pointer, so doesn't blow up and the real reason b) fb->obj[0]
> already holds a full reference for us.
>
> Mig
1: fix clang .macro retention check
2: clang: move and fix .skip check
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
From: Roger Pau Monné
.skip is only used by x86 code, so place the clang .skip with labels
check in x86/Rules.mk instead of the top level Rules.mk. While there
also fix an issue with it by removing the '\n' which triggers the
following error:
:1:31: error: missing terminating '"' character
[-We
There were two problems here: The first closing parentheses got parsed
by make to end the $(call invocation, and the escaping of the quotes
wasn't right either, as there's nowhere they would get un-escaped.
Furthermore there appears to be a puzzling problem with \n getting
expanded to an actual ne
On Thu, Nov 07, 2019 at 10:29:30PM +, Lars Kurth wrote:
> Dear Community Members,
>
> Juergen will be stepping down as Release Manager after Xen 4.13 has
> been delivered, following the 4.11 and 4.12 release. Release managers
> prior to Juergen were Julien Grall, Konrad Wilk, Wei Liu and Geor
Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
guests") attempted to "fake up" a topology which would induce guest
operating systems to not treat vcpus as sibling hyperthreads. This
involved (among other things) actually reporting hyperthreading as
available, but giving vcp
On 14.11.2019 12:29, Jan Beulich wrote:
On 14.11.2019 00:10, Andreas Kinzler wrote:
I came across the following: https://lkml.org/lkml/2019/8/29/536
Could that be the reason for the problem mentioned below? Xen is using
HPET as clocksource on the platform/mainboard. Is there an (easy) way to
ver
On 15.11.2019 11:57, George Dunlap wrote:
> Open questions:
>
> - Is this the right place to put the `getenv` check?
>
> - Is there any way we can make migration work, at least in some cases?
>
> - Can we check for known-problematic models, and at least report a
> more useful error?
Checking
On 15.11.2019 11:57, George Dunlap wrote:
Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
guests") attempted to "fake up" a topology which would induce guest
operating systems to not treat vcpus as sibling hyperthreads. This
involved (among other things) actually reporting
flight 144138 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144138/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6fe77f347ed820c5924f2ac6ddc43aa869cdbd5e
baseline version:
ovmf da178f5c5c5832476d37c
> -Original Message-
> From: Lars Kurth
> Sent: 07 November 2019 22:30
> To: xen-devel ; Juergen Gross
>
> Cc: committ...@xenproject.org; Durrant, Paul ; Brian
> Woods
> Subject: Call for new Release Manager for Xen 4.14+
>
> Dear Community Members,
>
> Juergen will be stepping down as
On 11/15/19 11:17 AM, Andreas Kinzler wrote:
> On 15.11.2019 11:57, George Dunlap wrote:
>> Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
>> guests") attempted to "fake up" a topology which would induce guest
>> operating systems to not treat vcpus as sibling hyperthreads.
On 13/11/2019 13:50, Jan Beulich wrote:
> Commit 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs right after table
> allocation") moved ourselves into a more secure default state, but
> didn't take sufficient care to also undo the effects when handing a
> previously disabled device back to a(nother) doma
> -Original Message-
> From: Jan Beulich
> Sent: 15 November 2019 09:29
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Sander Eikelenboom ;
> Juergen Gross
> Subject: Re: [Xen-devel] [PATCH v2 0/2] AMD/IOMMU: re-work mode updating
>
> On 14.11.2019 18:29, D
On 15.11.2019 12:29, George Dunlap wrote:
On 11/15/19 11:17 AM, Andreas Kinzler wrote:
I do not understand a central point: No matter why and/or how a fake
topology is presented by Xen, why did the older generation Ryzen 2xxx
work and Ryzen 3xxx doesn't? What is the change in AMD(!) not Xen that
On 15/11/2019 11:33, Durrant, Paul wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 15 November 2019 09:29
>> To: Durrant, Paul
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Sander Eikelenboom ;
>> Juergen Gross
>> Subject: Re: [Xen-devel] [PATCH v2 0/2] AMD/IOMMU:
On 14/11/2019 22:36, Tamas K Lengyel wrote:
> On Thu, Nov 14, 2019 at 11:39 AM Andrew Cooper
> wrote:
>> On 14/11/2019 18:34, Tamas K Lengyel wrote:
>>> * Comments: All works, altp2m+introspection requires the ept=pml=0
>>> boot flag specified to workaround a deadlock in Xen
>> Is this separate fr
On 11/15/19 11:12 AM, Jan Beulich wrote:
> On 15.11.2019 11:57, George Dunlap wrote:
>> Open questions:
>>
>> - Is this the right place to put the `getenv` check?
>>
>> - Is there any way we can make migration work, at least in some cases?
>>
>> - Can we check for known-problematic models, and at l
On 11/15/19 11:39 AM, Andreas Kinzler wrote:
> On 15.11.2019 12:29, George Dunlap wrote:
>> On 11/15/19 11:17 AM, Andreas Kinzler wrote:
>>> I do not understand a central point: No matter why and/or how a fake
>>> topology is presented by Xen, why did the older generation Ryzen 2xxx
>>> work and Ry
On Fri, Nov 15, 2019 at 11:06:27AM +0100, Jan Beulich wrote:
> On 14.11.2019 19:05, Anthony PERARD wrote:
> > With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile
> > will attempt to build that object. This result in the dependency file
> > been generated with relocs-dummy.o depend
1 - 100 of 166 matches
Mail list logo
