>
>
> Much better. Just one final question. Do you intend this function to
> block until data becomes available? (because that appears to be how it
> behaves.)
>
>
Yes. I could split it up into two functions if that bothers you. Or do you
just want me to include that in the comment?
> Hi
>
> I am trying understand Xen Pv drivers and i writing my own pv fronend and
> backend driver.
>
> 1. For driver internal communication how do i create/write node in backend
> driver and how to read in fronted drivers.
> 2.how do i create one shared page in backend driver to write/read data i
On 07/21/2017 03:12 PM, shishir tiwari wrote:
>
> > Hi
> >
> > I am trying understand Xen Pv drivers and i writing my own pv fronend
> and
> > backend driver.
> >
> > 1. For driver internal communication how do i create/write node in
> backend
> > driver and how to
On 04/07/17 20:34, Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variables last_frontswap_pages and
> tgt_frontswap_pages. Such variables are initialized before being used,
> on every execution path throughout the function. The statics have no
> benefit and, removing them reduce t
CC Ian Jackson
I don't know which version of Xen you're using. Can you check if it
contains the following commit?
commit fa13f7b0c0f3d01741e35d573009503c3bf7b6a6
Author: Andrew Cooper
AuthorDate: Mon Aug 18 14:02:37 2014 +0100
Commit: Ian Campbell
CommitDate: Wed Aug 27 02:30:25 2014 +0
On Fri, Jul 21, 2017 at 12:42:04PM +0530, shishir tiwari wrote:
> > Hi
> >
> > I am trying understand Xen Pv drivers and i writing my own pv fronend and
> > backend driver.
> >
> > 1. For driver internal communication how do i create/write node in backend
> > driver and how to read in fronted drive
CC Juergen and George
On Thu, Jul 20, 2017 at 01:05:20PM +0530, Ajmal M Ali wrote:
> Hi,
>
> I am trying to do USB passthrough in x86_64. I have Ubuntu as Dom0 and DomU.
>
>
>
> *Dom0 : Linux teltvm0881 4.8.0-58-generic #63~16.04.1-Ubuntu SMP Mon Jun 26
> 18:08:51 UTC 2017 x86_64 x86_64 x86_64
On 21/07/17 10:28, Wei Liu wrote:
> CC Juergen and George
>
> On Thu, Jul 20, 2017 at 01:05:20PM +0530, Ajmal M Ali wrote:
>> Hi,
>>
>> I am trying to do USB passthrough in x86_64. I have Ubuntu as Dom0 and DomU.
>>
>>
>>
>> *Dom0 : Linux teltvm0881 4.8.0-58-generic #63~16.04.1-Ubuntu SMP Mon Jun
On Fri, Jul 21, 2017 at 10:39:36AM +0200, Juergen Gross wrote:
> >
> > USB passthrough requires the device model. There is currently no
> > provision in toolstack to spawn a device model on demand.
> >
> > The easiest workaround is to add one device (vfb?) that would require
> > spawning a device
flight 71712 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71712/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64-pvops
Hi,
On Mon, Jul 17, 2017 at 06:32:42PM +0200, Andreas Kinzler wrote:
> Hello Jan, Pasi, all
>
> >>Jan, I still have access to the hardware so perhaps we can finally solve
> >>this problem.
> >Feel free to go ahead; I'll be on vacation for the next three weeks.
>
> Perhaps we can shortcut debuggi
On 7/17/2017 6:08 PM, Huang, Kai wrote:
Hi Andrew,
Thank you very much for comments. Sorry for late reply, and please see
my reply below.
On 7/12/2017 2:13 AM, Andrew Cooper wrote:
On 09/07/17 09:03, Kai Huang wrote:
Hi all,
This series is RFC Xen SGX virtualization support design and RF
On 7/20/2017 2:23 AM, Andrew Cooper wrote:
On 09/07/17 09:09, Kai Huang wrote:
This patch adds early stage SGX feature detection via SGX CPUID 0x12. Function
detect_sgx is added to detect SGX info on each CPU (called from vmx_cpu_up).
SDM says SGX info returned by CPUID is per-thread, and we c
On 7/20/2017 5:27 AM, Andrew Cooper wrote:
On 09/07/17 09:09, Kai Huang wrote:
This patch handles IA32_FEATURE_CONTROL and IA32_SGXLEPUBKEYHASHn MSRs.
For IA32_FEATURE_CONTROL, if SGX is exposed to domain, then SGX_ENABLE bit
is always set. If SGX launch control is also exposed to domain, and
Hi,
On 18/07/17 21:07, Stefano Stabellini wrote:
On Mon, 17 Jul 2017, Bhupinder Thakur wrote:
This patch finally adds the support for vuart console. It adds
two new fields in the console initialization:
- optional
- prefer_gnttab
optional flag tells whether the console is optional.
prefer_gn
Hi,
On 19/07/17 19:47, Stefano Stabellini wrote:
On Wed, 19 Jul 2017, Zhongze Liu wrote:
1. Motivation and Description
Virtual machines use grant table hypercalls to setup a share page for
Dear All,
During the developers summit a Shared Coprocessor Framework (SCF)
concept was presented. One of the topics discussed was a shared
coprocessor configuration.
The SCF itself is intended to share coprocessor (i.e. GPU, DPS, FPGA,
whatever) resources to guest domains [1][2].
We are t
Boris Ostrovsky writes:
> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>> On systems that are not booted as a Xen domain, the xenfs driver prints
>> the following message during boot.
>>
>> [3.460595] xenfs: not registering filesystem on non-xen platform
>>
>> As the user chose not to boot a
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.13-rc2-tag
xen: features and fixes for 4.13-rc2
It contains:
- a new Xen backend driver for passing socket calls from a Xen guest to
Xen dom0
- some Xen related bug fixes and clea
It is 4.4.1 (4.4.1-9+deb8u9 from Debian 8 repository). Looks like
Debian just have too old version in repository. Problem is not
reproduces on 4.6.5.
Best regards,
Victor Kirhenshtein
-Original Message-
From: Wei Liu
To: Victor Kirhenshtein
Cc: xen-devel@lists.xen.org, Wei Liu , Ian Jacks
On 21/07/17 12:12, Punit Agrawal wrote:
> Boris Ostrovsky writes:
>
>> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
>>> On systems that are not booted as a Xen domain, the xenfs driver prints
>>> the following message during boot.
>>>
>>> [3.460595] xenfs: not registering filesystem on non-xe
On Fri, Jul 21, 2017 at 01:18:52PM +0300, Victor Kirhenshtein wrote:
> It is 4.4.1 (4.4.1-9+deb8u9 from Debian 8 repository). Looks like
> Debian just have too old version in repository. Problem is not
> reproduces on 4.6.5.
Right. That commit is included in 4.5, not 4.4.
Just backporting that on
Juergen Gross writes:
> On 21/07/17 12:12, Punit Agrawal wrote:
>> Boris Ostrovsky writes:
>>
>>> On 07/20/2017 07:04 AM, Punit Agrawal wrote:
On systems that are not booted as a Xen domain, the xenfs driver prints
the following message during boot.
[3.460595] xenfs: not
Hi,
On 18/07/17 19:30, Zhongze Liu wrote:
1. Motivation and Description
Virtual machines use grant table hypercalls to setup a share page for
inter-VMs communications. These hypercalls are u
On 20/07/17 17:54, Wei Liu wrote:
On Thu, Jul 20, 2017 at 05:46:50PM +0100, Wei Liu wrote:
CC relevant maintainers
On Thu, Jul 20, 2017 at 05:20:43PM +0200, David Woodhouse wrote:
From: David Woodhouse
This includes stuff lke the hypercall tables which we really want
lke -> like
to be
On an intel skylake machine with upstream qemu, if I add "rdm=strategy=host,
policy=strict" to hvm.cfg, win 8.1 DomU couldn't boot up and continues reboot.
Steps to reproduce this issue:
1) Boot xen with iommu=1 to enable iommu
2) hvm.cfg contain:
builder="hvm"
memory=
disk=[
Hi Julien,
On Thu, Jul 20, 2017 at 4:56 PM, Julien Grall wrote:
>
>
> On 19/07/17 19:39, Julien Grall wrote:
>>>
>>> cell = (const __be32 *)prop->data;
>>> banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
>>>
>>> -for ( i = 0; i < banks && bootinfo.mem.nr_banks < NR_MEM
On 21/07/17 12:10, Vijay Kilari wrote:
Hi Julien,
On Thu, Jul 20, 2017 at 4:56 PM, Julien Grall wrote:
On 19/07/17 19:39, Julien Grall wrote:
cell = (const __be32 *)prop->data;
banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
-for ( i = 0; i < banks && bootinf
On 18/07/17 10:50, Andrii Anisov wrote:
Dear Shishir,
On 18.07.17 12:05, shishir tiwari wrote:
Hi
I want test and understand xen hypervisor implementation with dom0 and
domU on omap5 board.
I followed
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM
wi
Hi Andrii,
Please CC the relevant maintainers when sending a patch (or questions
regarding a specific subsystems) on the ML.
On 18/07/17 17:45, Andrii Anisov wrote:
From: Andrii Anisov
Both Renesas R-Car Gen2(ARM32) and Gen3(ARM64) are utilizing SCIF IP,
so make its serial driver built by d
Hi all,
please find attached my notes. A lot of it went over my head, so I may have
gotten things wrong and some are missing
Feel free to modify, chip in, clarify, as needed
Lars
Session URL: http://sched.co/AjHN
OPTION 1: Userspace Approach
Dom0 Domu
[AFL] [VM ne
Hi,
On Fri, 21 Jul 2017 10:57:55 +
"Zhang, Xiong Y" wrote:
> On an intel skylake machine with upstream qemu, if I add
> "rdm=strategy=host, policy=strict" to hvm.cfg, win 8.1 DomU couldn't boot
> up and continues reboot.
>
> Steps to reproduce this issue:
>
> 1) Boot xen with iommu=1
On Tue, Jul 18, 2017 at 03:22:41PM -0700, Stefano Stabellini wrote:
> From: Igor Druzhinin
...
> +static uint8_t *xen_replace_cache_entry_unlocked(hwaddr old_phys_addr,
> + hwaddr new_phys_addr,
> + h
> On Fri, 21 Jul 2017 10:57:55 +
> "Zhang, Xiong Y" wrote:
>
> > On an intel skylake machine with upstream qemu, if I add
> > "rdm=strategy=host, policy=strict" to hvm.cfg, win 8.1 DomU couldn't
> > boot up and continues reboot.
> >
> > Steps to reproduce this issue:
> >
> > 1) Boot x
Hi,
On 20/07/17 20:01, osstest service owner wrote:
> flight 112033 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/112033/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-ovmf
flight 112065 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112065/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
112004
Regressions
On Fri, Jul 7, 2017 at 7:48 AM, Chao Gao wrote:
> This patch adds a field, counter, in struct vmx_pi_blocking_vcpu to track
> how many entries are on the pi blocking list.
>
> Signed-off-by: Chao Gao
Minor nit: The grammar in the title isn't quite right; "vcpu number"
would be "the number ident
Hi all,
please find attached my notes.
Lars
Session URL: http://sched.co/AjB3
ACTIONS on Lars, Andy and Juergen
ACTIONS on Stefano and Julien
Community Call
==
This was a discussion about whether we should do more community calls,
in critical areas. The background was whether we sh
On Fri, Jul 7, 2017 at 7:48 AM, Chao Gao wrote:
> Currently, a blocked vCPU is put in its pCPU's pi blocking list. If
> too many vCPUs are blocked on a given pCPU, it will incur that the list
> grows too long. After a simple analysis, there are 32k domains and
> 128 vcpu per domain, thus about 4M
__WARN() is an internal helper that is only available on
some architectures, but causes a build error e.g. on ARM64
in some configurations:
drivers/xen/pvcalls-back.c: In function 'set_backend_state':
drivers/xen/pvcalls-back.c:1097:5: error: implicit declaration of function
'__WARN' [-Werror=imp
On 20/07/17 13:57, Wei Liu wrote:
On Thu, Jul 20, 2017 at 12:49:37PM +0100, Andrew Cooper wrote:
On 20/07/17 12:47, Wei Liu wrote:
On Thu, Jul 20, 2017 at 12:45:38PM +0100, Roger Pau Monné wrote:
On Thu, Jul 20, 2017 at 12:35:56PM +0100, Wei Liu wrote:
The code says it defaults to false.
Sig
On Fri, Jul 7, 2017 at 7:49 AM, Chao Gao wrote:
> In order to analyze PI blocking list operation frequence and obtain
> the list length, add some relevant events to xentrace and some
> associated code in xenalyze. Event ASYNC_PI_LIST_DEL may happen in interrupt
> context, which incurs current assu
On Fri, Jul 21, 2017 at 05:21:26PM +0100, Andrew Cooper wrote:
> On 20/07/17 13:57, Wei Liu wrote:
> > On Thu, Jul 20, 2017 at 12:49:37PM +0100, Andrew Cooper wrote:
> > > On 20/07/17 12:47, Wei Liu wrote:
> > > > On Thu, Jul 20, 2017 at 12:45:38PM +0100, Roger Pau Monné wrote:
> > > > > On Thu, Ju
flight 112072 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112072/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 111765
build-i386
flight 112091 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112091/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1683ecec41a7c944783c51efa75375f1e0a71d08
baseline version:
ovmf 79aac4dd756bb2809cdcb
On 21/07/17 02:42, Boqun Feng wrote:
On Thu, Jul 20, 2017 at 10:38:59AM +0100, Andrew Cooper wrote:
On 20/07/17 06:29, Boqun Feng (Intel) wrote:
Add a "umip" test for the User-Model Instruction Prevention. The test
simply tries to run sgdt/sidt/sldt/str/smsw in guest user-mode with
CR4_UMIP = 1
On 21/07/17 08:01, Felix Schmoll wrote:
Much better. Just one final question. Do you intend this
function to block until data becomes available? (because that
appears to be how it behaves.)
Yes. I could split it up into two functions if that bothers you. Or do
you just want me
Dear George,
First I would state terms as following:
* Sharing HW - using the same hardware by different domains using PV
drivers, so actually one domain accessing the HW directly and serves
other domains.
* Assigning HW - providing access to some particular HW for some
particular domain. E.g.
On 21/07/17 11:43, Julien Grall wrote:
On 20/07/17 17:54, Wei Liu wrote:
On Thu, Jul 20, 2017 at 05:46:50PM +0100, Wei Liu wrote:
CC relevant maintainers
On Thu, Jul 20, 2017 at 05:20:43PM +0200, David Woodhouse wrote:
From: David Woodhouse
This includes stuff lke the hypercall tables whi
On Thu, Jul 20, 2017 at 01:57:17PM +0100, Wei Liu wrote:
> On Thu, Jul 20, 2017 at 12:49:37PM +0100, Andrew Cooper wrote:
> > On 20/07/17 12:47, Wei Liu wrote:
> > > On Thu, Jul 20, 2017 at 12:45:38PM +0100, Roger Pau Monné wrote:
> > > > On Thu, Jul 20, 2017 at 12:35:56PM +0100, Wei Liu wrote:
> >
On 06/23/2017 11:54 AM, Dario Faggioli wrote:
> Instead of keeping an NR_CPUS big array of csched2_runqueue_data
> elements, directly inside the csched2_private structure, allocate
> it dynamically.
>
> This has two positive effects:
> - reduces the size of csched2_private sensibly, which is
> e
On Fri, Jul 21, 2017 at 12:44:18PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 20, 2017 at 01:57:17PM +0100, Wei Liu wrote:
> > On Thu, Jul 20, 2017 at 12:49:37PM +0100, Andrew Cooper wrote:
> > > On 20/07/17 12:47, Wei Liu wrote:
> > > > On Thu, Jul 20, 2017 at 12:45:38PM +0100, Roger Pau Mo
On 06/23/2017 11:54 AM, Dario Faggioli wrote:
> Instead of keeping an NR_CPUS big array of int-s,
> directly inside csched2_private, use a per-cpu
> variable.
>
> That's especially beneficial (in terms of saved
> memory) when there are more instance of Credit2 (in
> different cpupools), and also h
On 06/23/2017 11:55 AM, Dario Faggioli wrote:
> With the aim of improving memory size and layout, and
> at the same time trying to put related fields reside
> in the same cacheline.
>
> Here's a summary of the output of `pahole`, with and
> without this patch, for the affected data structures.
>
On Fri, Jul 21, 2017 at 05:51:02PM +0100, Wei Liu wrote:
> On Fri, Jul 21, 2017 at 12:44:18PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jul 20, 2017 at 01:57:17PM +0100, Wei Liu wrote:
> > > On Thu, Jul 20, 2017 at 12:49:37PM +0100, Andrew Cooper wrote:
> > > > On 20/07/17 12:47, Wei Liu wrot
Hello Julien,
On 21.07.17 15:52, Julien Grall wrote:
This is very early boot in head.S so having the full log will not
really help here...
What is more interesting is where the different modules have been
loaded in memory:
- Device Tree
- Kernel
- Xen
- Initramfs (if any)
We
On 06/23/2017 11:55 AM, Dario Faggioli wrote:
> With the aim of improving memory size and layout, and
> at the same time trying to put related fields reside
> in the same cacheline.
>
> Here's a summary of the output of `pahole`, with and
> without this patch, for the affected data structures.
>
On 06/23/2017 11:55 AM, Dario Faggioli wrote:
> Nothing changed in `pahole` output, in terms of holes
> and padding, but some fields have been moved, to put
> related members in same cache line.
>
> Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
> ---
> Cc: Meng Xu
> Cc: George Dunlap
This patch fixes the following sparse warnings:
drivers/block/xen-blkfront.c:916:45: warning: incorrect type in argument 2
(different base types)
drivers/block/xen-blkfront.c:916:45:expected restricted blk_status_t
[usertype] error
drivers/block/xen-blkfront.c:916:45:got int [signed] err
On 06/23/2017 11:55 AM, Dario Faggioli wrote:
> Exclusive pinning of vCPUs is used, sometimes, for
> achieving the highest level of determinism, and the
> least possible overhead, for the vCPUs in question.
>
> Although static 1:1 pinning is not recommended, for
> general use cases, optimizing the
flight 112085 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112085/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 4 host-install(4)broken REGR. vs. 111920
test-armhf-armhf-lib
On Fri, Jun 23, 2017 at 6:55 AM, Dario Faggioli
wrote:
>
> Nothing changed in `pahole` output, in terms of holes
> and padding, but some fields have been moved, to put
> related members in same cache line.
>
> Signed-off-by: Dario Faggioli
> ---
> Cc: Meng Xu
> Cc: George Dunlap
> ---
> xen/co
On 07/21/2017 12:17 PM, Arnd Bergmann wrote:
> __WARN() is an internal helper that is only available on
> some architectures, but causes a build error e.g. on ARM64
> in some configurations:
>
> drivers/xen/pvcalls-back.c: In function 'set_backend_state':
> drivers/xen/pvcalls-back.c:1097:5: error:
On 21/07/17 14:50, Anthony PERARD wrote:
On Tue, Jul 18, 2017 at 03:22:41PM -0700, Stefano Stabellini wrote:
From: Igor Druzhinin
...
+static uint8_t *xen_replace_cache_entry_unlocked(hwaddr old_phys_addr,
+ hwaddr new_phys_addr,
+
On Fri, 21 Jul 2017, Arnd Bergmann wrote:
> __WARN() is an internal helper that is only available on
> some architectures, but causes a build error e.g. on ARM64
> in some configurations:
>
> drivers/xen/pvcalls-back.c: In function 'set_backend_state':
> drivers/xen/pvcalls-back.c:1097:5: error: i
On Fri, 21 Jul 2017, Julien Grall wrote:
> > > @x86_cacheattrcan be 'uc', 'wc', 'wt', 'wp', 'wb' or 'suc'.
> > > Default
> > > is 'wb'.
> >
> > Also here, I would write:
> >
> > @x86_cacheattr Only 'wb' (write-back) is supported today.
> >
> > Like you wrote la
On Fri, 21 Jul 2017, Julien Grall wrote:
> Hi,
>
> On 18/07/17 21:07, Stefano Stabellini wrote:
> > On Mon, 17 Jul 2017, Bhupinder Thakur wrote:
> > > This patch finally adds the support for vuart console. It adds
> > > two new fields in the console initialization:
> > >
> > > - optional
> > > -
flight 112104 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112104/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 13 mig
On Fri, 2017-07-21 at 13:51 -0400, Meng Xu wrote:
> On Fri, Jun 23, 2017 at 6:55 AM, Dario Faggioli
> wrote:
> >
> > Nothing changed in `pahole` output, in terms of holes
> > and padding, but some fields have been moved, to put
> > related members in same cache line.
> >
> > Signed-off-by: Dario
On Fri, 2017-07-21 at 18:05 +0100, George Dunlap wrote:
> On 06/23/2017 11:55 AM, Dario Faggioli wrote:
> >
> > While there, improve the wording, style and alignment
> > of comments too.
> >
> > Signed-off-by: Dario Faggioli
>
> I haven't taken a careful look at these; the idea sounds good and
On Fri, 2017-07-21 at 18:19 +0100, George Dunlap wrote:
> On 06/23/2017 11:55 AM, Dario Faggioli wrote:
> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> > index 4f6330e..85e014d 100644
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> > @@ -429,6 +429
When replacing the rank lock with individual per-IRQs lock soon, we will
still need the ability to lock multiple IRQs.
Provide two helper routines which lock and unlock a number of consecutive
IRQs in the right order.
Forward-looking the locking function fills an array of pending_irq
pointers, so t
Since the GICs MMIO access always covers a number of IRQs at once,
introduce wrapper functions which loop over those IRQs, take their
locks and read or update the priority values.
This will be used in a later patch.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic.c| 37 ++
Hi,
this is the first part of the attempt to rewrite the VGIC to solve the
issues we discovered when adding the ITS emulation.
The problems we identified resulted in the following list of things that
need fixing:
1) introduce a per-IRQ lock
2) remove the IRQ rank scheme (of storing IRQ properties)
For LPIs we stored the priority value in struct pending_irq, but all
other type of IRQs were using the irq_rank structure for that.
Now that every IRQ using pending_irq, we can remove the special handling
we had in place for LPIs and just use the now unified access wrappers.
Signed-off-by: Andre P
So far the rank lock is protecting the physical IRQ routing for a
particular virtual IRQ (though this doesn't seem to be documented
anywhere). So although these functions don't really touch the rank
structure, the lock prevents them from running concurrently.
This seems a bit like a kludge, so as w
Currently we protect the pending_irq structure with the corresponding
VGIC VCPU lock. There are problems in certain corner cases (for
instance if an IRQ is migrating), so let's introduce a per-IRQ lock,
which will protect the consistency of this structure independent from
any VCPU.
For now this jus
Now that we no longer need the struct vgic_irq_rank, we can remove the
definition and all the helper functions.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic.c | 54
xen/include/asm-arm/domain.h | 6 +
xen/include/asm-arm/vgic.h
For now vgic_get_target_vcpu takes a VCPU and an IRQ number, because
this is what we need for finding the proper rank and the VCPU in there.
In the future the VCPU will be looked up in the struct pending_irq.
To avoid locking issues, let's pass the pointer to the pending_irq
instead. We can read th
When putting a (pending) IRQ into an LR, we should better make sure that
no-one changes it behind our back. So make sure we take the pending_irq
lock. This bubbles up to all users of gic_add_to_lr_pending() and
gic_raise_guest_irq().
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic.c | 14
Since we will soon store a virtual IRQ's target VCPU in struct pending_irq,
generalise the existing storage for an LPI's target to cover all IRQs.
This just renames "lpi_vcpu_id" to "vcpu_id", but doesn't change anything
else yet.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-lpi.c | 2
Since we will soon store a virtual IRQ's priority in struct pending_irq,
generalise the existing storage for an LPI's priority to cover all IRQs.
This just renames "lpi_priority" to "priority", but doesn't change
anything else yet.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 4
gic_events_need_delivery() reads the cur_priority field twice, also
relies on the consistency of status bits.
So it should take pending_irq lock.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/xe
The enabled bits for a group of IRQs are still stored in the irq_rank
structure, although we already have the same information in pending_irq,
in the GIC_IRQ_GUEST_ENABLED bit of the "status" field.
Remove the storage from the irq_rank and just utilize the existing
wrappers to cover enabling/disabl
For "historical" reasons we used to pass a vCPU pointer to
vgic_get_target_vcpu(), which was only considered to distinguish private
IRQs. Now since we have the unique pending_irq pointer already, we don't
need the vCPU anymore, but just the domain.
So change this function to avoid a rather hackish
So far a virtual interrupt's priority is stored in the irq_rank
structure, which covers multiple IRQs and has a single lock for this
group.
Generalize the already existing priority variable in struct pending_irq
to not only cover LPIs, but every IRQ. Access to this value is protected
by the per-IRQ
As the priority value is now officially a member of struct pending_irq,
we need to take its lock when manipulating it via ITS commands.
Make sure we take the IRQ lock after the VCPU lock when we need both.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 26 +++-
The IRQ configuration (level or edge triggered) for a group of IRQs
are still stored in the irq_rank structure.
Introduce a new bit called GIC_IRQ_GUEST_LEVEL in the "status" field,
which holds that information.
Remove the storage from the irq_rank and use the existing wrappers to
store and retriev
Currently there is a gic_raise_inflight_irq(), which serves the very
special purpose of handling a newly injected interrupt while an older
one is still handled. This has only one user, in vgic_vcpu_inject_irq().
Now with the introduction of the pending_irq lock this will later on
result in a nasty
In preparation for storing the virtual interrupt priority in the struct
pending_irq, rename the existing "priority" member to "cur_priority".
This is to signify that this is the current priority of an interrupt
which has been injected to a VCPU. Once this happened, its priority must
stay fixed at t
When we return from a domain with the active bit set in an LR,
we update our pending_irq accordingly. This touches multiple status
bits, so requires the pending_irq lock.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/arm/gic.c
Instead of using an atomic access and hoping for the best, let's use
the new pending_irq lock now to make sure we read a sane version of
the target VCPU.
That still doesn't solve the problem mentioned in the comment, but
paves the way for future improvements.
Signed-off-by: Andre Przywara
---
xe
The VCPU a shared virtual IRQ is targeting is currently stored in the
irq_rank structure.
For LPIs we already store the target VCPU in struct pending_irq, so
move SPIs over as well.
The ITS code, which was using this field already, was so far using the
VCPU lock to protect the pending_irq, so move
Since a VCPU can own multiple IRQs, the natural locking order is to take
a VCPU lock first, then the individual per-IRQ locks.
However there are situations where the target VCPU is not known without
looking into the struct pending_irq first, which usually means we need to
take the IRQ lock first.
T
On Fri, Jul 21, 2017 at 8:55 PM, Dario Faggioli
wrote:
> On Fri, 2017-07-21 at 18:19 +0100, George Dunlap wrote:
>> On 06/23/2017 11:55 AM, Dario Faggioli wrote:
>> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
>> > index 4f6330e..85e014d 100644
>> > --- a/xen/common/sched_c
Hi Juergen,
On 07/21/2017 02:36 AM, Juergen Gross wrote:
On 04/07/17 20:34, Gustavo A. R. Silva wrote:
Remove unnecessary static on local variables last_frontswap_pages and
tgt_frontswap_pages. Such variables are initialized before being used,
on every execution path throughout the function. Th
On Fri, Jul 21, 2017 at 3:17 AM, Juergen Gross wrote:
> drivers/xen/pvcalls-back.c | 1236
>
This really doesn't look like a fix.
The merge window is over.
So I'm not pulling this without way more explanations of why I should.
Linu
flight 112081 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112081/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 112036
test-armhf-armhf-libvirt-xsm 14 saveresto
Hey Razvan,
the vm_event that is being generated by doing
VM_EVENT_FLAG_GET_NEXT_INTERRUPT sends almost all required information
about the interrupt to the listener to allow it to get reinjected,
except the instruction length. If the listener wants to reinject the
interrupt to the guest via xc_hvm_
On 07/22/2017 12:33 AM, Tamas K Lengyel wrote:
> Hey Razvan,
Hello,
> the vm_event that is being generated by doing
> VM_EVENT_FLAG_GET_NEXT_INTERRUPT sends almost all required information
> about the interrupt to the listener to allow it to get reinjected,
> except the instruction length. If the
1 - 100 of 124 matches
Mail list logo
