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
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
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>
>>
>
>
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
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
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
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
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 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
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
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
... 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
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
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
---
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
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
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
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
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
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]
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
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
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,
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
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
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
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
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.
-
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.
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
---
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
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
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
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
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
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
---
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
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
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
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
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
---
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
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:
-
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.
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
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
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
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
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
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
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
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();
> > +
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
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
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
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
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
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
>
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
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()
> 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 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
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
> 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
___
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
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
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
flight 144155 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144155/
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
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 system environment variable to turn this
On 15.11.19 16:19, Tamas K Lengyel wrote:
On Fri, Nov 15, 2019 at 4:56 AM Andrew Cooper wrote:
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
On 15.11.2019 16: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
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 system environment variable to turn this
>>> feature / bugfix / hack on and off - this would
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 system environment variable to turn this
>> feature / bugfix / hack on and off - this would probably break starting
>> the VM via the
> 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's just going to be too easy to
> forget; and
On Fri, 15 Nov 2019, 18:13 Andrew Cooper, wrote:
> On 31/10/2019 21:25, Julien Grall wrote:
> > Hi,
> >
> > On 31/10/2019 19:28, Andrew Cooper wrote:
> >> This code is especially tangled. VCPUOP_initialise calls into
> >> arch_initialise_vcpu() which calls back into default_initialise_vcpu()
>
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 together with the
>>> question of whether instead
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(!mfn_eq(mfn, INVALID_MFN));
> +
> +return map_xen_pagetable_new(mfn);
> +}
>
On Fri, Nov 15, 2019 at 4:56 AM Andrew Cooper wrote:
>
> 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
On Fri, Nov 15, 2019 at 04:00:42PM +0100, Jan Beulich wrote:
> On 15.11.2019 15:45, Roger Pau Monné wrote:
> > Also, if
> > possible, could both patches have the same prefix? (x86/clang)
>
> I did notice the prefix difference before sending the series.
> I wouldn't mind making both just x86:
On 11/15/19 3:10 PM, Jürgen Groß wrote:
> On 15.11.19 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 system environment variable to turn this
>>> feature / bugfix / hack on and off - this would
On 31/10/2019 21:25, Julien Grall wrote:
> Hi,
>
> On 31/10/2019 19:28, Andrew Cooper wrote:
>> This code is especially tangled. VCPUOP_initialise calls into
>> arch_initialise_vcpu() which calls back into default_initialise_vcpu() which
>> is common code.
>>
>> This path is actually dead code on
On 02.10.2019 19:16, Hongyan Xia wrote:
> From: Wei Liu
>
> They were put into page.h but mm.h is more appropriate.
>
> The real reason is that I will be adding some new functions which
> takes mfn_t. It turns out it is a bit difficult to do in page.h.
>
> No functional change.
>
>
On 15.11.19 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 system environment variable to turn this
feature / bugfix / hack on and off - this would probably break starting
the VM via the xendomains script.
If
FTR, please avoid top-posting. :-)
On 11/15/19 2:31 PM, Steven Haigh wrote:
> Just regarding the use of a system environment variable to turn this
> feature / bugfix / hack on and off - this would probably break starting
> the VM via the xendomains script.
>
> If the VM definition is in
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 together with the
>> question of whether instead leaving it alone, cmp_legacy then
>> would have
On 15.11.2019 15:45, Roger Pau Monné wrote:
> On Fri, Nov 15, 2019 at 11:43:21AM +0100, Jan Beulich wrote:
>> 1: fix clang .macro retention check
>> 2: clang: move and fix .skip check
>
> For both:
>
> Tested-by: Roger Pau Monné
> [On FreeBSD and Debian 9.5]
Thanks much. I'll take the liberty
On 11/15/19 2:42 PM, Jan Beulich wrote:
> On 15.11.2019 15:29, George Dunlap wrote:
>> On 11/15/19 2:18 PM, Jan Beulich wrote:
>>> On 15.11.2019 15:10, George Dunlap wrote:
On 11/15/19 2:06 PM, Andrew Cooper wrote:
> On 15/11/2019 14:04, George Dunlap wrote:
It's not entirely
On 15/11/2019 14:45, Roger Pau Monné wrote:
> On Fri, Nov 15, 2019 at 11:43:21AM +0100, Jan Beulich wrote:
>> 1: fix clang .macro retention check
>> 2: clang: move and fix .skip check
> For both:
>
> Tested-by: Roger Pau Monné
> [On FreeBSD and Debian 9.5]
> Reviewed-by: Roger Pau Monné
>
> Note
On Fri, Nov 15, 2019 at 11:43:21AM +0100, Jan Beulich wrote:
> 1: fix clang .macro retention check
> 2: clang: move and fix .skip check
For both:
Tested-by: Roger Pau Monné
[On FreeBSD and Debian 9.5]
Reviewed-by: Roger Pau Monné
Note there's a typo in this email's subject (clank v clang).
On 15.11.2019 15:27, Wei Liu wrote:
> Fix text about release cycle. Drop the conjured up example that's no
> longer applicable.
>
> Signed-off-by: Wei Liu
FWIW
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 15.11.19 15:27, Wei Liu wrote:
Fix text about release cycle. Drop the conjured up example that's no
longer applicable.
Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
On 15.11.2019 15:29, George Dunlap wrote:
> On 11/15/19 2:18 PM, Jan Beulich wrote:
>> On 15.11.2019 15:10, George Dunlap wrote:
>>> On 11/15/19 2:06 PM, Andrew Cooper wrote:
On 15/11/2019 14:04, George Dunlap wrote:
>>> It's not entirely uncommon to (also) consider how the resulting
> Actually this has already been submitted and Release-acked here:
>
> https://patchew.org/Xen/20191023162358.7222-1-george.dun...@citrix.com/
Ah thanks, I remember seeing that now but I confused it with the
*very* similar patch for libxl_domain_pause/unpause.
-NR
Hi Julian and Jenish
I have queued this patch to my for-next branch based on Paul and Tim's
review.
Note that Xen is currently frozen. This patch will get committed once
the tree is open for new features.
Wei.
___
Xen-devel mailing list
Just regarding the use of a system environment variable to turn this
feature / bugfix / hack on and off - this would probably break starting
the VM via the xendomains script.
If the VM definition is in /etc/xen/auto/, then there would be nothing
to set the environment variable before the VM
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; adjust BUG_IF_WRONG_CR3
> as well just in case.
>
> Fixes:
On 11/15/19 2:18 PM, Jan Beulich wrote:
> On 15.11.2019 15:10, George Dunlap wrote:
>> On 11/15/19 2:06 PM, Andrew Cooper wrote:
>>> On 15/11/2019 14:04, George Dunlap wrote:
>> It's not entirely uncommon to (also) consider how the resulting
>> diff would look like when putting together a
Fix text about release cycle. Drop the conjured up example that's no
longer applicable.
Signed-off-by: Wei Liu
---
docs/process/xen-release-management.pandoc | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/docs/process/xen-release-management.pandoc
1 - 100 of 166 matches
Mail list logo
