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]
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
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
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
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
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
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 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
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 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
> 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
___
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.
>
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
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
> -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
On 21.10.2019 17:57, Wei Liu wrote:
> --- a/xen/arch/x86/guest/xen/xen.c
> +++ b/xen/arch/x86/guest/xen/xen.c
> @@ -97,7 +97,7 @@ static void map_shared_info(void)
> unsigned int i;
> unsigned long rc;
>
> -if ( hypervisor_alloc_unused_page() )
> +if ( xen_alloc_unused_page() )
On 08/11/2019 07:06, Jürgen Groß wrote:
> On 30.10.19 19:06, Anthony PERARD wrote:
>> Patch series available in this git branch:
>> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
>> br.fix-ev_qmp-multi-connect-v2
>>
>> Hi,
>>
>> QEMU's QMP socket doesn't allow multiple
On 21.10.2019 17:57, Wei Liu wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -164,6 +164,15 @@ endchoice
> config GUEST
> bool
>
> +config HYPERV_GUEST
> + def_bool n
> + select GUEST
> + prompt "Hyper-V Guest"
Please can you avoid following the bad
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 flush any pending PIRR vectors on the
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 change. And besides
>>> the review aspect, there's also the archeology one - "git blame"
>>> yields much more helpful results when code
On 11/15/19 2:04 PM, George Dunlap wrote:
> On 11/15/19 1:55 PM, Andrew Cooper wrote:
>> On 15/11/2019 12:39, Jan Beulich wrote:
>>> On 15.11.2019 12:58, George Dunlap wrote:
On 11/15/19 11:12 AM, Jan Beulich wrote:
> On 15.11.2019 11:57, George Dunlap wrote:
>> ---
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 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 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
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
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
>
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 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
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
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();
> > +
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
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 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 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
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
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 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 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: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 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.
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
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
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
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
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
On 13.11.19 14: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) domain. Put
On Thu, 14 Nov 2019 at 04:57, Julian Tuminaro wrote:
>
> From: Julian Tuminaro and Jenish Rakholiya rakholiyajenish...@gmail.com>
>
> Current implementation of find_os is based on the hard-coded values for
> different Windows version. It uses the value for get the address to
> start looking for
On 11/15/19 1:55 PM, Andrew Cooper wrote:
> On 15/11/2019 12:39, Jan Beulich wrote:
>> On 15.11.2019 12:58, George Dunlap wrote:
>>> On 11/15/19 11:12 AM, Jan Beulich wrote:
On 15.11.2019 11:57, George Dunlap wrote:
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
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.
>
>
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
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
> -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,
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
flight 144150 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144150/
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 13:10, George Dunlap wrote:
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
On 15/11/2019 14: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 change. And besides
> the review aspect,
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
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 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:
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
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
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 15/11/2019 09:37, Jan Beulich wrote:
> 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
On 08/11/2019 07:07, Jürgen Groß wrote:
> On 31.10.19 13:17, Anthony PERARD wrote:
>> 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 the
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 change. And besides
> the review aspect,
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
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 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
flight 144130 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144130/
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 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
On 15.11.2019 13:12, Anthony PERARD wrote:
> 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
On 21.10.2019 17:57, Wei Liu wrote:
> We need ASSERT_UNREACHABLE.
>
> Signed-off-by: Wei Liu
> Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
Albeit perhaps fold into patch 2?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 21.10.2019 17:57, Wei Liu wrote:
> The only user is Xen specific code in PV shim. We can therefore export
> the variable directly.
>
> Signed-off-by: Wei Liu
> Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
with, at this occasion, ...
> --- a/xen/arch/x86/guest/xen/xen.c
> +++
On 21.10.2019 17:57, Wei Liu wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -689,6 +689,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> int i, j, e820_warn = 0, bytes = 0;
> bool acpi_boot_table_init_done = false, relocated = false;
> int ret;
> +
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
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 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
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
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.19 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
On 15.11.2019 12:58, George Dunlap wrote:
> On 11/15/19 11:12 AM, Jan Beulich wrote:
>> On 15.11.2019 11:57, George Dunlap wrote:
>>> --- a/tools/libxc/xc_cpuid_x86.c
>>> +++ b/tools/libxc/xc_cpuid_x86.c
>>> @@ -579,52 +579,68 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
>>> domid,
On Fri, Nov 15, 2019 at 01:23:46PM +0100, Jan Beulich wrote:
> On 15.11.2019 13:12, Anthony PERARD wrote:
> > 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
>
On 21.10.2019 17:57, Wei Liu wrote:
> Xen is able to run as a guest on Xen. We plan to make it able to run
> on Hyper-V as well.
>
> Introduce CONFIG_GUEST which is set to true if either running on Xen
> or Hyper-V is desired. Restructure code hierarchy for new code to
> come.
>
> No functional
On 21.10.2019 17:57, Wei Liu wrote:
> @@ -31,9 +31,39 @@ bool hypervisor_probe(void)
> if ( hops )
> return true;
>
> +/* Too early to use cpu_has_hypervisor */
> +if ( !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) )
> +return false;
> +
> +#ifdef
On 15/11/2019 12:39, Jan Beulich wrote:
> On 15.11.2019 12:58, George Dunlap wrote:
>> On 11/15/19 11:12 AM, Jan Beulich wrote:
>>> On 15.11.2019 11:57, George Dunlap wrote:
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -579,52 +579,68 @@ int
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
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 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
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
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
On Fri, Nov 15, 2019 at 02:56:48PM +0100, Jürgen Groß wrote:
> > >
> > > Juergen
> >
> > Hi Juergen,
> >
> > Since a lot more recent patches have been committed, but these don't seem
> > to.
> > I was wondering if these fell through the cracks.
>
> Hi Sander,
>
> I'm no committer, "just" the
On 15/11/2019 12:44, Andreas Kinzler wrote:
> On 15.11.2019 13:10, George Dunlap wrote:
>> 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
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
1 - 100 of 166 matches
Mail list logo
