On 24/08/18 20:43, Jason Andryuk wrote:
> On Wed, Aug 15, 2018 at 10:39 AM Juergen Gross wrote:
>>
>> On 15/08/18 16:10, Jan Beulich wrote:
>> On 15.08.18 at 15:17, wrote:
2) 32bit PV guests which use writeable pagetable support will
automatically get shadowed when the clear the
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-intel
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
flight 126545 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126545/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 16973234fc60a95daf7be32ee89123914fdab3f0
baseline version:
ovmf
flight 126473 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126473/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
examine-baroque1 2 hosts-allocate broken REGR. vs. 125522
flight 126472 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 126042
When a vcpu that was offline, comes back online, we do want it to either
be assigned to a pCPU, or go into the wait list.
So let's do exactly that. Detecting that a vcpu is coming back online is
a bit tricky. Basically, if the vcpu is waking up, and is neither
assigned to a pCPU, nor in the wait
It is all the time that we call vcpu_deassing() that the vcpu _must_ be
assigned to a pCPU, and hence that such pCPU can't be free.
Therefore, move the ASSERT-s which check for these properties in that
function, where they belong better.
---
Cc: George Dunlap
---
xen/common/sched_null.c |5
If a pCPU has been/is being offlined, we don't want it to be neither
assigned to any pCPU, nor in the wait list.
Therefore, when we detect that a vcpu is going offline, remove it from
both places.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Stefano Stabellini
Cc: Roger Pau Monne
xen: sched: support vcpu hotplug/hotunplug in the 'null scheduler'
Hello,
It turned out, while discussing this patch:
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00249.html
that the 'null scheduler' does not really support vcpu
hotplug/hotunplug. In fact, under some
If a pCPU has been/is being offlined, we don't want it to be neither
assigned to any pCPU, nor in the wait list.
So, avoid doing that while inserting or migrating vcpus.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Stefano Stabellini
Cc: Roger Pau Monne
---
vcpu_deassign() has only one caller: _vcpu_remove().
Let's consolidate the two functions into one.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_null.c | 76 ++-
1 file changed, 35
On Thu, 2018-01-18 at 10:10 -0500, Paul Durrant wrote:
> Lastly the previous code did not properly emulate an EOI if a missed EOI
> was discovered in vlapic_has_pending_irq(); it merely cleared the bit in
> the ISR. The new code instead calls vlapic_EOI_set().
Hm, this *halves* my observed
If sched_smt_cosched is enabled, when tickling pcpus (upon vcpu
wakeups), take into account the fact that only pcpus of cores where
other vcpus of the same domain are running already, or fully idle ones,
will actually be able to pick the vcpu up.
*NB* there are places where the behavior needs a
If sched_smt_cosched is enabled, take it into account when choosing on
what pcpu to run a vcpu (e.g., for doing a migration).
Basically, we can only run vcpus of domain A on pcpus of cores where
other vcpus of domain A are running already (and, vice versa, we
absolutely don't want to run a vcpu
Introduce some new event, related to SMT-aware domain co-scheduling,
in Credit1 code, and their handling and parsing in xenalyze.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Ian Jackson
Cc: Wei Liu
---
TODO:
- deal with xentrace_format.
---
tools/xentrace/xenalyze.c | 74
If SMT domain co-scheduling is enabled, we only migrate a vcpu to either
a fully idle core, or to pcpus of cores where other vcpus of the same
domain are running already.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_credit.c | 17 ++---
1 file changed,
When a vcpu which is exclusively pinned to a pcpu wakes up, we only have
one option: tickling that exact pcpu.
If sched_smt_cosched is enabled, however, it only makes sense to do that
if pcpu is in a core where vcpus of the domain are running already.
Signed-off-by: Dario Faggioli
---
Cc:
In fact, we want to be able to enforce that only vcpus belonging to the
same domain are executed on pcpus that are part of one core (i.e., that
are 'siblings hyperthread', or just 'hyperthreads').
To achieve that, we introduce a new new data structure, representing a
physical core, and use it to
Now that we have the information about which cores are fully idle, use
it for tickling pcpus.
This way, if there are cores that are fully idle, we tickle a pcpu from
one of them. This improve the SMT-awareness of the scheduler,
guaranteeing a better distribution of load, right from vcpu wakeup.
As in Credit2, We add a per-scheduler cpumask in which, the bits od
the CPUs of a core are set if and only if all the threads of the core
are idle.
If even just one thread is not idle (or has just been tickled and hence
is about to pick up work), all the bits are zero.
Note that this new mask
If sched_smt_cosched is enabled, after having selected the next vcpu to
run on a pcpu, we check whether either:
- the whole core is fully idle,
- or the chosen vcpu is from the same domain than the other vcpus
running on pcpus of the core.
If that is not the case, and the core is not idle, we
If sched_smt_cosched is enabled, when poking at other pcpus' runqueues
(for doing load balancing), we only consider the vcpus of the domain
that is running on the core already. Unless the core is fully idle, in
which case, we can pick up any vcpu.
Signed-off-by: Dario Faggioli
---
Cc: George
Hello,
As anticipated here:
https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02052.html
Here's a preliminary version of my work, trying to implement
core-scheduling in Xen.
First of all, this deals with Credit1 only. I have patches for Credit2,
and I've been working on having
For scalability reasons, we keep track of the number of runnable vcpu
in each runqueue (there is one runq for each pcpu). This, right now,
includes running both runnable and running ones.
Change the mechanism so that we count runnable only runnable ones,
which is more useful. In fact, we want to
Currently, if a pcpu is idle and has some runnable vcpus in its
runqueue, the other pcpus (e.g., when they're going idle) never try to
steal any of such runnable vcpus.
This is because Credit1 assumes that, when a vcpu wakes up, if the pcpu
on which it is queued is idle, that very pcpu is
If a vcpu wakes up on an idle pcpu, we always (try to) run it there.
This may seem ok but it may actually be not, in case there is another
(also idle) pcpu which would be better suited (for load balancing and/or
affinity reasons, for instance) to run it.
So, instead than blindly tickle the pcpu
Basically, for dealing earlier with the case when there are some idle
pcpus that are suitable for running the newly waking vcpu (and bailing
out if not).
This is pure code refactoring, with the purpose of separating code
movement and functional changes (coming in follow-up commits).
Introduced in 9bb9c73884d "xen: credit2: implement true
SMT support", it was available only to Credit2.
Move the functions to common headers so that also other
schedulers can use them, to track the idleness of full
cores.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc:
This is pure code refactoring, with the purpose of isolating code
movement. No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_credit.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-multivcpu
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
On 08/24/2018 04:48 AM, Wei Liu wrote:
On Fri, Aug 24, 2018 at 10:25:49AM +, osstest service owner wrote:
flight 126429 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On Tue, Aug 21, 2018 at 02:27:40AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > @@ -423,6 +426,10 @@ const struct x86_emulate_ops *shadow_init_emulation(
> > ? sizeof(sh_ctxt->insn_buf) : 0;
> >
> > return _shadow_emulator_ops;
> > +#else
> > +BUG();
> > +
On Tue, Aug 21, 2018 at 10:29:21AM +0200, Roger Pau Monné wrote:
> On Fri, Aug 17, 2018 at 04:12:43PM +0100, Wei Liu wrote:
> > Enclose HVM only emulation code under CONFIG_HVM. Add some BUG()s to
> > to catch any issue.
> >
> > Note that although some code checks is_hvm_*, which hints it can be
flight 126535 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126535/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-amd64-xen-freebsd 7 xen-build-freebsdfail never pass
version targeted for testing:
On Tue, Aug 21, 2018 at 02:41:06AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > --- a/xen/arch/x86/mm/shadow/multi.c
> > +++ b/xen/arch/x86/mm/shadow/multi.c
> > @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
> > }
> > else
> >
On Fri, 24 Aug 2018, Julien Grall wrote:
> On 24/08/18 00:33, Stefano Stabellini wrote:
> > Hi all,
>
> Hi,
>
> >
> > This patch series introduces one kconfig option for each remaing
> > platform under platforms/. Each kconfig option enables the required
> > drivers in Xen.
> >
> > Cheers,
>
On Fri, 24 Aug 2018, Julien Grall wrote:
> Hi,
>
> On 24/08/18 00:33, Stefano Stabellini wrote:
> > Add a Kconfig option to select no specific platform support.
>
> That's not entirely true. After this series applied, there are still some
> obj-y present in the Makefile.
Sorry I must have been
On Fri, 24 Aug 2018, Julien Grall wrote:
> Hi,
>
> On 24/08/18 00:33, Stefano Stabellini wrote:
> > Add a kconfig option for Renesas Rcar2 platforms.
> >
> > Signed-off-by: Stefano Stabellini
> > Reviewed-by: Andrii Anisov
> > CC: iurii.konovale...@globallogic.com
> > ---
> >
flight 126466 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126466/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
This run is configured for baseline tests only.
flight 75116 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75116/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 11 guest-start
On 8/24/18 8:49 PM, Andrew Cooper wrote:
> On 24/08/18 15:11, Alexandru Isaila wrote:
>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>> index 03a864156..b01194d 100644
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -212,7 +212,20 @@
On Wed, Aug 15, 2018 at 10:39 AM Juergen Gross wrote:
>
> On 15/08/18 16:10, Jan Beulich wrote:
> On 15.08.18 at 15:17, wrote:
> >> 2) 32bit PV guests which use writeable pagetable support will
> >> automatically get shadowed when the clear the lower half.
> >
> > ... of a page table entry.
On 24/08/18 15:11, Alexandru Isaila wrote:
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index 03a864156..b01194d 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -212,7 +212,20 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned
flight 126443 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126443/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail
REGR. vs. 126266
On Fri, Aug 24, 2018 at 06:40:03PM +0200, Michal Hocko wrote:
> On Fri 24-08-18 11:12:40, Jerome Glisse wrote:
> [...]
> > I am fine with Michal patch, i already said so couple month ago first time
> > this discussion did pop up, Michal you can add:
> >
> > Reviewed-by: Jérôme Glisse
>
> So I
Hello,
The current QEMU build in -unstable is broken on FreeBSD due to some
pvrdma issues. Those issues have already been fixed upstream by
commits:
72221d03b85fcfba27a47a2af08ee59150550ced
21ab34c9543fe1b6d31b3edbd01a397e7e090d00
I see that those commits are already in the upstream-tested
On Tue, Aug 21, 2018 at 02:07:22AM -0600, Jan Beulich wrote:
> #ifdef (also elsewhere; did I overlook similar issues in earlier patches?)
>
> > --- a/xen/common/vm_event.c
> > +++ b/xen/common/vm_event.c
> > @@ -429,9 +429,11 @@ void vm_event_resume(struct domain *d, struct
> > vm_event_domain
Some capababilities are set right during boot and will never change
afterwards. At the moment, the function cpu_have_caps will check whether
the cap is enabled from the memory.
It is possible to avoid the load from the memory by using an
ALTERNATIVE. With that the check is just reduced to 1
call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
do SMCCC call, replace all call to the former by the later.
Signed-off-by: Julien Grall
---
xen/arch/arm/Makefile| 1 -
xen/arch/arm/platforms/exynos5.c | 3 ++-
xen/arch/arm/platforms/seattle.c | 4 ++--
From: Volodymyr Babchuk
Existing SMC wrapper call_smc() allows only 4 parameters and
returns only one value. This is enough for existing
use in PSCI code, but TEE mediator will need a call that is
fully compatible with ARM SMCCC v1.0.
This patch adds a wrapper for both arm32 and arm64. In the
Signed-off-by: Julien Grall
---
xen/arch/arm/psci.c | 4
xen/include/asm-arm/cpufeature.h | 3 ++-
xen/include/asm-arm/smccc.h | 8
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index
From: Marc Zyngier
If someone has the silly idea to write something along those lines:
extern u64 foo(void);
void bar(struct arm_smccc_res *res)
{
arm_smccc_1_1_smc(0xbad, foo(), res);
}
they are in for a surprise, as this gets compiled as:
Hi all,
This patch series contains fixup and improvement for the SMCCC subsystem.
Patch #1 - #2 are candidates for backporting.
Cheers,
Julien Grall (3):
xen/arm: cpufeature: Add helper to check constant caps
xen/arm: smccc: Add wrapper to automatically select the calling
convention
flight 126440 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126440/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125183
test-amd64-amd64-xl
On Fri, Aug 24, 2018 at 06:22:32PM +0200, Valentin Vidic wrote:
> Managed to reproduce this and xen_blkif_disconnect is always returning 0
> like you expected. So this is some other issue, and from what I can tell
> blkdev_put of the underlying drbd device gets called some time after
>
On Fri 24-08-18 11:12:40, Jerome Glisse wrote:
[...]
> I am fine with Michal patch, i already said so couple month ago first time
> this discussion did pop up, Michal you can add:
>
> Reviewed-by: Jérôme Glisse
So I guess the below is the patch you were talking about?
From
On Tue, Aug 21, 2018 at 10:37:24AM +0200, Roger Pau Monné wrote:
> On Fri, Aug 17, 2018 at 04:12:45PM +0100, Wei Liu wrote:
> > They reference hvm_inject_event which is HVM code (not compiled). They
> > aren't used by code outside HVM code anyway.
>
> Can you put all the functions inside of an
On Sun, Aug 19, 2018 at 07:27:22PM +0300, Razvan Cojocaru wrote:
> On 8/17/18 6:12 PM, Wei Liu wrote:
> > Going through the code, nested EPT, EPT, and ALTP2M depend on HVM code. Put
> > these components under CONFIG_HVM. This further requires putting one
> > of the vm event under CONFIG_HVM.
> >
On Mon, Aug 20, 2018 at 07:04:09AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > This helps to take advantage of dead code elimination. Turn
> > hvm_enabled into proper bool while at it.
> >
> > Providing an empty hvm_funcs resolves a lot of undefined references to
> > it in
On Wed, Aug 22, 2018 at 06:23:01PM +0200, Valentin Vidic wrote:
> On Wed, Aug 22, 2018 at 05:51:54PM +0200, Roger Pau Monné wrote:
> > Can you add some debug prints to check if xen_blkif_disconnect is
> > indeed returning EBUSY (or some error) and that's preventing the
> > device from closing
This run is configured for baseline tests only.
flight 75114 seabios real [real]
http://osstest.xensource.com/osstest/logs/75114/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win10-i386 10 windows-installfail
On Fri, Aug 24, 2018 at 10:32:24AM -0500, Doug Goldstein wrote:
> On Fri, Aug 24, 2018 at 04:22:47PM +0100, Wei Liu wrote:
> > Previously it is disabled because the embedded ipxe can't be built
> > with clang. Now that ipxe is split out we can use --with-system-ipxe
> > to work around the issue.
>
On Fri, Aug 24, 2018 at 04:32:15PM +0100, Wei Liu wrote:
> On Fri, Aug 24, 2018 at 10:30:37AM -0500, Doug Goldstein wrote:
> > On Fri, Aug 24, 2018 at 04:22:15PM +0100, Wei Liu wrote:
> > > Building rombios with clang XXX fails with:
>
> Oops, I have meant to replace XXX with the right version
On Fri, Aug 24, 2018 at 10:30:37AM -0500, Doug Goldstein wrote:
> On Fri, Aug 24, 2018 at 04:22:15PM +0100, Wei Liu wrote:
> > Building rombios with clang XXX fails with:
Oops, I have meant to replace XXX with the right version number.
Will fix that while committing.
> >
> > tcgbios.c:1519:34:
On Fri, Aug 24, 2018 at 04:22:47PM +0100, Wei Liu wrote:
> Previously it is disabled because the embedded ipxe can't be built
> with clang. Now that ipxe is split out we can use --with-system-ipxe
> to work around the issue.
>
> Signed-off-by: Wei Liu
> ---
> +# iPXE cannot be built with
On Fri, Aug 24, 2018 at 04:22:15PM +0100, Wei Liu wrote:
> Building rombios with clang XXX fails with:
>
> tcgbios.c:1519:34: error: taking address of packed member 'u' of class or
> structure 'pushad_regs_t' may result in an unaligned pointer value
> [-Werror,-Waddress-of-packed-member]
>
Previously it is disabled because the embedded ipxe can't be built
with clang. Now that ipxe is split out we can use --with-system-ipxe
to work around the issue.
Signed-off-by: Wei Liu
---
automation/scripts/build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Building rombios with clang XXX fails with:
tcgbios.c:1519:34: error: taking address of packed member 'u' of class or
structure 'pushad_regs_t' may result in an unaligned pointer value
[-Werror,-Waddress-of-packed-member]
®s->u.r32.edx);
Paul Durrant writes ("[PATCH] xenforeignmemory: work around bug in older
privcmd"):
> Versions of linux privcmd prior to commit dc9eab6fd94d ("return -ENOTTY
> for unimplemented IOCTLs") will return -EINVAL rather than the conventional
> -ENOTTY for unimplemented codes. This breaks the error path
Wei Liu writes ("[PATCH] tools: building IPXE should be determined by
CONFIG_IPXE"):
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Wei Liu writes ("Re: [Xen-devel] Backport request -
3a2b8525b883baa87fe89b3da58f5c09fa599b99 to staging-4.9"):
> On Fri, Aug 24, 2018 at 12:32:57PM +1000, Steven Haigh wrote:
> > Commit:
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=3a2b8525b883baa87fe89b3da58f5c09fa599b99
> >
> > I've
On Fri, Aug 24, 2018 at 11:52:25PM +0900, Tetsuo Handa wrote:
> On 2018/08/24 22:32, Michal Hocko wrote:
> > On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
> >> I worry that (currently
> >> out-of-tree) users of this API are involving work / recursion.
> >
> > I do not give a slightest about
On Fri, Aug 24, 2018 at 02:33:41PM +0200, Michal Hocko wrote:
> On Fri 24-08-18 14:18:44, Christian König wrote:
> > Am 24.08.2018 um 14:03 schrieb Michal Hocko:
> > > On Fri 24-08-18 13:57:52, Christian König wrote:
> > > > Am 24.08.2018 um 13:52 schrieb Michal Hocko:
> > > > > On Fri 24-08-18
On 2018/08/24 22:32, Michal Hocko wrote:
> On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
>> I worry that (currently
>> out-of-tree) users of this API are involving work / recursion.
>
> I do not give a slightest about out-of-tree modules. They will have to
> accomodate to the new API. I have no
This run is configured for baseline tests only.
flight 75113 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75113/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75111
On Fri, Aug 24, 2018 at 03:52:55PM +0200, Juergen Gross wrote:
> Ping?
Looking good; although I messed it up a little bit by adding a new
paravirt function.
Thanks for doing this!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
flight 126412 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898
On Fri, Aug 24, 2018 at 07:54:19PM +0900, Tetsuo Handa wrote:
> Two more worries for this patch.
[...]
>
> > --- a/mm/hmm.c
> > +++ b/mm/hmm.c
> > @@ -177,16 +177,19 @@ static void hmm_release(struct mmu_notifier *mn,
> > struct mm_struct *mm)
> > up_write(>mirrors_sem);
> > }
> >
>
On 08/24/2018 07:26 AM, Juergen Gross wrote:
> On 24/08/18 13:12, Jiri Slaby wrote:
>> On 07/30/2018, 10:18 AM, Xiao Liang wrote:
>>> On 07/29/2018 11:30 PM, David Miller wrote:
From: Xiao Liang
Date: Fri, 27 Jul 2018 17:56:08 +0800
> @@ -1330,6 +1331,11 @@ static struct
On 24/08/18 16:12, Peter Zijlstra wrote:
> On Mon, Aug 13, 2018 at 09:37:38AM +0200, Juergen Gross wrote:
>> struct pv_mmu_ops {
>> +/* TLB operations */
>> +void (*flush_tlb_user)(void);
>> +void (*flush_tlb_kernel)(void);
>> +void (*flush_tlb_one_user)(unsigned long addr);
>> +
On 24/08/18 16:10, Peter Zijlstra wrote:
> On Mon, Aug 13, 2018 at 09:37:37AM +0200, Juergen Gross wrote:
>> Some of the paravirt ops defined in pv_irq_ops are for Xen PV guests
>> only. Define them only if CONFIG_PARAVIRT_XXL is set.
>> diff --git a/arch/x86/include/asm/paravirt_types.h
>>
On Mon, Aug 13, 2018 at 09:37:38AM +0200, Juergen Gross wrote:
> struct pv_mmu_ops {
> + /* TLB operations */
> + void (*flush_tlb_user)(void);
> + void (*flush_tlb_kernel)(void);
> + void (*flush_tlb_one_user)(unsigned long addr);
> + void (*flush_tlb_others)(const struct
The original version of the patch emulated the current instruction
(which, as a side-effect, emulated the page-walk as well), however we
need finer-grained control. We want to emulate the page-walk, but still
get an EPT violation event if the current instruction would trigger one.
This patch
On Mon, Aug 13, 2018 at 09:37:37AM +0200, Juergen Gross wrote:
> Some of the paravirt ops defined in pv_irq_ops are for Xen PV guests
> only. Define them only if CONFIG_PARAVIRT_XXL is set.
> diff --git a/arch/x86/include/asm/paravirt_types.h
> b/arch/x86/include/asm/paravirt_types.h
> index
Hi
On Fri, Aug 24, 2018 at 9:37 AM Markus Armbruster wrote:
>
> Marc-André Lureau writes:
>
> > This is mostly for readability of the code. Let's make it clear which
> > callers can create an implicit monitor when the chardev is muxed.
> >
> > This will also enforce a safer behaviour, as we
On Mon, 13 Aug 2018, Juergen Gross wrote:
> There is no need any longer to store the clobbers in struct
> paravirt_patch_site. Remove clobbers from the struct and from the
> related macros.
>
> While at it fix some lines longer than 80 characters.
>
> Signed-off-by: Juergen Gross
Reviewed-by:
On Mon, 13 Aug 2018, Juergen Gross wrote:
> The clobbers parameter from paravirt_patch_default() et al isn't used
> any longer. Remove it.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
___
Xen-devel mailing list
On Mon, 13 Aug 2018, Juergen Gross wrote:
> paravirt_patch_call() and paravirt_patch_jmp() are used in paravirt.c
> only. Convert them to static.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Thomas Gleixner
___
Xen-devel mailing list
On Fri, 24 Aug 2018, Juergen Gross wrote:
> On 08/08/18 17:13, Boris Ostrovsky wrote:
> > x86 maintainers, this needs you ack too even though it has "xen" tag in
> > the subject, thanks.
>
> Ping?
I thought I sent one already, but here you go:
Acked-by: Thomas Gleixner
On Fri, Aug 24, 2018 at 11:54:04AM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 08/08/18 17:13, Boris Ostrovsky wrote:
> x86 maintainers, this needs you ack too even though it has "xen" tag in
> the subject, thanks.
Ping?
Juergen
>
>
> On 08/08/2018 02:19 AM, Juergen Gross wrote:
>> All functions in arch/x86/xen/irq.c and arch/x86/xen/xen-asm*.S are
>> specific to PV
On 13/08/18 09:37, Juergen Gross wrote:
> This series removes some no longer needed stuff from paravirt
> infrastructure and puts large quantities of paravirt ops under a new
> config option PARAVIRT_XXL which is selected by XEN_PV only.
>
> A pvops kernel without XEN_PV being configured is about
On Fri 24-08-18 15:44:03, Christian König wrote:
> Am 24.08.2018 um 15:40 schrieb Michal Hocko:
> > On Fri 24-08-18 15:28:33, Christian König wrote:
> > > Am 24.08.2018 um 15:24 schrieb Michal Hocko:
> > > > On Fri 24-08-18 15:10:08, Christian König wrote:
> > > > > Am 24.08.2018 um 15:01 schrieb
On 17/08/18 17:59, Roger Pau Monné wrote:
> On Mon, Aug 13, 2018 at 04:01:09PM +0200, Juergen Gross wrote:
>> Persistent grants are used in the Xen's blkfront/blkback drivers to
>> avoid mapping/unmapping of I/O buffers in the backend for each I/O.
>>
>> While this speeds up processing quite a bit
Am 24.08.2018 um 15:40 schrieb Michal Hocko:
On Fri 24-08-18 15:28:33, Christian König wrote:
Am 24.08.2018 um 15:24 schrieb Michal Hocko:
On Fri 24-08-18 15:10:08, Christian König wrote:
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am
On Fri 24-08-18 15:28:33, Christian König wrote:
> Am 24.08.2018 um 15:24 schrieb Michal Hocko:
> > On Fri 24-08-18 15:10:08, Christian König wrote:
> > > Am 24.08.2018 um 15:01 schrieb Michal Hocko:
> > > > On Fri 24-08-18 14:52:26, Christian König wrote:
> > > > > Am 24.08.2018 um 14:33 schrieb
On Fri 24-08-18 22:02:23, Tetsuo Handa wrote:
> On 2018/08/24 20:36, Michal Hocko wrote:
> >> That is, this API seems to be currently used by only out-of-tree users.
> >> Since
> >> we can't check that nobody has memory allocation dependency, I think that
> >> hmm_invalidate_range_start() should
Am 24.08.2018 um 15:24 schrieb Michal Hocko:
On Fri 24-08-18 15:10:08, Christian König wrote:
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am 24.08.2018 um 14:33 schrieb Michal Hocko:
[...]
Thiking about it some more, I can imagine that a
On Fri, Aug 24, 2018 at 01:16:26PM +0100, Paul Durrant wrote:
> Versions of linux privcmd prior to commit dc9eab6fd94d ("return -ENOTTY
> for unimplemented IOCTLs") will return -EINVAL rather than the conventional
> -ENOTTY for unimplemented codes. This breaks the error path in
>
On Fri 24-08-18 15:10:08, Christian König wrote:
> Am 24.08.2018 um 15:01 schrieb Michal Hocko:
> > On Fri 24-08-18 14:52:26, Christian König wrote:
> > > Am 24.08.2018 um 14:33 schrieb Michal Hocko:
> > [...]
> > > > Thiking about it some more, I can imagine that a notifier callback which
> > > >
1 - 100 of 151 matches
Mail list logo
