Re: [Xen-devel] [PATCH v2 0/2] Introduce runstate area registration with phys address

Hi. On 5/13/19 4:42 PM, Andrii Anisov wrote: On 13.05.19 18:40, Julien Grall wrote:  From my understanding, if you want consistency, then setting the affinity will definitely help. Otherwise, you may have the scheduler to kick up and also balancing. Sorry, do you mean setting affinity for dd

Re: [Xen-devel] [PATCH v2 0/2] Introduce runstate area registration with phys address

On 13.05.19 18:45, Julien Grall wrote: I was speaking about dd process. But Dom0 vCPUs might also be a good idea. I see. -- Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/li

Re: [Xen-devel] [PATCH 3/5] iommu: move iommu_get_ops() into common code

>>> On 08.05.19 at 15:24, wrote: > Currently x86 and ARM differ in their implementation for no good reason. > This patch moves the ARM variant of iommu_get/set_ops() helpers into > common code and modifies them so they deal with the __initconstrel > ops structures used by the x86 IOMMU vendor impl

Re: [Xen-devel] Anyone using blktap2?

Am Mon, 13 May 2019 16:34:14 +0100 schrieb Wei Liu : > Seeing that you were the last people who changed blktap2 in a meaningful > way: do you use it at all? The default for --enable-blktap2 in tools/configure.ac is off, and nothing seems to pass --enable-blktap2 to configure. So I'm ok to remove

Re: [Xen-devel] [PATCH v2 1/3] x86/mm: short-circuit HVM-only mode flags when !HVM

On 5/9/19 2:42 PM, Jan Beulich wrote: > #define-ing them to zero allows better code generation in this case, > and paves the way for more DCE, allowing to leave certain functions just > declared, but not defined. > > Signed-off-by: Jan Beulich Reviewed-by: George Dunlap ___

Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

Le vendredi, mai 10, 2019 5:21 PM, Andrew Cooper a écrit : > On 10/05/2019 16:17, Mathieu Tarral wrote: > > > Le jeudi, mai 9, 2019 6:42 PM, Andrew Cooper andrew.coop...@citrix.com a > > écrit : > > > > > Therefore, the conclusion to draw is that it is a logical bug somewhere. > > The bug is st

Re: [Xen-devel] [PATCH v2 2/3] x86/mm: make guest_physmap_add_entry() HVM-only

On 5/9/19 2:44 PM, Jan Beulich wrote: > Lift its !paging_mode_translate() part into guest_physmap_add_page() > (which is what common code calls), eliminating the dummy use of a > (HVM-only really) P2M type in the PV case. > > Suggested-by: George Dunlap > Signed-off-by: Jan Beulich Thanks, look

Re: [Xen-devel] [PATCH v2 3/3] x86/mm: subsume set_gpfn_from_mfn() into guest_physmap_add_page()

On 5/9/19 2:45 PM, Jan Beulich wrote: > The two callers in common/memory.c currently call set_gpfn_from_mfn() > themselves, so moving the call into guest_physmap_add_page() helps > tidy their code. > > The two callers in common/grant_table.c fail to make that call alongside > the one to guest_phys

Re: [Xen-devel] [PATCH v2] docs/xl: Clarify documentation for mem-max and mem-set

On 13/05/2019, 08:28, "Wei Liu" wrote: On Mon, May 13, 2019 at 02:59:30PM +0100, Wei Liu wrote: > On Wed, May 01, 2019 at 03:59:41PM +0100, George Dunlap wrote: > > On 4/8/19 12:09 PM, George Dunlap wrote: > > > mem-set is the primary command that users will need to use and

Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

On 5/13/19 7:18 PM, Mathieu Tarral wrote: > Le vendredi, mai 10, 2019 5:21 PM, Andrew Cooper > a écrit : > >> On 10/05/2019 16:17, Mathieu Tarral wrote: >> >>> Le jeudi, mai 9, 2019 6:42 PM, Andrew Cooper andrew.coop...@citrix.com a >>> écrit : >>> Therefore, the conclusion to draw is that

[Xen-devel] [ovmf test] 136056: all pass - PUSHED

flight 136056 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/136056/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f684c3f5eef4be691e137ae64e7d00521ec201de baseline version: ovmf cd5147734cbe82f0c1665

[Xen-devel] [qemu-upstream-4.10-testing test] 136051: FAIL

flight 136051 qemu-upstream-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/136051/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken in 134

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

flight 136179 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/136179/ 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

Re: [Xen-devel] Anyone using blktap2?

On Mon, May 13, 2019 at 04:34:14PM +0100, Wei Liu wrote: > Hello > > Seeing that you were the last people who changed blktap2 in a meaningful > way: do you use it at all? > > I'm thinking about dropping it (again). Fine with me too. -- Best Regards, Marek Marczykowski-Górecki Invisible Things

[Xen-devel] [qemu-upstream-4.11-testing test] 136057: regressions - FAIL

flight 136057 qemu-upstream-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/136057/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken in 134594 build-arm64

Re: [Xen-devel] Criteria / validation proposal: drop Xen

Hi all, I am going to step in here with my hat as Xen Project community manager. We had a discussion about this issue as part of last week's community call. I CC'ed a number of stake-holders, which probably should have been on the thread such as ITL (which builds QubesOS on top of Fedora) and Mich

<    1   2