Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Thu, Jul 9, 2015 at 7:27 PM, Julien Grall julien.gr...@citrix.com wrote: On 09/07/2015 12:30, Manish Jaggi wrote: On Thursday 09 July 2015 01:38 PM, Julien Grall wrote: On 09/07/2015 08:13, Manish Jaggi wrote: If this was a domctl there might be scope for accepting an implementation which made assumptions such as sbdf == deviceid. However I'd still like to see this topic given proper treatment in the design and not just glossed over with this is how ThunderX does things. I got your point. Or maybe the solution is simple and we should just do it now -- i.e. can we add a new field to the PHYSDEVOP_pci_host_bridge_add argument struct which contains the base deviceid for that bridge deviceId would be same as sbdf. As we dont have a way to translate sbdf to deviceID. I think we have to be clear in this design document about the different meaning. When the Device Tree is used, it's assumed that the deviceID will be equal to the requester ID and not the sbdf. Does SMMU v2 has a concept of requesterID. I see requesterID term in SMMUv3 The requester ID is part of the PCI spec and not the SMMU. The version of the SMMUv2 spec doesn't mention anything about PCI. I suspect this is because the spec has been written before the introduced PCI. And therefore this is implementation defined. Linux provides a function (pci_for_each_dma_alias) which will return a requester ID for a given PCI device. It appears that the BDF (the 's' of sBDF is only internal to Linux and not part of the hardware) is equal to the requester ID on your platform but we can't assume it for anyone else. so you mean requesterID = pci_for_each_dma_alias(sbdf) Yes. When we have a PCI in hand, we have to find the requester ID for this device. That is the question. How to map requesterID to sbdf See above. On Once ? Yes. we have it we can deduce the streamID and the deviceID. The way to do it will depend on whether we use device tree or ACPI: - For device tree, the streamID, and deviceID will be equal to the requester ID what do you think should be streamID when a device is PCI EP and is enumerated. Also per ARM SMMU 2.0 spec StreamID is implementation specific. As per SMMUv3 specs For PCI, it is intended that StreamID is generated from the PCI RequesterID. The generation function may be 1:1 where one Root Complex is hosted by one SMMU I think my sentence For device tree, the streamID, and deviceID will be equal to the requester ID is pretty clear. FWIW, this is the solution chosen for Linux: Assume Stream ID == Requester ID for now. We need a way to describe the ID mappings in FDT (see arm_smmu_add_pci_device in drivers/iommu/arm-smmu.c). You can refer to my point below about ACPI tables. The solution would be exactly the same. If we have a requester ID in hand we can do pretty much everything. There is already one proposal by Mark Rutland on this topic about describing StreamID to Requester ID mapping in DT. http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333199.html Probably till it gets finalized assuming RequesterID=StreamId is the only way since deriving StreamID from PCIe RequsterID will vary from one vendor to another. Thanks, Pranav The whole point of my previous email is to give insight about what we need and what we can deduce based on firmware tables. I didn't cover anything implementation details. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 16/16] tools: parse to enable new rdm policy parameters
The first issue (which would really be relevant to the documentation
patch) is that the documentation is in a separate commit. There are
sometimes valid reasons for doing this. I'm not sure if they apply,
Wei suggested we should organize/spit all patches according to libxl,
libxc, xc and xl.
but if they do this should be explained in one of the commit
messages. If this was done I'm afraid I have missed it.
In this patch head description, maybe I can change something like this
This patch parses to enable user configurable parameters to specify
RDM resource and according policies which are defined previously,
+}else if ( !strcmp(optkey, rdm_policy) ) {
+if ( !strcmp(tok, strict) ) {
+pcidev-rdm_policy = LIBXL_RDM_RESERVE_POLICY_STRICT;
+} else if ( !strcmp(tok, relaxed) ) {
+pcidev-rdm_policy = LIBXL_RDM_RESERVE_POLICY_RELAXED;
+} else {
+XLU__PCI_ERR(cfg, %s is not an valid PCI RDM property
+ policy: 'strict' or 'relaxed'.,
+ tok);
+goto parse_error;
+}
This section has coding style (whitespace) problems and long lines.
If you need to respin, please fix them.
Are you saying this?
} else if ( - }else if (
} else { - }else {
Additionally I don't found which line is over 80 characters.
+for (tok = ptr, end = ptr + strlen(ptr) + 1; ptr end; ptr++) {
+switch(state) {
+case STATE_TYPE:
+if (*ptr == '=') {
+state = STATE_RDM_STRATEGY;
+*ptr = '\0';
+if (strcmp(tok, strategy)) {
+XLU__PCI_ERR(cfg, Unknown RDM state option: %s, tok);
+goto parse_error;
+}
+tok = ptr + 1;
+}
This code is extremely repetitive.
I just refer to xlu_pci_parse_bdf()
switch(state) {
case STATE_DOMAIN:
if ( *ptr == ':' ) {
state = STATE_BUS;
*ptr = '\0';
if ( hex_convert(tok, dom, 0x) )
goto parse_error;
tok = ptr + 1;
}
break;
Really I would prefer that this parsing was done with a miniature flex
parser, rather than ad-hoc pointer arithmetic and use of strtok.
Sorry, could you show this explicitly?
Thanks
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling
On 10.07.15 at 07:59, feng...@intel.com wrote: If you agree with doing all this in a central place, maybe we can create an arch hook for 'struct scheduler' to do this and call it in all the places vcpu_runstate_change() gets called. What is your opinion about this? Doing this in a central place is certainly the right approach, but adding an arch hook that needs to be called everywhere vcpu_runstate_change() wouldn't serve that purpose. Instead we'd need to replace all current vcpu_runstate_change() calls with calls to a new function calling both this and the to be added arch hook. But please wait for George's / Dario's feedback, because they seem to be even less convinced than me about your model of tying the updates to runstate changes. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked
On 10.07.15 at 08:21, feng...@intel.com wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, July 09, 2015 3:26 PM
To: Wu, Feng; Tian, Kevin
Cc: Andrew Cooper; george.dun...@eu.citrix.com; Zhang, Yang Z;
xen-devel@lists.xen.org; k...@xen.org
Subject: RE: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU
is blocked
On 09.07.15 at 00:49, kevin.t...@intel.com wrote:
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Wednesday, July 08, 2015 9:09 PM
On 08/07/2015 13:46, Jan Beulich wrote:
On 08.07.15 at 13:00, kevin.t...@intel.com wrote:
@@ -1848,6 +1869,33 @@ static struct hvm_function_table __initdata
vmx_function_table = {
.enable_msr_exit_interception =
vmx_enable_msr_exit_interception,
};
+/*
+ * Handle VT-d posted-interrupt when VCPU is blocked.
+ */
+static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
+{
+struct arch_vmx_struct *vmx;
+unsigned int cpu = smp_processor_id();
+
+spin_lock(per_cpu(pi_blocked_vcpu_lock, cpu));
+
+/*
+ * FIXME: The length of the list depends on how many
+ * vCPU is current blocked on this specific pCPU.
+ * This may hurt the interrupt latency if the list
+ * grows to too many entries.
+ */
let's go with this linked list first until a real issue is identified.
This is exactly the way of thinking I dislike when it comes to code
that isn't intended to be experimental only: We shouldn't wait
for problems to surface when we already can see them. I.e. if
there are no plans to deal with this, I'd ask for the feature to be
off by default and be properly marked experimental in the
command line option documentation (so people know to stay
away from it).
And in this specific case, there is no balancing of vcpus across the
pcpus lists.
One can construct a pathological case using pinning and pausing to get
almost every vcpu on a single pcpu list, and vcpus recieving fewer
interrupts will exasperate the problem by staying on the list for longer
periods of time.
In that extreme case I believe many contentions in other code paths will
be much larger than overhead caused by this structure limitation.
Examples?
IMO, the PI feature cannot be declared as done/supported with this bug
remaining. OTOH, it is fine to be experimental, and disabled by default
for people who wish to experiment.
Again, I don't expect to see it disabled as experimental. For good
production
environment where vcpus are well balanced and interrupt latency is
sensitive,
linked list should be efficient here. For bad environment like extreme case
you raised, I don't know whether it really matters to just tune interrupt
path.
Can you _guarantee_ that everything potentially leading to such a
pathological situation is covered by XSA-77? And even if it is now,
removing elements from the waiver list would become significantly
more difficult if disconnected behavior like this one would need to
be taken into account.
Please understand that history has told us to be rather more careful
than might seem necessary with this: ATS originally having been
enabled by default is one bold example, and the recent flood of MSI
related XSAs is another; I suppose I could find more. All affecting
code originating from Intel, apparently written with only functionality
in mind, while having left out (other than basic) security considerations.
IOW, with my committer role hat on, the feature is going to be
experimental (and hence default off) unless the issue here gets
addressed. And no, I cannot immediately suggest a good approach,
and with all of the rush before the feature freeze I also can't justify
taking a lot of time to think of options.
Is it acceptable to you if I only add the blocked vcpus that has
assigned devices to the list? I think that should shorten the
length of the list.
I actually implied this to be the case already, i.e.
- if it's not, this needs to be fixed anyway,
- it's not going to eliminate the concern (just think of a couple of
many-vCPU guests all having devices assigned).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling
-Original Message- From: George Dunlap [mailto:george.dun...@eu.citrix.com] Sent: Thursday, July 09, 2015 10:28 PM To: Dario Faggioli; Jan Beulich Cc: Tian, Kevin; Wu, Feng; andrew.coop...@citrix.com; xen-devel; Zhang, Yang Z; k...@xen.org Subject: Re: [Xen-devel] Fwd: [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling On 07/09/2015 03:18 PM, Dario Faggioli wrote: On Thu, 2015-07-09 at 14:44 +0100, Jan Beulich wrote: On 09.07.15 at 14:53, george.dun...@eu.citrix.com wrote: Consider the following scenario: - v1 blocks on pcpu 0. - vcpu_runstate_change() will do everything necessary for v1 on p0. - The scheduler does load balancing and moves v1 to p1, calling vcpu_migrate(). Because the vcpu is still blocked, vcpu_runstate_change() is not called. - A device interrupt is generated. What happens to the interrupt? Does everything still work properly, or will the device wake-up interrupt go to the wrong pcpu (p0 rather than p1)? I think much of this was discussed before, since I also disliked the hooking into vcpu_runstate_change(). What I remember having been told is that it really only matters which pCPU's list a vCPU is on, not what v-processor says. Right. But, as far as I could understand from the patches I've seen, a vcpu ends up in a list when it blocks, and when it blocks there will be a context switch, and hence we can deal with the queueing during the the context switch itself (which is, in part, an arch specific operation already). What am I missing? I think what you're missing is that Jan is answering my question about migrating a blocked vcpu, not arguing that vcpu_runstate_change() is the right way to go. At least that's how I understood him. :-) But regarding context_switch: I think the reason we need more hooks than that is that context_switch only changes into and out of running state. There are also changes that need to happen when you change from blocked to offline, offline to blocked, blocked to runnable, c; these don't go through context_switch. That's why I was suggesting some architectural equivalents to the SCHED_OP() callbacks to be added to vcpu_wake c. vcpu_runstate_change() is at the moment a nice quiet cul-de-sac that just does a little bit of accounting; I'd rather not have it suddenly become a major thoroughfare for runstate change hooks, if we can avoid it. :-) So in my understanding, vcpu_runstate_change() is a central place to do this, which is good. However, this function is original designed to be served only for accounting. it is a little intrusive to make it so important after adding the hooks in it. If you agree with doing all this in a central place, maybe we can create an arch hook for 'struct scheduler' to do this and call it in all the places vcpu_runstate_change() gets called. What is your opinion about this? Thanks, Feng -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, July 09, 2015 3:26 PM
To: Wu, Feng; Tian, Kevin
Cc: Andrew Cooper; george.dun...@eu.citrix.com; Zhang, Yang Z;
xen-devel@lists.xen.org; k...@xen.org
Subject: RE: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU
is blocked
On 09.07.15 at 00:49, kevin.t...@intel.com wrote:
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Wednesday, July 08, 2015 9:09 PM
On 08/07/2015 13:46, Jan Beulich wrote:
On 08.07.15 at 13:00, kevin.t...@intel.com wrote:
@@ -1848,6 +1869,33 @@ static struct hvm_function_table __initdata
vmx_function_table = {
.enable_msr_exit_interception =
vmx_enable_msr_exit_interception,
};
+/*
+ * Handle VT-d posted-interrupt when VCPU is blocked.
+ */
+static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
+{
+struct arch_vmx_struct *vmx;
+unsigned int cpu = smp_processor_id();
+
+spin_lock(per_cpu(pi_blocked_vcpu_lock, cpu));
+
+/*
+ * FIXME: The length of the list depends on how many
+ * vCPU is current blocked on this specific pCPU.
+ * This may hurt the interrupt latency if the list
+ * grows to too many entries.
+ */
let's go with this linked list first until a real issue is identified.
This is exactly the way of thinking I dislike when it comes to code
that isn't intended to be experimental only: We shouldn't wait
for problems to surface when we already can see them. I.e. if
there are no plans to deal with this, I'd ask for the feature to be
off by default and be properly marked experimental in the
command line option documentation (so people know to stay
away from it).
And in this specific case, there is no balancing of vcpus across the
pcpus lists.
One can construct a pathological case using pinning and pausing to get
almost every vcpu on a single pcpu list, and vcpus recieving fewer
interrupts will exasperate the problem by staying on the list for longer
periods of time.
In that extreme case I believe many contentions in other code paths will
be much larger than overhead caused by this structure limitation.
Examples?
IMO, the PI feature cannot be declared as done/supported with this bug
remaining. OTOH, it is fine to be experimental, and disabled by default
for people who wish to experiment.
Again, I don't expect to see it disabled as experimental. For good
production
environment where vcpus are well balanced and interrupt latency is
sensitive,
linked list should be efficient here. For bad environment like extreme case
you raised, I don't know whether it really matters to just tune interrupt
path.
Can you _guarantee_ that everything potentially leading to such a
pathological situation is covered by XSA-77? And even if it is now,
removing elements from the waiver list would become significantly
more difficult if disconnected behavior like this one would need to
be taken into account.
Please understand that history has told us to be rather more careful
than might seem necessary with this: ATS originally having been
enabled by default is one bold example, and the recent flood of MSI
related XSAs is another; I suppose I could find more. All affecting
code originating from Intel, apparently written with only functionality
in mind, while having left out (other than basic) security considerations.
IOW, with my committer role hat on, the feature is going to be
experimental (and hence default off) unless the issue here gets
addressed. And no, I cannot immediately suggest a good approach,
and with all of the rush before the feature freeze I also can't justify
taking a lot of time to think of options.
Is it acceptable to you if I only add the blocked vcpus that has
assigned devices to the list? I think that should shorten the
length of the list.
Thanks,
Feng
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6] run QEMU as non-root
On Thu, 2015-07-09 at 17:14 -0600, Jim Fehlig wrote: On 07/09/2015 04:34 AM, Ian Campbell wrote: On Wed, 2015-07-01 at 15:03 -0600, Jim Fehlig wrote: Perhaps. But thanks for providing a way (b_info-device_model_user) for apps to override the libxl policy. You mentioned in v5 that libvirt supports setting both the user and the group and that the qemu driver supports that. How does that work? AFAICT qemu's -runas option only takes a user and it takes that user's primary group and uses that with no configurability. I think that's a fine way to do things, but you implied greater configurability in libvirt and I'm now curious... The libvirt qemu driver doesn't use qemu's -runas option. It calls setregid()/setreuid() in the child after fork()'ing, but before exec()'ing, qemu. Makes sense, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 0/8] Xen VMware tools support
On 28.06.15 at 01:27, don.sl...@gmail.com wrote: Changes v11 to v12: Rebased on staging. Jan Beulich (xen: Add ring 3 vmware_port support) As there don't seem to be enough convincing arguments for this to be worthwhile, I'm going to drop this... Dropped the 2 ring3 patches. Ian Campbell (tools: Add vmware_hwver support): s/come/comes/ Done I'm not sure this hunk has anything to do with this patch, nor what the semantic difference between the old and new text is supposed to be. Dropped comment change. Ian Campbell (multiple): In v11 this seems to have morphed into only LIBXL_HAVE_LIBXL_VGA_INTERFACE_TYPE_VMWARE being provided, which is clearly not an appropriate umbrella #define. #define LIBXL_HAVE_CREATEINFO_VMWARE 1 Lets just have a single one of these indicating support for vmware, it should be added at the end of the series after all the baseline vmware functionality is in place. I think that means hwver, vga=vmware and this port stuff. Make (tools: Add vga=vmware) no longer independent. Change the #define to LIBXL_HAVE_VMWARE Jan Beulich (xen: Add vmware_port support): Surrounding code avoiding the use of break makes the result look rather inconsistent. Please move this up immediately after the XSM check, or drop the break. Moved it up. George Dunlap (Add IOREQ_TYPE_VMWARE_PORT): Sorry for coming a bit late to this party. On a high level I think this is good, but there doesn't seem to be anything in here in particular that is vmware-specific. Would it make more sense to give this a more generic name, and have it include all of the general-purpose registers? Did not change at this time because QEMU would need changes 1st. George Dunlap (Add xentrace to vmware_port): Do you need to log edi as well? It looks like it's not used. I think it makes sense to indicate that edi can be used and may in the future. And do you need to log all the registers here? It seems like port + regs-_ecx would be enough to tell you why it got ignored. Adjusted to log just port and eax (ecx was NOT tested for). I was actually meaning to apply this (at least until patch 6; I'm not convinced patch 7 makes sense to go in at this point), but noticed that comments by Konrad were still un-addressed. I'm also expecting some re-basing to be needed on top of Paul's emulation re-work. Wei, considering that this had already missed 4.5, would you be okay to take at least first 6 patches (which seem reasonably risk free) after the freeze? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [rumpuserxen test] 59349: regressions - FAIL
flight 59349 rumpuserxen real [real] http://logs.test-lab.xenproject.org/osstest/logs/59349/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 3b91e44996ea6ae1276bce1cc44f38701c53ee6f baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad Last test of basis33866 2015-01-28 04:19:26 Z 163 days Failing since 34129 2015-02-03 04:21:40 Z 157 days 112 attempts Testing same since50441 2015-04-15 20:51:55 Z 85 days 67 attempts People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net Wei Liu l...@liuw.name jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 535 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 14/15] tools/libxc: add support to altp2m hvmops
On Thu, 2015-07-09 at 17:52 -0700, Ed White wrote: From: Tamas K Lengyel tleng...@novetta.com Wrappers to issue altp2m hvmops. Signed-off-by: Tamas K Lengyel tleng...@novetta.com Signed-off-by: Ravi Sahita ravi.sah...@intel.com These all appear to be valid wrappings of the hypercall interfaces, so if the h/v folks are fine with the interface itself: Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked
On 10.07.15 at 09:29, feng...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, July 10, 2015 2:32 PM
On 10.07.15 at 08:21, feng...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, July 09, 2015 3:26 PM
On 09.07.15 at 00:49, kevin.t...@intel.com wrote:
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Wednesday, July 08, 2015 9:09 PM
On 08/07/2015 13:46, Jan Beulich wrote:
On 08.07.15 at 13:00, kevin.t...@intel.com wrote:
@@ -1848,6 +1869,33 @@ static struct hvm_function_table
__initdata
vmx_function_table = {
.enable_msr_exit_interception =
vmx_enable_msr_exit_interception,
};
+/*
+ * Handle VT-d posted-interrupt when VCPU is blocked.
+ */
+static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
+{
+struct arch_vmx_struct *vmx;
+unsigned int cpu = smp_processor_id();
+
+spin_lock(per_cpu(pi_blocked_vcpu_lock, cpu));
+
+/*
+ * FIXME: The length of the list depends on how many
+ * vCPU is current blocked on this specific pCPU.
+ * This may hurt the interrupt latency if the list
+ * grows to too many entries.
+ */
let's go with this linked list first until a real issue is
identified.
This is exactly the way of thinking I dislike when it comes to code
that isn't intended to be experimental only: We shouldn't wait
for problems to surface when we already can see them. I.e. if
there are no plans to deal with this, I'd ask for the feature to be
off by default and be properly marked experimental in the
command line option documentation (so people know to stay
away from it).
And in this specific case, there is no balancing of vcpus across the
pcpus lists.
One can construct a pathological case using pinning and pausing to get
almost every vcpu on a single pcpu list, and vcpus recieving fewer
interrupts will exasperate the problem by staying on the list for
longer
periods of time.
In that extreme case I believe many contentions in other code paths will
be much larger than overhead caused by this structure limitation.
Examples?
IMO, the PI feature cannot be declared as done/supported with this bug
remaining. OTOH, it is fine to be experimental, and disabled by
default
for people who wish to experiment.
Again, I don't expect to see it disabled as experimental. For good
production
environment where vcpus are well balanced and interrupt latency is
sensitive,
linked list should be efficient here. For bad environment like extreme
case
you raised, I don't know whether it really matters to just tune
interrupt
path.
Can you _guarantee_ that everything potentially leading to such a
pathological situation is covered by XSA-77? And even if it is now,
removing elements from the waiver list would become significantly
more difficult if disconnected behavior like this one would need to
be taken into account.
Please understand that history has told us to be rather more careful
than might seem necessary with this: ATS originally having been
enabled by default is one bold example, and the recent flood of MSI
related XSAs is another; I suppose I could find more. All affecting
code originating from Intel, apparently written with only functionality
in mind, while having left out (other than basic) security considerations.
IOW, with my committer role hat on, the feature is going to be
experimental (and hence default off) unless the issue here gets
addressed. And no, I cannot immediately suggest a good approach,
and with all of the rush before the feature freeze I also can't justify
taking a lot of time to think of options.
Is it acceptable to you if I only add the blocked vcpus that has
assigned devices to the list? I think that should shorten the
length of the list.
I actually implied this to be the case already, i.e.
- if it's not, this needs to be fixed anyway,
- it's not going to eliminate the concern (just think of a couple of
many-vCPU guests all having devices assigned).
So how about allocating multiple wakeup vectors (says, 16, maybe
we can make this configurable) and multiplex them amongst all the
blocked vCPUs?
For such an approach to be effective, you'd need to know up front
how many vCPU-s you may need to deal with, or allocate vectors
on demand. Plus you'd need to convince us that spending additional
vectors (which we're already short of on certain big systems) is the
only viable solution to the issue (which I don't think it is).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 15/15] tools/xen-access: altp2m testcases
On Thu, 2015-07-09 at 17:52 -0700, Ed White wrote: From: Tamas K Lengyel tleng...@novetta.com Working altp2m test-case. Extended the test tool to support singlestepping to better highlight the core feature of altp2m view switching. Is this the only higher level tool integration which is required for this feature? I was expecting to see at a minimum some libxl/xl integration for enabling/disabling the feature on a per domain basis since AIUI it is a feature which is (or can be) exposed to the guest. From looking at the 00 patch it seems like the ability for a domain to do altp2m on itself is perhaps not included in this iteration of the series, is that correct? Is that functionality disabled by default or simply not present? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 12/15] x86/altp2m: Add altp2mhvm HVM domain parameter.
On Thu, Jul 09, 2015 at 05:52:30PM -0700, Ed White wrote: The altp2mhvm and nestedhvm parameters are mutually exclusive and cannot be set together. Signed-off-by: Ed White edmund.h.wh...@intel.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com for the hypervisor bits. Drop for the hypervisor bits if you happen to resend. For tools: Acked-by: Wei Liu wei.l...@citrix.com I actually discover a minor problem that I should have mentioned in last iteration, but since time is short I will fix that up for you once this series is applied. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 15/15] tools/xen-access: altp2m testcases
On Fri, Jul 10, 2015 at 09:50:25AM +0100, Ian Campbell wrote: On Thu, 2015-07-09 at 17:52 -0700, Ed White wrote: From: Tamas K Lengyel tleng...@novetta.com Working altp2m test-case. Extended the test tool to support singlestepping to better highlight the core feature of altp2m view switching. Is this the only higher level tool integration which is required for this feature? I was expecting to see at a minimum some libxl/xl integration for enabling/disabling the feature on a per domain basis since AIUI it is a feature which is (or can be) exposed to the guest. There is xl/libxl integration in one patch, which is trivial at the moment. As I understand it there will be more libxl patches for this feature, but they are not included in this series at the moment. From looking at the 00 patch it seems like the ability for a domain to do altp2m on itself is perhaps not included in this iteration of the series, is that correct? Is that functionality disabled by default or simply not present? Disable by default in libxl. Wei. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/27] tools/libxl: Introduce libxl__kill()
On 10/07/15 02:34, Yang Hongyang wrote: On 07/10/2015 02:26 AM, Andrew Cooper wrote: as a wrapper to kill(2), and use it in preference to sendig in s/sendig/sendsig/ Oops yes - fixed. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, July 10, 2015 4:50 PM
To: Wu, Feng
Cc: Andrew Cooper; george.dun...@eu.citrix.com; Tian, Kevin; Zhang, Yang Z;
xen-devel@lists.xen.org; k...@xen.org
Subject: Re: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU
is blocked
On 10.07.15 at 09:29, feng...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, July 10, 2015 2:32 PM
On 10.07.15 at 08:21, feng...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, July 09, 2015 3:26 PM
On 09.07.15 at 00:49, kevin.t...@intel.com wrote:
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Wednesday, July 08, 2015 9:09 PM
On 08/07/2015 13:46, Jan Beulich wrote:
On 08.07.15 at 13:00, kevin.t...@intel.com wrote:
@@ -1848,6 +1869,33 @@ static struct hvm_function_table
__initdata
vmx_function_table = {
.enable_msr_exit_interception =
vmx_enable_msr_exit_interception,
};
+/*
+ * Handle VT-d posted-interrupt when VCPU is blocked.
+ */
+static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
+{
+struct arch_vmx_struct *vmx;
+unsigned int cpu = smp_processor_id();
+
+spin_lock(per_cpu(pi_blocked_vcpu_lock, cpu));
+
+/*
+ * FIXME: The length of the list depends on how many
+ * vCPU is current blocked on this specific pCPU.
+ * This may hurt the interrupt latency if the list
+ * grows to too many entries.
+ */
let's go with this linked list first until a real issue is
identified.
This is exactly the way of thinking I dislike when it comes to code
that isn't intended to be experimental only: We shouldn't wait
for problems to surface when we already can see them. I.e. if
there are no plans to deal with this, I'd ask for the feature to be
off by default and be properly marked experimental in the
command line option documentation (so people know to stay
away from it).
And in this specific case, there is no balancing of vcpus across the
pcpus lists.
One can construct a pathological case using pinning and pausing to
get
almost every vcpu on a single pcpu list, and vcpus recieving fewer
interrupts will exasperate the problem by staying on the list for
longer
periods of time.
In that extreme case I believe many contentions in other code paths
will
be much larger than overhead caused by this structure limitation.
Examples?
IMO, the PI feature cannot be declared as done/supported with this
bug
remaining. OTOH, it is fine to be experimental, and disabled by
default
for people who wish to experiment.
Again, I don't expect to see it disabled as experimental. For good
production
environment where vcpus are well balanced and interrupt latency is
sensitive,
linked list should be efficient here. For bad environment like extreme
case
you raised, I don't know whether it really matters to just tune
interrupt
path.
Can you _guarantee_ that everything potentially leading to such a
pathological situation is covered by XSA-77? And even if it is now,
removing elements from the waiver list would become significantly
more difficult if disconnected behavior like this one would need to
be taken into account.
Please understand that history has told us to be rather more careful
than might seem necessary with this: ATS originally having been
enabled by default is one bold example, and the recent flood of MSI
related XSAs is another; I suppose I could find more. All affecting
code originating from Intel, apparently written with only functionality
in mind, while having left out (other than basic) security
considerations.
IOW, with my committer role hat on, the feature is going to be
experimental (and hence default off) unless the issue here gets
addressed. And no, I cannot immediately suggest a good approach,
and with all of the rush before the feature freeze I also can't justify
taking a lot of time to think of options.
Is it acceptable to you if I only add the blocked vcpus that has
assigned devices to the list? I think that should shorten the
length of the list.
I actually implied this to be the case already, i.e.
- if it's not, this needs to be fixed anyway,
- it's not going to eliminate the concern (just think of a couple of
many-vCPU guests all having devices assigned).
So how about allocating multiple wakeup vectors (says, 16, maybe
we can make this configurable) and multiplex them amongst all the
blocked vCPUs?
For such an approach to be effective, you'd need to know up front
how many vCPU-s you may need to deal with, or allocate vectors
on demand. Plus you'd need to convince us that
Re: [Xen-devel] [PATCH v4 01/17] xen/arm: Add bitmap_find_next_zero_area helper function
On 10.07.15 at 09:42, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com bitmap_find_next_zero_area helper function will be used by physical ITS driver. This is imported from linux version? Certainly not any 4.x, i.e. nothing reasonably recent. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v12 0/8] Xen VMware tools support
On Fri, Jul 10, 2015 at 09:40:59AM +0100, Jan Beulich wrote: On 28.06.15 at 01:27, don.sl...@gmail.com wrote: Changes v11 to v12: Rebased on staging. Jan Beulich (xen: Add ring 3 vmware_port support) As there don't seem to be enough convincing arguments for this to be worthwhile, I'm going to drop this... Dropped the 2 ring3 patches. Ian Campbell (tools: Add vmware_hwver support): s/come/comes/ Done I'm not sure this hunk has anything to do with this patch, nor what the semantic difference between the old and new text is supposed to be. Dropped comment change. Ian Campbell (multiple): In v11 this seems to have morphed into only LIBXL_HAVE_LIBXL_VGA_INTERFACE_TYPE_VMWARE being provided, which is clearly not an appropriate umbrella #define. #define LIBXL_HAVE_CREATEINFO_VMWARE 1 Lets just have a single one of these indicating support for vmware, it should be added at the end of the series after all the baseline vmware functionality is in place. I think that means hwver, vga=vmware and this port stuff. Make (tools: Add vga=vmware) no longer independent. Change the #define to LIBXL_HAVE_VMWARE Jan Beulich (xen: Add vmware_port support): Surrounding code avoiding the use of break makes the result look rather inconsistent. Please move this up immediately after the XSM check, or drop the break. Moved it up. George Dunlap (Add IOREQ_TYPE_VMWARE_PORT): Sorry for coming a bit late to this party. On a high level I think this is good, but there doesn't seem to be anything in here in particular that is vmware-specific. Would it make more sense to give this a more generic name, and have it include all of the general-purpose registers? Did not change at this time because QEMU would need changes 1st. George Dunlap (Add xentrace to vmware_port): Do you need to log edi as well? It looks like it's not used. I think it makes sense to indicate that edi can be used and may in the future. And do you need to log all the registers here? It seems like port + regs-_ecx would be enough to tell you why it got ignored. Adjusted to log just port and eax (ecx was NOT tested for). I was actually meaning to apply this (at least until patch 6; I'm not convinced patch 7 makes sense to go in at this point), but noticed that comments by Konrad were still un-addressed. I'm also expecting some re-basing to be needed on top of Paul's emulation re-work. Wei, considering that this had already missed 4.5, would you be okay to take at least first 6 patches (which seem reasonably risk free) after the freeze? Yes. I think it is fine, but please do it as soon as possible, preferably within next week. Wei. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/27] tools/libxl: Introduce libxl__kill()
On Thu, Jul 09, 2015 at 07:26:30PM +0100, Andrew Cooper wrote:
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 19fc425..9147de1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2244,6 +2244,8 @@ struct libxl__async_exec_state {
int libxl__async_exec_start(libxl__async_exec_state *aes);
bool libxl__async_exec_inuse(const libxl__async_exec_state *aes);
+void libxl__kill(libxl__gc *gc, pid_t pid, int sig, const char *what);
_hidden void ...
other than that:
Acked-by: Wei Liu wei.l...@citrix.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 03/15] VMX: implement suppress #VE.
On 10.07.15 at 02:52, edmund.h.wh...@intel.com wrote: @@ -1134,6 +1151,13 @@ int ept_p2m_init(struct p2m_domain *p2m) p2m-flush_hardware_cached_dirty = ept_flush_pml_buffers; } +table = map_domain_page(pagetable_get_pfn(p2m_get_pagetable(p2m))); + +for ( i = 0; i EPT_PAGETABLE_ENTRIES; i++ ) +table[i].suppress_ve = 1; + +unmap_domain_page(table); See my comments/questions on v3. I find it irritating for new patch versions to be sent without addressing comments on the previous one (verbally or by adjusting code). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-pvh-amd
branch xen-unstable xen branch xen-unstable job test-amd64-amd64-xl-pvh-amd test xen-boot Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 4824bdfdabebd4042277461cb3cbefa61c624804 Bug not present: 0c0cbf72cf9f28070cc5d49955b0a00df5c1d114 commit 4824bdfdabebd4042277461cb3cbefa61c624804 Author: Chao Peng chao.p.p...@linux.intel.com Date: Tue Jul 7 15:42:49 2015 +0200 x86: add socket_cpumask Maintain socket_cpumask which contains all the HT and core siblings in the same socket. Signed-off-by: Chao Peng chao.p.p...@linux.intel.com Acked-by: Jan Beulich jbeul...@suse.com For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-pvh-amd.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Searching for failure / basis pass: 59207 fail [host=pinot1] / 59105 ok. Failure / basis pass flights: 59207 / 59105 (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git Latest a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 89483dc2b3eca29b9b104019bda1883c08150dc9 Basis pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c b9dbe33d15a038500bcc3226a3ca31ee215122cd Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#a0768244828d0da096ce957616150220da607be1-a0768244828d0da096ce957616150220da607be1 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#3e2e51ecc1120bd59537ed19b6bc7066511c7e2e-3e2e51ecc1120bd59537ed19b6bc7066511c7e2e git://xenbits.xen.org/staging/qemu-upstream-unstable.git#c4a962ec0c61aa9b860a3635c8424472e6c2cc2c-c4a962ec0c61aa9b860a3635c8424472e6c2cc2c git://xenbits.xen.org/xen.git#b9dbe33d15a038500bcc3226a3ca31ee215122cd-89483dc2b3eca29b9b104019bda1883c08150dc9 + exec + sh -xe + cd /home/osstest/repos/xen + git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /home/osstest/repos/xen + git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* Loaded 1001 nodes in revision graph Searching for test results: 59058 pass irrelevant 59160 fail a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 9a566a83d6374e7425bcb330e03c8ca9b31a0d0b 59105 pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c b9dbe33d15a038500bcc3226a3ca31ee215122cd 59297 pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c b9dbe33d15a038500bcc3226a3ca31ee215122cd 59276 pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 8022b05284dea80e24813d03180788ec7277a0bd 59270 fail a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 9a566a83d6374e7425bcb330e03c8ca9b31a0d0b 59203 pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c b9dbe33d15a038500bcc3226a3ca31ee215122cd 59288 pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c d1370961810d3b1630e0ad5e28e5cfc8dcfe2b9b 59281 fail a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e
Re: [Xen-devel] [PATCH v4 05/15] x86/altp2m: basic data structures and support routines.
On 10.07.15 at 02:52, edmund.h.wh...@intel.com wrote: Add the basic data structures needed to support alternate p2m's and the functions to initialise them and tear them down. Although Intel hardware can handle 512 EPTP's per hardware thread concurrently, only 10 per domain are supported in this patch for performance reasons. The iterator in hap_enable() does need to handle 512, so that is now uint16_t. This change also splits the p2m lock into one lock type for altp2m's and another type for all other p2m's. The purpose of this is to place the altp2m list lock between the types, so the list lock can be acquired whilst holding the host p2m lock. Signed-off-by: Ed White edmund.h.wh...@intel.com Same here - none of my comments on v3 got addressed in any way. Yes, I sent them only yesterday, but still hours before you sent the new version. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 15/15] tools/xen-access: altp2m testcases
On Fri, Jul 10, 2015 at 09:55:52AM +0100, Wei Liu wrote: On Fri, Jul 10, 2015 at 09:50:25AM +0100, Ian Campbell wrote: On Thu, 2015-07-09 at 17:52 -0700, Ed White wrote: From: Tamas K Lengyel tleng...@novetta.com Working altp2m test-case. Extended the test tool to support singlestepping to better highlight the core feature of altp2m view switching. Is this the only higher level tool integration which is required for this feature? I was expecting to see at a minimum some libxl/xl integration for enabling/disabling the feature on a per domain basis since AIUI it is a feature which is (or can be) exposed to the guest. There is xl/libxl integration in one patch, which is trivial at the moment. As I understand it there will be more libxl patches for this feature, but they are not included in this series at the moment. Oh, I could be wrong on this. Maybe these last two patches are the ones he talked about. I will let Ed and Ravi confirm. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v25 00/15] x86/PMU: Xen PMU PV(H) support
Am Freitag 19 Juni 2015, 14:44:31 schrieb Boris Ostrovsky: Changes in v25: * Add extra check for consistency in patch 4 * Replace few returns with 'ret = -E...' (patches 4 and 12) * Clarified commit message in patch 8 * A couple of cosmetic changes in patch 12 (I left AMD multi-counter problem unfixed since what I thought would be sufficient to fix it did not quite work and I don't want to do a partial fix) I did some tests with HVM guests on Intel processors so for the vmx part: Tested-by: Dietmar Hahn dietmar.h...@ts.fujitsu.com Many Thanks! Dietmar. -- Company details: http://ts.fujitsu.com/imprint.html ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.4-testing test] 59289: tolerable FAIL - PUSHED
flight 59289 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/59289/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-multivcpu 11 guest-start fail like 58953 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 58953 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 58960 test-amd64-i386-libvirt 11 guest-start fail like 58975 test-amd64-amd64-libvirt 11 guest-start fail like 58975 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a build-amd64-rumpuserxen 6 xen-buildfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-armhf-armhf-libvirt 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 36c53c22cd72f742cb42891354e82e9532436fcf baseline version: xen 6c1cb3dba4ff97dd40909670755f24fcdf903012 Last test of basis58975 2015-06-29 19:41:08 Z 10 days Testing same since59289 2015-07-09 12:40:11 Z0 days1 attempts People who touched revisions under test: Jan Beulich jbeul...@suse.com jobs: build-amd64-xend pass build-i386-xend pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 blocked test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu
[Xen-devel] [PATCH v4 04/17] xen/arm: ITS: Add helper functions to manage its_devices
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Helper functions to manage its devices using RB-tree
are introduced in physical ITS driver.
This is global list of all the devices.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: - Remove passing of root node as parameter
- Declare prototype in header file
- Rename find_its_device to its_find_device
---
xen/arch/arm/gic-v3-its.c | 49 +
xen/include/asm-arm/gic-its.h | 13 +++
2 files changed, 62 insertions(+)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 60ab646..b421a6f 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -90,6 +90,7 @@ struct its_node {
static LIST_HEAD(its_nodes);
static DEFINE_SPINLOCK(its_lock);
static struct rdist_prop *gic_rdists;
+static struct rb_root rb_its_dev;
#define gic_data_rdist()(per_cpu(rdist, smp_processor_id()))
@@ -101,6 +102,53 @@ void dump_cmd(its_cmd_block *cmd)
}
#endif
+/* RB-tree helpers for its_device */
+struct its_device *its_find_device(u32 devid)
+{
+struct rb_node *node = rb_its_dev.rb_node;
+
+while ( node )
+{
+struct its_device *dev;
+
+dev = container_of(node, struct its_device, node);
+if ( devid dev-device_id )
+node = node-rb_left;
+else if ( devid dev-device_id )
+node = node-rb_right;
+else
+return dev;
+}
+
+return NULL;
+}
+
+int its_insert_device(struct its_device *dev)
+{
+struct rb_node **new, *parent;
+
+new = rb_its_dev.rb_node;
+parent = NULL;
+while ( *new )
+{
+struct its_device *this;
+
+this = container_of(*new, struct its_device, node);
+parent = *new;
+if ( dev-device_id this-device_id )
+new = ((*new)-rb_left);
+else if ( dev-device_id this-device_id )
+new = ((*new)-rb_right);
+else
+return -EEXIST;
+}
+
+rb_link_node(dev-node, parent, new);
+rb_insert_color(dev-node, rb_its_dev);
+
+return 0;
+}
+
#define ITS_CMD_QUEUE_SZSZ_64K
#define ITS_CMD_QUEUE_NR_ENTRIES(ITS_CMD_QUEUE_SZ / sizeof(its_cmd_block))
@@ -811,6 +859,7 @@ static int its_probe(struct dt_device_node *node)
list_add(its-entry, its_nodes);
spin_unlock(its_lock);
+rb_its_dev = RB_ROOT;
return 0;
out_free_tables:
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index d24b039..b5e09bd 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -19,6 +19,7 @@
#define __ASM_ARM_GIC_ITS_H__
#include asm/gic_v3_defs.h
+#include xen/rbtree.h
/*
* Collection structure - just an ID, and a redistributor address to
@@ -156,9 +157,21 @@ typedef union {
} sync;
} its_cmd_block;
+/*
+ * The ITS view of a device.
+ */
+struct its_device {
+/* Physical Device id */
+u32 device_id;
+/* RB-tree entry */
+struct rb_node node;
+};
+
int its_lpi_init(u32 id_bits);
int its_init(struct rdist_prop *rdists);
int its_cpu_init(void);
+struct its_device *its_find_device(u32 devid);
+int its_insert_device(struct its_device *dev);
#endif /* __ASM_ARM_GIC_ITS_H__ */
/*
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 16/17] xen/arm: ITS: Generate ITS node for Dom0
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Parse host dt and generate ITS node for Dom0.
ITS node resides inside GIC node so when GIC node
is encountered look for ITS node.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: - Generate only one ITS node for Dom0
- Replace msi-parent references to single its phandle
---
xen/arch/arm/domain_build.c | 78 +
xen/arch/arm/gic-v3-its.c | 57 ++
xen/include/asm-arm/gic-its.h |2 ++
3 files changed, 137 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e9cb8a9..5c62437 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -20,6 +20,7 @@
#include asm/cpufeature.h
#include asm/gic.h
+#include asm/gic-its.h
#include xen/irq.h
#include kernel.h
@@ -61,6 +62,9 @@ custom_param(dom0_mem, parse_dom0_mem);
*/
#define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
+#ifdef CONFIG_ARM_64
+static fdt32_t its_phandle;
+#endif
struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
{
if ( opt_dom0_max_vcpus == 0 )
@@ -468,6 +472,18 @@ static int write_properties(struct domain *d, struct
kernel_info *kinfo,
continue;
}
+#ifdef CONFIG_ARM_64
+/*
+ * Replace all msi-parent phandle references to single ITS node
+ * generated for Dom0
+ */
+if ( dt_property_name_is_equal(prop, msi-parent) )
+{
+fdt_property(kinfo-fdt, prop-name, (void *)its_phandle,
+ sizeof(its_phandle));
+continue;
+}
+#endif
res = fdt_property(kinfo-fdt, prop-name, prop_data, prop_len);
xfree(new_data);
@@ -803,6 +819,38 @@ static int make_cpus_node(const struct domain *d, void
*fdt,
return res;
}
+#ifdef CONFIG_ARM_64
+static int make_its_node(const struct domain *d, void *fdt,
+ const struct dt_device_node *node)
+{
+int res = 0;
+
+DPRINT(Create GIC ITS node\n);
+
+res = its_make_dt_node(d, node, fdt);
+if ( res )
+return res;
+
+/*
+ * The value of the property phandle in the property interrupts
+ * to know on which interrupt controller the interrupt is wired.
+ */
+if ( node-phandle )
+{
+DPRINT( Set phandle = 0x%x\n, node-phandle);
+res = fdt_property_cell(fdt, phandle, node-phandle);
+if ( res )
+return res;
+}
+
+its_phandle = cpu_to_fdt32(node-phandle);
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+#endif
+
static int make_gic_node(const struct domain *d, void *fdt,
const struct dt_device_node *node)
{
@@ -1119,6 +1167,14 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
DT_MATCH_TIMER,
{ /* sentinel */ },
};
+#ifdef CONFIG_ARM_64
+static const struct dt_device_match gits_matches[] __initconst =
+{
+DT_MATCH_GIC_ITS,
+{ /* sentinel */ },
+};
+struct dt_device_node *gic_child;
+#endif
struct dt_device_node *child;
int res;
const char *name;
@@ -1143,7 +1199,29 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
/* Replace these nodes with our own. Note that the original may be
* used_by DOMID_XEN so this check comes first. */
if ( device_get_class(node) == DEVICE_GIC )
+{
+#ifdef CONFIG_ARM_64
+if ( !make_gic_node(d, kinfo-fdt, node) )
+{
+res = 0;
+dt_for_each_child_node(node, gic_child)
+{
+if ( gic_child != NULL )
+{
+if ( dt_match_node(gits_matches, gic_child) )
+{
+res = make_its_node(d, kinfo-fdt, gic_child);
+break;
+}
+}
+}
+return res;
+}
+return 0;
+#else
return make_gic_node(d, kinfo-fdt, node);
+#endif
+}
if ( dt_match_node(timer_matches, node) )
return make_timer_node(d, kinfo-fdt, node);
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index b159b0b..4193624 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -27,6 +27,8 @@
#include xen/sched.h
#include xen/errno.h
#include xen/delay.h
+#include xen/device_tree.h
+#include xen/libfdt/libfdt.h
#include xen/list.h
#include xen/sizes.h
#include xen/vmap.h
@@ -1227,6 +1229,61 @@ static void its_cpu_init_collection(void)
spin_unlock(its_lock);
}
+int its_make_dt_node(const struct domain *d,
+ const struct dt_device_node *node, void *fdt)
+{
+struct its_node *its;
+const struct dt_device_node *gic;
+const void *compatible = NULL;
+u32 len;
+__be32 *new_cells, *tmp;
+int res = 0;
+
+/* Will pass only first ITS node info */
+
[Xen-devel] [PATCH v4 15/17] xen/arm: ITS: Map ITS translation space
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
ITS translation space contains GITS_TRANSLATOR
register which is written by device to raise
LPI. This space needs to mapped to every domain
address space for all physical ITS available,
so that device can access GITS_TRANSLATOR
register using SMMU.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/vgic-v3-its.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 74e6ee7..301f065 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1082,6 +1082,35 @@ static const struct mmio_handler_ops
vgic_gits_mmio_handler = {
.write_handler = vgic_v3_gits_mmio_write,
};
+/*
+ * Map the 64K ITS translation space in guest.
+ * This is required purely for device smmu writes.
+*/
+
+static int vits_map_translation_space(struct domain *d)
+{
+uint64_t addr, size;
+int ret;
+
+addr = d-arch.vits-gits_base + SZ_64K;
+size = SZ_64K;
+
+ret = map_mmio_regions(d,
+ paddr_to_pfn(addr PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr PAGE_MASK));
+
+ if ( ret )
+ {
+ dprintk(XENLOG_G_ERR, vITS: Unable to map to dom%d access to
+ 0x%PRIx64 - 0x%PRIx64\n,
+ d-domain_id,
+ addr PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ }
+
+return ret;
+}
+
int vits_domain_init(struct domain *d)
{
int i;
@@ -1112,7 +1141,7 @@ int vits_domain_init(struct domain *d)
d-arch.vits-gits_base,
SZ_64K);
-return 0;
+return vits_map_translation_space(d);
}
void vgic_its_init(void)
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about seperating request and response ring in PV network
On Fri, Jul 10, 2015 at 09:41:10AM +0800, openlui wrote: Hi, all: I am trying to improve the performance of netfront/netback, and I found that there were some discussion about PV network performance improvement in devel mailing list ([1]). The proposals mentioned in [1] are helpful, such as multipage ring, multiqueue, etc, and some of them have already merged into upstream. However, I am wondering if we have already used multipage ring, why seperate request and response ring listed in [1] is also helpful for performance improvement? I have read the implementation of vmxnet3 driver, it does have separated request and response rings, but I can not understand what the advantage of this method is. Correction: network driver doesn't use multi-page ring and I don't think we have plan to do that. That email contains mostly brainstormed ideas that we thought might help improve performance. Some ideas were solid (and upstreamed), some were not. I implemented several prototype back in the day but I couldn't remember what I did. As for separating rings, there are two possibilities: 1) I didn't implement that; 2) I implemented that but there was no visible improvement. So there is no such feature in upstream driver. Wei. Thanks. [1] http://lists.xen.org/archives/html/xen-devel/2013-05/msg01904.html Best Regards Lui ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU is blocked
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, July 10, 2015 2:32 PM
To: Wu, Feng
Cc: Andrew Cooper; george.dun...@eu.citrix.com; Tian, Kevin; Zhang, Yang Z;
xen-devel@lists.xen.org; k...@xen.org
Subject: RE: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when vCPU
is blocked
On 10.07.15 at 08:21, feng...@intel.com wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, July 09, 2015 3:26 PM
To: Wu, Feng; Tian, Kevin
Cc: Andrew Cooper; george.dun...@eu.citrix.com; Zhang, Yang Z;
xen-devel@lists.xen.org; k...@xen.org
Subject: RE: [Xen-devel] [v3 12/15] vmx: posted-interrupt handling when
vCPU
is blocked
On 09.07.15 at 00:49, kevin.t...@intel.com wrote:
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Wednesday, July 08, 2015 9:09 PM
On 08/07/2015 13:46, Jan Beulich wrote:
On 08.07.15 at 13:00, kevin.t...@intel.com wrote:
@@ -1848,6 +1869,33 @@ static struct hvm_function_table
__initdata
vmx_function_table = {
.enable_msr_exit_interception =
vmx_enable_msr_exit_interception,
};
+/*
+ * Handle VT-d posted-interrupt when VCPU is blocked.
+ */
+static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
+{
+struct arch_vmx_struct *vmx;
+unsigned int cpu = smp_processor_id();
+
+spin_lock(per_cpu(pi_blocked_vcpu_lock, cpu));
+
+/*
+ * FIXME: The length of the list depends on how many
+ * vCPU is current blocked on this specific pCPU.
+ * This may hurt the interrupt latency if the list
+ * grows to too many entries.
+ */
let's go with this linked list first until a real issue is
identified.
This is exactly the way of thinking I dislike when it comes to code
that isn't intended to be experimental only: We shouldn't wait
for problems to surface when we already can see them. I.e. if
there are no plans to deal with this, I'd ask for the feature to be
off by default and be properly marked experimental in the
command line option documentation (so people know to stay
away from it).
And in this specific case, there is no balancing of vcpus across the
pcpus lists.
One can construct a pathological case using pinning and pausing to get
almost every vcpu on a single pcpu list, and vcpus recieving fewer
interrupts will exasperate the problem by staying on the list for longer
periods of time.
In that extreme case I believe many contentions in other code paths will
be much larger than overhead caused by this structure limitation.
Examples?
IMO, the PI feature cannot be declared as done/supported with this bug
remaining. OTOH, it is fine to be experimental, and disabled by default
for people who wish to experiment.
Again, I don't expect to see it disabled as experimental. For good
production
environment where vcpus are well balanced and interrupt latency is
sensitive,
linked list should be efficient here. For bad environment like extreme
case
you raised, I don't know whether it really matters to just tune interrupt
path.
Can you _guarantee_ that everything potentially leading to such a
pathological situation is covered by XSA-77? And even if it is now,
removing elements from the waiver list would become significantly
more difficult if disconnected behavior like this one would need to
be taken into account.
Please understand that history has told us to be rather more careful
than might seem necessary with this: ATS originally having been
enabled by default is one bold example, and the recent flood of MSI
related XSAs is another; I suppose I could find more. All affecting
code originating from Intel, apparently written with only functionality
in mind, while having left out (other than basic) security considerations.
IOW, with my committer role hat on, the feature is going to be
experimental (and hence default off) unless the issue here gets
addressed. And no, I cannot immediately suggest a good approach,
and with all of the rush before the feature freeze I also can't justify
taking a lot of time to think of options.
Is it acceptable to you if I only add the blocked vcpus that has
assigned devices to the list? I think that should shorten the
length of the list.
I actually implied this to be the case already, i.e.
- if it's not, this needs to be fixed anyway,
- it's not going to eliminate the concern (just think of a couple of
many-vCPU guests all having devices assigned).
So how about allocating multiple wakeup vectors (says, 16, maybe
we can make this configurable) and multiplex them amongst all the
blocked vCPUs?
Thanks,
Feng
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 14/17] xen/arm: ITS: Add domain specific ITS initialization
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add Domain and vcpu specific ITS initialization
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3-its.c | 17
xen/arch/arm/setup.c |4 +++-
xen/arch/arm/vgic-v3-its.c| 39 +
xen/arch/arm/vgic-v3.c|3 +++
xen/include/asm-arm/gic-its.h |2 ++
xen/include/asm-arm/gic_v3_defs.h |2 ++
xen/include/asm-arm/vgic.h|1 +
7 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 5e6c7f2..b159b0b 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -1256,6 +1256,23 @@ static int its_force_quiescent(void __iomem *base)
}
}
+void its_domain_init(struct domain *d)
+{
+struct its_node *its;
+
+if ( is_hardware_domain(d) )
+{
+/*
+ * Only one virtual ITS is provided to domain.
+ * Assign first physical ITS address to Dom0 virtual ITS.
+ */
+its = list_first_entry(its_nodes, struct its_node, entry);
+d-arch.vits-gits_base = its-phys_base;
+d-arch.vits-gits_size = its-phys_size;
+}
+/* TODO: DomU */
+}
+
static int its_probe(struct dt_device_node *node)
{
paddr_t its_addr, its_size;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 06f8e54..3bd1f2e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -776,7 +776,9 @@ void __init start_xen(unsigned long boot_phys_offset,
init_xen_time();
gic_init();
-
+#ifdef CONFIG_ARM_64
+vgic_its_init();
+#endif
p2m_vmid_allocator_init();
softirq_init();
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 4649b07..74e6ee7 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1082,6 +1082,45 @@ static const struct mmio_handler_ops
vgic_gits_mmio_handler = {
.write_handler = vgic_v3_gits_mmio_write,
};
+int vits_domain_init(struct domain *d)
+{
+int i;
+
+d-arch.vits = xzalloc(struct vgic_its);
+if ( !d-arch.vits )
+return -ENOMEM;
+
+spin_lock_init(d-arch.vits-lock);
+spin_lock_init(d-arch.vits-dev_lock);
+spin_lock_init(d-arch.vits-prop_lock);
+
+d-arch.vits-collections = xzalloc_array(struct its_collection,
+ nr_cpu_ids);
+if ( !d-arch.vits-collections )
+return -ENOMEM;
+
+for ( i = 0; i nr_cpu_ids; i++ )
+d-arch.vits-collections[i].target_address = ~0UL;
+
+d-arch.vits-baser = GITS_BASER_INIT_VAL;
+d-arch.vits-dev_root = RB_ROOT;
+
+spin_lock_init(d-arch.vits-lock);
+
+its_domain_init(d);
+register_mmio_handler(d, vgic_gits_mmio_handler,
+ d-arch.vits-gits_base,
+ SZ_64K);
+
+return 0;
+}
+
+void vgic_its_init(void)
+{
+if ( gic_lpi_supported() )
+its_lpi_init(gic_nr_id_bits());
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4e14439..79dbfc4 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1217,6 +1217,9 @@ static int vgic_v3_domain_init(struct domain *d)
d-arch.vgic.ctlr = VGICD_CTLR_DEFAULT;
+if ( gic_lpi_supported() )
+vits_domain_init(d);
+
return 0;
}
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index fbed905..cbe7596 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -265,6 +265,8 @@ struct its_device *its_find_device(u32 devid);
int its_insert_device(struct its_device *dev);
int its_add_device(u32 devid);
int its_assign_device(struct domain *d, u32 vdevid, u32 pdevid);
+void its_domain_init(struct domain *d);
+int vits_domain_init(struct domain *d);
int vits_set_vitt_entry(struct domain *d, uint32_t devid,
uint32_t event, struct vitt *entry);
int vits_get_vitt_entry(struct domain *d, uint32_t devid,
diff --git a/xen/include/asm-arm/gic_v3_defs.h
b/xen/include/asm-arm/gic_v3_defs.h
index 368ebb3..24ef547 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -243,6 +243,8 @@
#define GITS_BASER_TYPE_RESERVED5 5
#define GITS_BASER_TYPE_RESERVED6 6
#define GITS_BASER_TYPE_RESERVED7 7
+#define GITS_BASER_INIT_VAL ((1UL GITS_BASER_TYPE_SHIFT) | \
+ (0x7UL
GITS_BASER_ENTRY_SIZE_SHIFT))
/* GITS_PIDRn register values for ARM implementations */
#define GITS_PIDR0_VAL (0x94)
#define GITS_PIDR1_VAL (0xb4)
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index f8928ab..4509e9a 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -178,6 +178,7 @@ enum gic_sgi_mode;
#define vgic_num_irqs(d)((d)-arch.vgic.nr_spis
[Xen-devel] [PATCH v4 11/17] xen/arm: ITS: Add GICR register emulation
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Emulate LPI related changes to GICR registers
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: - Added LPI configuration table emulation
- Rename function inline with vits
- Copied guest lpi configuration table to xen
---
xen/arch/arm/gic-v3.c | 15
xen/arch/arm/gic.c| 10 +++
xen/arch/arm/vgic-v3-its.c| 165 +
xen/arch/arm/vgic-v3.c| 85 +--
xen/arch/arm/vgic.c |4 +
xen/include/asm-arm/domain.h |1 +
xen/include/asm-arm/gic-its.h | 11 +++
xen/include/asm-arm/gic.h |9 ++
xen/include/asm-arm/gic_v3_defs.h |3 +
9 files changed, 295 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 904fe57..e6004d2 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -677,6 +677,11 @@ static int __init gicv3_populate_rdist(void)
return -ENODEV;
}
+static int gicv3_dist_supports_lpis(void)
+{
+return readl_relaxed(GICD + GICD_TYPER) GICD_TYPER_LPIS_SUPPORTED;
+}
+
static int __cpuinit gicv3_cpu_init(void)
{
int i;
@@ -1293,10 +1298,20 @@ static int __init gicv3_init(void)
gicv3.rdist_regions[0].size, gicv3.rdist_regions[0].map_base,
gicv3_info.maintenance_irq);
+reg = readl_relaxed(GICD + GICD_TYPER);
+
+gicv3.rdist_data.id_bits = ((reg 19) 0x1f) + 1;
+gicv3_info.nr_id_bits = gicv3.rdist_data.id_bits;
+
spin_lock_init(gicv3.lock);
spin_lock(gicv3.lock);
+if ( gicv3_dist_supports_lpis() )
+gicv3_info.lpi_supported = 1;
+else
+gicv3_info.lpi_supported = 0;
+
gicv3_dist_init();
res = gicv3_cpu_init();
gicv3_hyp_init();
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4f3801b..3ebadcf 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -73,6 +73,16 @@ unsigned int gic_number_lines(void)
return gic_hw_ops-info-nr_lines;
}
+unsigned int gic_nr_id_bits(void)
+{
+return gic_hw_ops-info-nr_id_bits;
+}
+
+bool_t gic_lpi_supported(void)
+{
+return gic_hw_ops-info-lpi_supported;
+}
+
void gic_save_state(struct vcpu *v)
{
ASSERT(!local_irq_is_enabled());
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index abf60e2..bbcc7bb 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -49,6 +49,36 @@ static void dump_cmd(its_cmd_block *cmd)
}
#endif
+static void vits_disable_lpi(struct vcpu *v, uint32_t vlpi)
+{
+struct pending_irq *p;
+
+p = irq_to_pending(v, vlpi);
+clear_bit(GIC_IRQ_GUEST_ENABLED, p-status);
+gic_remove_from_queues(v, vlpi);
+}
+
+static void vits_enable_lpi(struct vcpu *v, uint32_t vlpi, uint8_t priority)
+{
+struct pending_irq *p;
+unsigned long flags;
+
+/* Get plpi for the given vlpi */
+p = irq_to_pending(v, vlpi);
+
+set_bit(GIC_IRQ_GUEST_ENABLED, p-status);
+
+spin_lock_irqsave(v-arch.vgic.lock, flags);
+
+/*XXX: raise on right vcpu */
+if ( !list_empty(p-inflight)
+ !test_bit(GIC_IRQ_GUEST_VISIBLE, p-status) )
+gic_raise_guest_irq(v, irq_to_virq(p-desc), p-priority);
+
+spin_unlock_irqrestore(v-arch.vgic.lock, flags);
+}
+
+/* ITS device table helper functions */
static int vits_entry(struct domain *d, paddr_t entry, void *addr,
uint32_t size, bool_t set)
{
@@ -595,6 +625,141 @@ err:
return 0;
}
+static int vgic_v3_gits_lpi_mmio_read(struct vcpu *v, mmio_info_t *info)
+{
+uint32_t offset;
+struct hsr_dabt dabt = info-dabt;
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+register_t *r = select_user_reg(regs, dabt.reg);
+
+offset = info-gpa -
+ (v-domain-arch.vits-propbase BIT_48_12_MASK);
+
+if ( offset v-domain-arch.vits-prop_size )
+{
+DPRINTK(%pv: vITS: LPI Table read offset 0x%x\n, v, offset);
+spin_lock(v-domain-arch.vits-prop_lock);
+*r = *((u8*)v-domain-arch.vits-prop_page + offset);
+spin_unlock(v-domain-arch.vits-prop_lock);
+return 1;
+}
+else
+dprintk(XENLOG_G_ERR, %pv: vITS: LPI Table read with wrong offset
0x%x\n,
+v, offset);
+
+return 0;
+}
+
+static int vgic_v3_gits_lpi_mmio_write(struct vcpu *v, mmio_info_t *info)
+{
+uint32_t offset;
+uint32_t vid;
+uint8_t cfg, *p;
+bool_t enable;
+struct hsr_dabt dabt = info-dabt;
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+register_t *r = select_user_reg(regs, dabt.reg);
+
+offset = info-gpa -
+ (v-domain-arch.vits-propbase BIT_48_12_MASK);
+
+vid = offset + NR_GIC_LPI;
+if ( offset v-domain-arch.vits-prop_size )
+{
+DPRINTK(%pv: vITS: LPI Table write offset 0x%x\n, v, offset);
+
+spin_lock(v-domain-arch.vits-prop_lock);
+p =
[Xen-devel] [PATCH v4 07/17] xen/arm: ITS: Add virtual ITS commands support
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add Virtual ITS command processing support to Virtual ITS driver
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: - Use helper function to read from command queue
- Add MOVALL
- Removed check for entry in device in domain RB-tree
---
xen/arch/arm/gic-v3-its.c |7 +
xen/arch/arm/vgic-v3-its.c| 391 +
xen/include/asm-arm/gic-its.h | 19 ++
xen/include/asm-arm/gic.h |1 +
4 files changed, 418 insertions(+)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index b98d396..9161053 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -91,6 +91,7 @@ static LIST_HEAD(its_nodes);
static DEFINE_SPINLOCK(its_lock);
static struct rdist_prop *gic_rdists;
static struct rb_root rb_its_dev;
+static struct gic_its_info its_data;
#define gic_data_rdist()(per_cpu(rdist, smp_processor_id()))
@@ -102,6 +103,11 @@ void dump_cmd(its_cmd_block *cmd)
}
#endif
+u32 its_get_nr_events(void)
+{
+return (1 its_data.id_bits);
+}
+
/* RB-tree helpers for its_device */
struct its_device *its_find_device(u32 devid)
{
@@ -940,6 +946,7 @@ static int its_probe(struct dt_device_node *node)
its-phys_size = its_size;
typer = readl_relaxed(its_base + GITS_TYPER);
its-ite_size = ((typer 4) 0xf) + 1;
+its_data.id_bits = GITS_TYPER_IDBITS(typer);
its-cmd_base = xzalloc_bytes(ITS_CMD_QUEUE_SZ);
if ( !its-cmd_base )
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index c63f478..af2bacd 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -31,6 +31,22 @@
#include asm/gic-its.h
#include xen/log2.h
+#define DEBUG_ITS
+
+#ifdef DEBUG_ITS
+# define DPRINTK(fmt, args...) dprintk(XENLOG_DEBUG, fmt, ##args)
+#else
+# define DPRINTK(fmt, args...) do {} while ( 0 )
+#endif
+
+#ifdef DEBUG_ITS
+static void dump_cmd(its_cmd_block *cmd)
+{
+printk(CMD[0] = 0x%lx CMD[1] = 0x%lx CMD[2] = 0x%lx CMD[3] = 0x%lx\n,
+ cmd-bits[0], cmd-bits[1], cmd-bits[2], cmd-bits[3]);
+}
+#endif
+
static int vits_entry(struct domain *d, paddr_t entry, void *addr,
uint32_t size, bool_t set)
{
@@ -202,6 +218,381 @@ void vits_remove_device(struct rb_root *root, struct
vits_device *dev)
rb_erase(dev-node, root);
}
+static int vgic_its_process_sync(struct vcpu *v, struct vgic_its *vits,
+ its_cmd_block *virt_cmd)
+{
+DPRINTK(%pv: vITS: SYNC: ta 0x%x \n, v, virt_cmd-sync.ta);
+
+return 0;
+}
+
+static int vgic_its_process_mapvi(struct vcpu *v, struct vgic_its *vits,
+ its_cmd_block *virt_cmd)
+{
+struct vitt entry;
+struct domain *d = v-domain;
+uint8_t vcol_id, cmd;
+uint32_t vid, dev_id, event;
+
+vcol_id = virt_cmd-mapvi.col;
+vid = virt_cmd-mapvi.phy_id;
+cmd = virt_cmd-mapvi.cmd;
+dev_id = virt_cmd-mapvi.devid;
+
+DPRINTK(%pv: vITS: MAPVI: dev_id 0x%x vcol_id %d vid %d \n,
+ v, dev_id, vcol_id, vid);
+
+if ( vcol_id (d-max_vcpus + 1) || vid its_get_nr_events() )
+return -EINVAL;
+
+entry.valid = true;
+entry.vcollection = vcol_id;
+entry.vlpi = vid;
+
+if ( cmd == GITS_CMD_MAPI )
+vits_set_vitt_entry(d, dev_id, vid, entry);
+else
+{
+event = virt_cmd-mapvi.event;
+vits_set_vitt_entry(d, dev_id, event, entry);
+}
+
+return 0;
+}
+
+static int vgic_its_process_movi(struct vcpu *v, struct vgic_its *vits,
+ its_cmd_block *virt_cmd)
+{
+struct vitt entry;
+struct domain *d = v-domain;
+uint32_t dev_id, event;
+uint8_t vcol_id;
+
+vcol_id = virt_cmd-movi.col;
+event = virt_cmd-movi.event;
+dev_id = virt_cmd-movi.devid;
+
+DPRINTK(%pv vITS: MOVI: dev_id 0x%x vcol_id %d event %d\n,
+v, dev_id, vcol_id, event);
+
+if ( vcol_id (d-max_vcpus + 1) || event its_get_nr_events() )
+return -EINVAL;
+
+if ( vits_get_vitt_entry(d, dev_id, event, entry) )
+return -EINVAL;
+
+entry.vcollection = vcol_id;
+
+if ( vits_set_vitt_entry(d, dev_id, event, entry) )
+return -EINVAL;
+
+return 0;
+}
+
+static int vgic_its_process_movall(struct vcpu *v, struct vgic_its *vits,
+ its_cmd_block *virt_cmd)
+{
+return 0;
+}
+
+static int vgic_its_process_discard(struct vcpu *v, struct vgic_its *vits,
+its_cmd_block *virt_cmd)
+{
+struct vitt entry;
+struct domain *d = v-domain;
+uint32_t event, dev_id;
+
+event = virt_cmd-discard.event;
+dev_id = virt_cmd-discard.devid;
+
+DPRINTK(%pv vITS: DISCARD: dev_id 0x%x id %d\n,
+v, virt_cmd-discard.devid, event);
+
+if ( event its_get_nr_events() )
+return -EINVAL;
+
+if ( vits_get_vitt_entry(d, dev_id,
[Xen-devel] [PATCH v4 10/17] xen/arm: ITS: Enable physical and virtual ITS driver compilation
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com Compilation is delayed till this patch. From now on functions in physical ITS and virtual ITS driver are required. So enable compilation Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com --- xen/arch/arm/Makefile |2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index 935999e..048a762 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -14,6 +14,7 @@ obj-y += domain_build.o obj-y += gic.o gic-v2.o obj-$(CONFIG_ARM_32) += gic-hip04.o obj-$(CONFIG_ARM_64) += gic-v3.o +obj-$(CONFIG_ARM_64) += gic-v3-its.o obj-y += io.o obj-y += irq.o obj-y += kernel.o @@ -32,6 +33,7 @@ obj-y += shutdown.o obj-y += traps.o obj-y += vgic.o vgic-v2.o obj-$(CONFIG_ARM_64) += vgic-v3.o +obj-$(CONFIG_ARM_64) += vgic-v3-its.o obj-y += vtimer.o obj-y += vuart.o obj-y += hvm.o -- 1.7.9.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 03/17] xen/arm: ITS: Port ITS driver to Xen
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
The linux driver is based on 4.1 with below commit id
3ad2a5f57656a14d964b673a5a0e4ab0e583c870
Only following code from Linux ITS driver is ported
and compiled
- LPI initialization
- ITS configuration code
- Physical command queue management
- ITS command building
Also redistributor information is split into rdist and
rdist_prop structures.
The rdist_prop struct holds the redistributor common
information for all re-distributor and rdist struct
holds the per-cpu specific information.
This per-cpu rdist is defined as global and shared with
physical ITS driver.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: Major changes
- Redistributor refactoring patch is merged
- Fixed comments from v3 related to coding style and
removing duplicate code.
- Target address is stored from bits[48:16] to avoid
shifting of target address while building ITS commands
- Removed non-static functions
- Removed usage of command builder functions
- Changed its_cmd_block union to include mix of bit and unsigned
variable types to define ITS command structure
v3:
- Only required changes from Linux ITS driver is ported
- Xen coding style is followed.
---
xen/arch/arm/gic-v3-its.c | 882 +
xen/arch/arm/gic-v3.c | 15 +-
xen/include/asm-arm/gic-its.h | 171 +++
xen/include/asm-arm/gic.h |1 +
xen/include/asm-arm/gic_v3_defs.h | 117 -
5 files changed, 1179 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
new file mode 100644
index 000..60ab646
--- /dev/null
+++ b/xen/arch/arm/gic-v3-its.c
@@ -0,0 +1,882 @@
+/*
+ * Copyright (C) 2013, 2014 ARM Limited, All Rights Reserved.
+ * Author: Marc Zyngier marc.zyng...@arm.com
+ *
+ * Xen changes:
+ * Vijaya Kumar K vijaya.ku...@caviumnetworks.com
+ * Copyright (C) 2014, 2015 Cavium Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include xen/config.h
+#include xen/bitops.h
+#include xen/init.h
+#include xen/mm.h
+#include xen/irq.h
+#include xen/sched.h
+#include xen/errno.h
+#include xen/delay.h
+#include xen/list.h
+#include xen/sizes.h
+#include xen/vmap.h
+#include asm/p2m.h
+#include asm/domain.h
+#include asm/io.h
+#include asm/device.h
+#include asm/gic.h
+#include asm/gic_v3_defs.h
+#include asm/gic-its.h
+#include xen/log2.h
+
+#define its_print(lvl, fmt, ...) \
+printk(GIC-ITS: fmt, ## __VA_ARGS__)
+
+#define its_err(fmt, ...) its_print(XENLOG_ERR, fmt, ## __VA_ARGS__)
+
+#define its_dbg(fmt, ...) \
+its_print(XENLOG_DEBUG, fmt, ## __VA_ARGS__)
+
+#define its_info(fmt, ...)\
+its_print(XENLOG_INFO, fmt, ## __VA_ARGS__)
+
+#define its_warn(fmt, ...)\
+its_print(XENLOG_WARNING, fmt, ## __VA_ARGS__)
+
+//#define DEBUG_GIC_ITS
+
+#ifdef DEBUG_GIC_ITS
+# define DPRINTK(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
+#else
+# define DPRINTK(fmt, args...) do {} while ( 0 )
+#endif
+
+#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1 0)
+#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 0)
+
+/*
+ * The ITS structure - contains most of the infrastructure, with the
+ * msi_controller, the command queue, the collections, and the list of
+ * devices writing to it.
+ */
+struct its_node {
+spinlock_t lock;
+struct list_headentry;
+void __iomem*base;
+unsigned long phys_base;
+unsigned long phys_size;
+its_cmd_block *cmd_base;
+its_cmd_block *cmd_write;
+void*tables[GITS_BASER_NR_REGS];
+u32 order[GITS_BASER_NR_REGS];
+struct its_collection *collections;
+u64 flags;
+u32 ite_size;
+struct dt_device_node *dt_node;
+};
+
+#define ITS_ITT_ALIGNSZ_256
+
+static LIST_HEAD(its_nodes);
+static DEFINE_SPINLOCK(its_lock);
+static struct rdist_prop *gic_rdists;
+
+#define gic_data_rdist()(per_cpu(rdist, smp_processor_id()))
+
+#ifdef DEBUG_GIC_ITS
+void dump_cmd(its_cmd_block *cmd)
+{
+printk(ITS: Phys_cmd CMD[0] = 0x%lx CMD[1] = 0x%lx CMD[2] = 0x%lx CMD[3]
= 0x%lx\n,
+ cmd-bits[0], cmd-bits[1],
[Xen-devel] [PATCH v4 06/17] xen/arm: ITS: Add virtual ITS driver
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
This patch introduces virtual ITS driver with following
functionality
- Introduces helper functions to manage device table and
ITT table in guest memory
- Helper function to handle virtual ITS devices assigned
to domain
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: - Rename functions {find,remove,insert}_vits_* to
vits_{find,remove,insert}.
- Add common helper function to map and read/write dt
or vitt table entry.
- Removed unused code
---
xen/arch/arm/vgic-v3-its.c| 212 +
xen/include/asm-arm/domain.h |4 +
xen/include/asm-arm/gic-its.h | 45 -
3 files changed, 260 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
new file mode 100644
index 000..c63f478
--- /dev/null
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (C) 2015 Cavium Inc.
+ * Vijaya Kumar K vijaya.ku...@caviumnetworks.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include xen/bitops.h
+#include xen/config.h
+#include xen/init.h
+#include xen/irq.h
+#include xen/list.h
+#include xen/sched.h
+#include xen/sizes.h
+#include asm/device.h
+#include asm/mmio.h
+#include asm/io.h
+#include asm/gic_v3_defs.h
+#include asm/gic.h
+#include asm/vgic.h
+#include asm/gic-its.h
+#include xen/log2.h
+
+static int vits_entry(struct domain *d, paddr_t entry, void *addr,
+ uint32_t size, bool_t set)
+{
+struct page_info *page;
+uint64_t offset;
+p2m_type_t p2mt;
+void *p;
+
+page = get_page_from_gfn(d, paddr_to_pfn(entry), p2mt, P2M_ALLOC);
+if ( !page )
+{
+dprintk(XENLOG_G_ERR, %pv: vITS: Failed to get table entry\n,
+current);
+return -EINVAL;
+}
+
+if ( !p2m_is_ram(p2mt) )
+{
+put_page(page);
+dprintk(XENLOG_G_ERR, %pv: vITS: with wrong attributes\n, current);
+return -EINVAL;
+}
+
+p = __map_domain_page(page);
+/* Offset within the mapped page */
+offset = entry ~PAGE_MASK;
+
+if ( set )
+memcpy(p + offset, addr, size);
+else
+memcpy(addr, p + offset, size);
+
+unmap_domain_page(p);
+put_page(page);
+
+return 0;
+}
+
+/* ITS device table helper functions */
+static int vits_vdevice_entry(struct domain *d, uint32_t dev_id,
+ struct vdevice_table *entry, bool_t set)
+{
+uint64_t offset;
+paddr_t dt_entry;
+
+BUILD_BUG_ON(sizeof(struct vdevice_table) != 16);
+
+offset = dev_id * sizeof(struct vdevice_table);
+if ( offset d-arch.vits-dt_size )
+{
+dprintk(XENLOG_G_ERR,
+%pv: vITS: Out of range offset %ld id 0x%x size %ld\n,
+current, offset, dev_id, d-arch.vits-dt_size);
+return -EINVAL;
+}
+
+dt_entry = d-arch.vits-dt_ipa + offset;
+
+return vits_entry(d, dt_entry, (void *)entry,
+ sizeof(struct vdevice_table), set);
+}
+
+int vits_set_vdevice_entry(struct domain *d, uint32_t devid,
+ struct vdevice_table *entry)
+{
+return vits_vdevice_entry(d, devid, entry, 1);
+}
+
+int vits_get_vdevice_entry(struct domain *d, uint32_t devid,
+ struct vdevice_table *entry)
+{
+return vits_vdevice_entry(d, devid, entry, 0);
+}
+
+static int vits_vitt_entry(struct domain *d, uint32_t devid,
+ uint32_t event, struct vitt *entry, bool_t set)
+{
+struct vdevice_table dt_entry;
+paddr_t vitt_entry;
+uint64_t offset;
+
+BUILD_BUG_ON(sizeof(struct vitt) != 8);
+
+if ( vits_get_vdevice_entry(d, devid, dt_entry) )
+{
+dprintk(XENLOG_G_ERR, %pv: vITS: Fail to get vdevice for dev 0x%x\n,
+current, devid);
+return -EINVAL;
+}
+
+/* dt_entry is validated when read */
+offset = event * sizeof(struct vitt);
+if ( offset dt_entry.vitt_size )
+{
+dprintk(XENLOG_G_ERR, %pv: vITS: ITT out of range\n, current);
+return -EINVAL;
+}
+
+vitt_entry = dt_entry.vitt_ipa + offset;
+
+return vits_entry(d, vitt_entry, (void *)entry,
+ sizeof(struct vitt), set);
+}
+
+int vits_set_vitt_entry(struct domain *d, uint32_t devid,
+uint32_t event, struct vitt *entry)
+{
+return
[Xen-devel] [PATCH v4 09/17] xen/arm: ITS: Add GITS registers emulation
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Emulate GITS* registers
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: - Removed GICR register emulation
---
xen/arch/arm/gic-v3-its.c | 11 ++
xen/arch/arm/vgic-v3-its.c| 319 -
xen/include/asm-arm/gic-its.h | 10 ++
xen/include/asm-arm/gic_v3_defs.h | 11 ++
4 files changed, 349 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 1d2fdde..5e6c7f2 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -109,6 +109,16 @@ u32 its_get_nr_events(void)
return (1 its_data.id_bits);
}
+u32 its_get_id_bits(void)
+{
+return its_data.id_bits;
+}
+
+u32 its_get_dev_bits(void)
+{
+return its_data.dev_bits;
+}
+
static struct its_node * its_get_phys_node(u32 dev_id)
{
/* TODO: For now return ITS0 node.
@@ -1309,6 +1319,7 @@ static int its_probe(struct dt_device_node *node)
typer = readl_relaxed(its_base + GITS_TYPER);
its-ite_size = ((typer 4) 0xf) + 1;
its_data.id_bits = GITS_TYPER_IDBITS(typer);
+its_data.dev_bits = GITS_TYPER_DEVBITS(typer);
its-cmd_base = xzalloc_bytes(ITS_CMD_QUEUE_SZ);
if ( !its-cmd_base )
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index af2bacd..abf60e2 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -31,7 +31,9 @@
#include asm/gic-its.h
#include xen/log2.h
-#define DEBUG_ITS
+// #define DEBUG_ITS
+#define VITS_GITS_ITT_SIZE(0x7U GITS_TYPER_ITT_SIZE_SHIFT)
+#define VITS_GITS_PLPIS (0x1U)
#ifdef DEBUG_ITS
# define DPRINTK(fmt, args...) dprintk(XENLOG_DEBUG, fmt, ##args)
@@ -568,7 +570,7 @@ static int vgic_its_read_virt_cmd(struct vcpu *v,
return 0;
}
-int vgic_its_process_cmd(struct vcpu *v, struct vgic_its *vits)
+static int vgic_its_process_cmd(struct vcpu *v, struct vgic_its *vits)
{
its_cmd_block virt_cmd;
@@ -593,6 +595,319 @@ err:
return 0;
}
+static inline void vits_spin_lock(struct vgic_its *vits)
+{
+spin_lock(vits-lock);
+}
+
+static inline void vits_spin_unlock(struct vgic_its *vits)
+{
+spin_unlock(vits-lock);
+}
+
+static int vgic_v3_gits_mmio_read(struct vcpu *v, mmio_info_t *info)
+{
+struct vgic_its *vits = v-domain-arch.vits;
+struct hsr_dabt dabt = info-dabt;
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+register_t *r = select_user_reg(regs, dabt.reg);
+uint64_t val = 0;
+uint32_t gits_reg;
+
+gits_reg = info-gpa - vits-gits_base;
+
+switch ( gits_reg )
+{
+case GITS_CTLR:
+if ( dabt.size != DABT_WORD ) goto bad_width;
+vits_spin_lock(vits);
+*r = vits-ctrl GITS_CTLR_ENABLE;
+vits_spin_unlock(vits);
+return 1;
+case GITS_IIDR:
+if ( dabt.size != DABT_WORD ) goto bad_width;
+*r = GICV3_GICD_IIDR_VAL;
+return 1;
+case GITS_TYPER:
+case GITS_TYPER + 4:
+vits_spin_lock(vits);
+val = (((v-domain-max_vcpus + 1) GITS_TYPER_HCC_SHIFT ) |
+(its_get_dev_bits() - 1) GITS_TYPER_DEVBITS_SHIFT |
+(its_get_id_bits() - 1) GITS_TYPER_IDBITS_SHIFT |
+ VITS_GITS_ITT_SIZE | VITS_GITS_PLPIS);
+if ( (gits_reg % 8) == 0 dabt.size == DABT_DOUBLE_WORD )
+*r = val;
+else if ( dabt.size == DABT_WORD )
+{
+if ( (gits_reg % 8) == 0 )
+*r = (u32)(val 32);
+else
+*r = (u32)val;
+}
+else
+{
+vits_spin_unlock(vits);
+goto bad_width;
+}
+vits_spin_unlock(vits);
+return 1;
+case 0x0010 ... 0x007c:
+case 0xc000 ... 0xffcc:
+/* Implementation defined -- read ignored */
+goto read_as_zero;
+case GITS_CBASER:
+case GITS_CBASER + 4:
+/* Only read support 32/64-bit access */
+vits_spin_lock(vits);
+if ( (gits_reg % 8) == 0 dabt.size == DABT_DOUBLE_WORD )
+*r = vits-cmd_base;
+else if ( dabt.size == DABT_WORD )
+{
+if ( (gits_reg % 8) == 0 )
+*r = (u32)vits-cmd_base;
+else
+*r = (u32)(vits-cmd_base 32);
+}
+else
+{
+vits_spin_unlock(vits);
+goto bad_width;
+}
+vits_spin_unlock(vits);
+return 1;
+case GITS_CWRITER:
+case GITS_CWRITER + 4:
+/* Only read support 32/64-bit access */
+vits_spin_lock(vits);
+if ( (gits_reg % 8) == 0 dabt.size == DABT_DOUBLE_WORD )
+*r = vits-cmd_write;
+else if ( dabt.size == DABT_WORD )
+{
+if ( (gits_reg % 8) == 0 )
+*r = (u32)vits-cmd_write;
+else
+*r = (u32)(vits-cmd_write 32);
+}
+else
+{
+
[Xen-devel] [PATCH v4 08/17] xen/arm: ITS: Add APIs to add and assign device
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add APIs to add devices to RB-tree, assign and remove
devices to domain.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: - Introduced helper to populate its_device struct
- Fixed freeing of its_device memory
- its_device struct holds domain id
---
xen/arch/arm/gic-v3-its.c | 362 +
xen/arch/arm/irq.c|8 +
xen/include/asm-arm/gic-its.h | 18 ++
xen/include/asm-arm/irq.h |1 +
4 files changed, 389 insertions(+)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 9161053..1d2fdde 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -92,6 +92,7 @@ static DEFINE_SPINLOCK(its_lock);
static struct rdist_prop *gic_rdists;
static struct rb_root rb_its_dev;
static struct gic_its_info its_data;
+static DEFINE_SPINLOCK(rb_its_dev_lock);
#define gic_data_rdist()(per_cpu(rdist, smp_processor_id()))
@@ -108,6 +109,14 @@ u32 its_get_nr_events(void)
return (1 its_data.id_bits);
}
+static struct its_node * its_get_phys_node(u32 dev_id)
+{
+/* TODO: For now return ITS0 node.
+ * Need Query PCI helper function to get on which
+ * ITS node the device is attached
+ */
+return list_first_entry(its_nodes, struct its_node, entry);
+}
/* RB-tree helpers for its_device */
struct its_device *its_find_device(u32 devid)
{
@@ -314,6 +323,30 @@ static void its_send_inv(struct its_device *dev, struct
its_collection *col,
its_send_single_command(dev-its, cmd, col);
}
+static void its_send_mapd(struct its_device *dev, int valid)
+{
+its_cmd_block cmd;
+unsigned long itt_addr;
+u8 size;
+
+size = max(ilog2(dev-nr_ites), 1);
+itt_addr = __pa(dev-itt_addr);
+itt_addr = ROUNDUP(itt_addr, ITS_ITT_ALIGN);
+
+memset(cmd, 0x0, sizeof(its_cmd_block));
+cmd.mapd.cmd = GITS_CMD_MAPD;
+cmd.mapd.devid = dev-device_id;
+cmd.mapd.size = size - 1;
+/*
+ * ITT address field of MAPD command holds bit[48:8] of
+ * itt address. Hence shift by 8.
+ */
+cmd.mapd.itt = itt_addr 8;
+cmd.mapd.valid = !!valid;
+
+its_send_single_command(dev-its, cmd, dev-its-collections[0]);
+}
+
static void its_send_mapc(struct its_node *its, struct its_collection *col,
int valid)
{
@@ -328,6 +361,21 @@ static void its_send_mapc(struct its_node *its, struct
its_collection *col,
its_send_single_command(its, cmd, col);
}
+static void its_send_mapvi(struct its_device *dev, struct its_collection *col,
+u32 phys_id, u32 event)
+{
+its_cmd_block cmd;
+
+memset(cmd, 0x0, sizeof(its_cmd_block));
+cmd.mapvi.cmd = GITS_CMD_MAPVI;
+cmd.mapvi.devid = dev-device_id;
+cmd.mapvi.event = event;
+cmd.mapvi.phy_id = phys_id;
+cmd.mapvi.col = col-col_id;
+
+its_send_single_command(dev-its, cmd, col);
+}
+
static void its_send_invall(struct its_node *its, struct its_collection *col)
{
its_cmd_block cmd;
@@ -473,12 +521,18 @@ static const struct its_hw_operations its_ops = {
static unsigned long *lpi_bitmap;
static u32 lpi_chunks;
+static DEFINE_SPINLOCK(lpi_lock);
static int its_lpi_to_chunk(int lpi)
{
return (lpi - 8192) IRQS_PER_CHUNK_SHIFT;
}
+static int its_chunk_to_lpi(int chunk)
+{
+return (chunk IRQS_PER_CHUNK_SHIFT) + 8192;
+}
+
int its_lpi_init(u32 id_bits)
{
lpi_chunks = its_lpi_to_chunk(1UL id_bits);
@@ -495,6 +549,314 @@ int its_lpi_init(u32 id_bits)
return 0;
}
+static unsigned long *its_lpi_alloc_chunks(int nirqs, int *base, int *nr_ids)
+{
+unsigned long *bitmap = NULL;
+int chunk_id;
+int nr_chunks;
+int i;
+
+nr_chunks = DIV_ROUND_UP(nirqs, IRQS_PER_CHUNK);
+
+spin_lock(lpi_lock);
+
+do {
+chunk_id = bitmap_find_next_zero_area(lpi_bitmap, lpi_chunks,
+ 0, nr_chunks, 0);
+if ( chunk_id lpi_chunks )
+break;
+
+nr_chunks--;
+} while ( nr_chunks 0 );
+
+if ( !nr_chunks )
+goto out;
+
+bitmap = xzalloc_bytes(BITS_TO_LONGS(nr_chunks * IRQS_PER_CHUNK) *
+ sizeof (long));
+if ( !bitmap )
+goto out;
+
+for ( i = 0; i nr_chunks; i++ )
+set_bit(chunk_id + i, lpi_bitmap);
+
+*base = its_chunk_to_lpi(chunk_id);
+*nr_ids = nr_chunks * IRQS_PER_CHUNK;
+
+out:
+spin_unlock(lpi_lock);
+
+return bitmap;
+}
+
+static void its_lpi_free(unsigned long *bitmap, int base, int nr_ids)
+{
+int lpi;
+
+spin_lock(lpi_lock);
+
+for ( lpi = base; lpi (base + nr_ids); lpi += IRQS_PER_CHUNK )
+{
+int chunk = its_lpi_to_chunk(lpi);
+
+BUG_ON(chunk lpi_chunks);
+if ( test_bit(chunk, lpi_bitmap) )
+clear_bit(chunk, lpi_bitmap);
+else
+its_err(Bad LPI chunk %d\n, chunk);
+}
+
+
[Xen-devel] [PATCH v4 13/17] xen/arm: ITS: Initialize physical ITS
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com Initialize physical ITS driver from GIC v3 driver if LPIs are supported by hardware Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com --- xen/arch/arm/gic-v3.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index 53554e6..f4881d7 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -694,6 +694,10 @@ static int __cpuinit gicv3_cpu_init(void) if ( gicv3_enable_redist() ) return -ENODEV; +/* Give LPIs a spin */ +if ( gicv3_info.lpi_supported ) +its_cpu_init(); + /* Set priority on PPI and SGI interrupts */ priority = (GIC_PRI_IPI 24 | GIC_PRI_IPI 16 | GIC_PRI_IPI 8 | GIC_PRI_IPI); @@ -1312,6 +1316,9 @@ static int __init gicv3_init(void) else gicv3_info.lpi_supported = 0; +if ( gicv3_info.lpi_supported ) +its_init(gicv3.rdist_data); + gicv3_dist_init(); res = gicv3_cpu_init(); gicv3_hyp_init(); -- 1.7.9.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 12/17] xen/arm: ITS: Initialize LPI irq descriptors and route
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Allocate and initialize irq descriptor for LPIs and
route LPIs to guest
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: - Merge patch #16
- Changed commit message
---
xen/arch/arm/gic-v3.c |2 +-
xen/arch/arm/gic.c| 24 +++--
xen/arch/arm/irq.c| 44 +
xen/arch/arm/vgic-v3-its.c|9
xen/arch/arm/vgic-v3.c| 15 --
xen/arch/arm/vgic.c | 110 ++---
xen/include/asm-arm/domain.h |3 ++
xen/include/asm-arm/gic-its.h |1 +
xen/include/asm-arm/gic.h |7 ++-
xen/include/asm-arm/vgic.h|1 +
10 files changed, 192 insertions(+), 24 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index e6004d2..53554e6 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -895,7 +895,7 @@ static void gicv3_update_lr(int lr, const struct
pending_irq *p,
val |= ((uint64_t)p-priority 0xff) GICH_LR_PRIORITY_SHIFT;
val |= ((uint64_t)p-irq GICH_LR_VIRTUAL_MASK) GICH_LR_VIRTUAL_SHIFT;
- if ( p-desc != NULL )
+ if ( p-desc != NULL !(is_lpi(p-irq)) )
val |= GICH_LR_HW | (((uint64_t)p-desc-irq GICH_LR_PHYSICAL_MASK)
GICH_LR_PHYSICAL_SHIFT);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 3ebadcf..92d2be9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -68,11 +68,18 @@ enum gic_version gic_hw_version(void)
return gic_hw_ops-info-hw_version;
}
+/* Only validates PPIs/SGIs/SPIs supported */
unsigned int gic_number_lines(void)
{
return gic_hw_ops-info-nr_lines;
}
+/* Validates PPIs/SGIs/SPIs/LPIs supported */
+bool_t gic_is_valid_irq(unsigned int irq)
+{
+return ((irq gic_hw_ops-info-nr_lines) is_lpi(irq));
+}
+
unsigned int gic_nr_id_bits(void)
{
return gic_hw_ops-info-nr_id_bits;
@@ -148,7 +155,7 @@ void gic_route_irq_to_xen(struct irq_desc *desc, const
cpumask_t *cpu_mask,
{
ASSERT(priority = 0xff); /* Only 8 bits of priority */
/* Can't route interrupts that don't exist */
-ASSERT(desc-irq gic_number_lines() || is_lpi(desc-irq));
+ASSERT(gic_is_valid_irq(desc-irq));
ASSERT(test_bit(_IRQ_DISABLED, desc-status));
ASSERT(spin_is_locked(desc-lock));
@@ -160,6 +167,17 @@ void gic_route_irq_to_xen(struct irq_desc *desc, const
cpumask_t *cpu_mask,
/* Program the GIC to route an interrupt to a guest
* - desc.lock must be held
*/
+int gic_route_lpi_to_guest(struct domain *d, unsigned int virq,
+ struct irq_desc *desc, unsigned int priority)
+{
+ASSERT(spin_is_locked(desc-lock));
+
+desc-handler = get_guest_hw_irq_controller(desc-irq);
+set_bit(_IRQ_GUEST, desc-status);
+
+return 0;
+}
+
int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
struct irq_desc *desc, unsigned int priority)
{
@@ -454,7 +472,7 @@ static void gic_update_one_lr(struct vcpu *v, int i)
if ( test_bit(GIC_IRQ_GUEST_ENABLED, p-status)
test_and_clear_bit(GIC_IRQ_GUEST_QUEUED, p-status) )
{
-if ( p-desc == NULL )
+if ( p-desc == NULL || is_lpi(irq) )
{
lr_val.state |= GICH_LR_PENDING;
gic_hw_ops-write_lr(i, lr_val);
@@ -677,7 +695,7 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
/* Reading IRQ will ACK it */
irq = gic_hw_ops-read_irq();
-if ( likely(irq = 16 irq 1020) )
+if ( (likely(irq = 16 irq 1020)) || is_lpi(irq) )
{
local_irq_enable();
do_IRQ(regs, irq, is_fiq);
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 3806d98..c8ea627 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -62,12 +62,21 @@ hw_irq_controller no_irq_type = {
};
static irq_desc_t irq_desc[NR_IRQS];
+#ifdef CONFIG_ARM_64
+static irq_desc_t irq_desc_lpi[NR_GIC_LPI];
+#endif
static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
irq_desc_t *__irq_to_desc(int irq)
{
if (irq NR_LOCAL_IRQS) return this_cpu(local_irq_desc)[irq];
-return irq_desc[irq-NR_LOCAL_IRQS];
+else if ( irq = NR_LOCAL_IRQS irq NR_IRQS)
+return irq_desc[irq-NR_LOCAL_IRQS];
+#ifdef CONFIG_ARM_64
+else if ( is_lpi(irq) )
+return irq_desc_lpi[irq - NR_GIC_LPI];
+#endif
+return NULL;
}
int __init arch_init_one_irq_desc(struct irq_desc *desc)
@@ -88,6 +97,15 @@ static int __init init_irq_data(void)
desc-action = NULL;
}
+#ifdef CONFIG_ARM_64
+for ( irq = NR_GIC_LPI; irq MAX_LPI; irq++ )
+{
+struct irq_desc *desc = irq_to_desc(irq);
+init_one_irq_desc(desc);
+desc-irq = irq;
+desc-action = NULL;
+}
+#endif
return 0;
}
@@ -208,7 +226,7 @@ int request_irq(unsigned int irq, unsigned int irqflags,
*
[Xen-devel] [PATCH v4 02/17] xen: Add log2 functionality
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
log2 helper apis are ported from linux from
commit 13c07b0286d340275f2d97adf085cecda37ede37
(linux/log2.h: Fix rounddown_pow_of_two(1))
Changes made for xen are:
- Only required functionality is retained
- Replace fls_long with flsl
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Jan Beulich jbeul...@suse.com
CC: Keir Fraser k...@xen.org
CC: Tim Deegan t...@xen.org
---
v4: - Only retained required functionality
- Replaced fls_long with flsl
- Removed fls_long implementation in bitops.h in v3 version
---
xen/include/xen/log2.h | 167
1 file changed, 167 insertions(+)
diff --git a/xen/include/xen/log2.h b/xen/include/xen/log2.h
new file mode 100644
index 000..86bd861
--- /dev/null
+++ b/xen/include/xen/log2.h
@@ -0,0 +1,167 @@
+/*
+ * Copyright (C) 2006 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _XEN_LOG2_H
+#define _XEN_LOG2_H
+
+#include xen/types.h
+#include xen/bitops.h
+
+/*
+ * deal with unrepresentable constant logarithms
+ */
+extern __attribute__((const))
+int ilog2_NaN(void);
+
+/*
+ * non-constant log of base 2 calculators
+ * - the arch may override these in asm/bitops.h if they can be implemented
+ * more efficiently than using fls() and fls64()
+ * - the arch is not required to handle n==0 if implementing the fallback
+ */
+static inline __attribute__((const))
+int __ilog2_u32(u32 n)
+{
+ return fls(n) - 1;
+}
+
+static inline __attribute__((const))
+int __ilog2_u64(u64 n)
+{
+ return flsl(n) - 1;
+}
+
+/*
+ * round up to nearest power of two
+ */
+static inline __attribute__((const))
+unsigned long __roundup_pow_of_two(unsigned long n)
+{
+ return 1UL flsl(n - 1);
+}
+
+/**
+ * ilog2 - log of base 2 of 32-bit or a 64-bit unsigned value
+ * @n - parameter
+ *
+ * constant-capable log of base 2 calculation
+ * - this can be used to initialise global variables from constant data, hence
+ * the massive ternary operator construction
+ *
+ * selects the appropriately-sized optimised version depending on sizeof(n)
+ */
+#define ilog2(n) \
+( \
+ __builtin_constant_p(n) ? ( \
+ (n) 1 ? ilog2_NaN() : \
+ (n) (1ULL 63) ? 63 : \
+ (n) (1ULL 62) ? 62 : \
+ (n) (1ULL 61) ? 61 : \
+ (n) (1ULL 60) ? 60 : \
+ (n) (1ULL 59) ? 59 : \
+ (n) (1ULL 58) ? 58 : \
+ (n) (1ULL 57) ? 57 : \
+ (n) (1ULL 56) ? 56 : \
+ (n) (1ULL 55) ? 55 : \
+ (n) (1ULL 54) ? 54 : \
+ (n) (1ULL 53) ? 53 : \
+ (n) (1ULL 52) ? 52 : \
+ (n) (1ULL 51) ? 51 : \
+ (n) (1ULL 50) ? 50 : \
+ (n) (1ULL 49) ? 49 : \
+ (n) (1ULL 48) ? 48 : \
+ (n) (1ULL 47) ? 47 : \
+ (n) (1ULL 46) ? 46 : \
+ (n) (1ULL 45) ? 45 : \
+ (n) (1ULL 44) ? 44 : \
+ (n) (1ULL 43) ? 43 : \
+ (n) (1ULL 42) ? 42 : \
+ (n) (1ULL 41) ? 41 : \
+ (n) (1ULL 40) ? 40 : \
+ (n) (1ULL 39) ? 39 : \
+ (n) (1ULL 38) ? 38 : \
+ (n) (1ULL 37) ? 37 : \
+ (n) (1ULL 36) ? 36 : \
+ (n) (1ULL 35) ? 35 : \
+ (n) (1ULL 34) ? 34 : \
+ (n) (1ULL 33) ? 33 : \
+ (n) (1ULL 32) ? 32 : \
+ (n) (1ULL 31) ? 31 : \
+ (n) (1ULL 30) ? 30 : \
+ (n) (1ULL 29) ? 29 : \
+ (n) (1ULL 28) ? 28 : \
+ (n) (1ULL 27) ? 27 : \
+ (n) (1ULL 26) ? 26 : \
+ (n) (1ULL 25) ? 25 : \
+ (n) (1ULL 24) ? 24 : \
+ (n) (1ULL 23) ? 23 : \
+ (n) (1ULL 22) ? 22 : \
+ (n) (1ULL 21) ? 21 : \
+ (n) (1ULL 20) ? 20 : \
+ (n) (1ULL 19) ? 19 : \
+ (n) (1ULL 18) ? 18 : \
+ (n) (1ULL 17) ? 17 : \
+ (n) (1ULL 16) ? 16 : \
+
[Xen-devel] [PATCH v4 05/17] xen/arm: ITS: implement hw_irq_controller for LPIs
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Implements hw_irq_controller api's required
to handle LPI's
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v4: - Implement separate hw_irq_controller for LPIs
- Drop setting LPI affinity
- virq and vid are moved under union
- Introduced inv command handling
- its_device is stored in irq_desc
---
xen/arch/arm/gic-v3-its.c | 132 +
xen/arch/arm/gic-v3.c |5 +-
xen/arch/arm/gic.c| 32 +++--
xen/arch/arm/irq.c| 40 ++-
xen/include/asm-arm/gic-its.h |4 ++
xen/include/asm-arm/gic.h | 13
xen/include/asm-arm/gic_v3_defs.h |1 +
xen/include/asm-arm/irq.h |8 ++-
8 files changed, 227 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index b421a6f..b98d396 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -295,6 +295,19 @@ post:
its_wait_for_range_completion(its, cmd, next_cmd);
}
+static void its_send_inv(struct its_device *dev, struct its_collection *col,
+ u32 event_id)
+{
+its_cmd_block cmd;
+
+memset(cmd, 0x0, sizeof(its_cmd_block));
+cmd.inv.cmd = GITS_CMD_INV;
+cmd.inv.devid = dev-device_id;
+cmd.inv.event = event_id;
+
+its_send_single_command(dev-its, cmd, col);
+}
+
static void its_send_mapc(struct its_node *its, struct its_collection *col,
int valid)
{
@@ -320,6 +333,125 @@ static void its_send_invall(struct its_node *its, struct
its_collection *col)
its_send_single_command(its, cmd, NULL);
}
+static void lpi_set_config(struct irq_desc *desc, int enable)
+{
+u8 *cfg;
+struct its_collection *col;
+struct its_device *its_dev = get_irq_device(desc);
+u16 col_id;
+u32 vid = irq_to_vid(desc);
+
+ASSERT(vid its_dev-nr_lpis);
+
+cfg = gic_rdists-prop_page + desc-irq - NR_GIC_LPI;
+if ( enable )
+*cfg |= LPI_PROP_ENABLED;
+else
+*cfg = ~LPI_PROP_ENABLED;
+
+/*
+ * Make the above write visible to the redistributors.
+ * And yes, we're flushing exactly: One. Single. Byte.
+ * Humpf...
+ */
+if ( gic_rdists-flags RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING )
+clean_and_invalidate_dcache_va_range(cfg, sizeof(*cfg));
+else
+dsb(ishst);
+
+/* Get collection id for this event id */
+col_id = gic_get_irq_collection(desc-irq);
+col = its_dev-its-collections[col_id];
+its_send_inv(its_dev, col, vid);
+}
+
+static void its_irq_enable(struct irq_desc *desc)
+{
+unsigned long flags;
+
+ASSERT(spin_is_locked(desc-lock));
+
+spin_lock_irqsave(its_lock, flags);
+clear_bit(_IRQ_DISABLED, desc-status);
+dsb(sy);
+lpi_set_config(desc, 1);
+spin_unlock_irqrestore(its_lock, flags);
+}
+
+static void its_irq_disable(struct irq_desc *desc)
+{
+unsigned long flags;
+
+ASSERT(spin_is_locked(desc-lock));
+
+spin_lock_irqsave(its_lock, flags);
+lpi_set_config(desc, 0);
+set_bit(_IRQ_DISABLED, desc-status);
+spin_unlock_irqrestore(its_lock, flags);
+}
+
+static unsigned int its_irq_startup(struct irq_desc *desc)
+{
+its_irq_enable(desc);
+
+return 0;
+}
+
+static void its_irq_shutdown(struct irq_desc *desc)
+{
+its_irq_disable(desc);
+}
+
+static void its_irq_ack(struct irq_desc *desc)
+{
+/* No ACK -- reading IAR has done this for us */
+}
+
+static void its_host_irq_end(struct irq_desc *desc)
+{
+/* Lower the priority */
+gicv3_eoi_irq(desc);
+/* Deactivate */
+gicv3_dir_irq(desc);
+}
+
+static void its_guest_irq_end(struct irq_desc *desc)
+{
+gicv3_eoi_irq(desc);
+}
+
+static void its_irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+return;
+}
+
+static const hw_irq_controller its_host_lpi_type = {
+.typename = gic-its,
+.startup = its_irq_startup,
+.shutdown = its_irq_shutdown,
+.enable = its_irq_enable,
+.disable = its_irq_disable,
+.ack = its_irq_ack,
+.end = its_host_irq_end,
+.set_affinity = its_irq_set_affinity,
+};
+
+static const hw_irq_controller its_guest_lpi_type = {
+.typename = gic-its,
+.startup = its_irq_startup,
+.shutdown = its_irq_shutdown,
+.enable = its_irq_enable,
+.disable = its_irq_disable,
+.ack = its_irq_ack,
+.end = its_guest_irq_end,
+.set_affinity = its_irq_set_affinity,
+};
+
+static const struct its_hw_operations its_ops = {
+.lpi_host_irq_type = its_host_lpi_type,
+.lpi_guest_irq_type = its_guest_lpi_type,
+};
+
/*
* How we allocate LPIs:
*
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b5c59f6..904fe57 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -40,6 +40,7 @@
#include asm/device.h
#include
[Xen-devel] [PATCH v4 00/17] Add ITS support
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com This is based on DraftF version http://xenbits.xen.org/people/ianc/vits/draftG.pdf Following major features are supported - GICv3 ITS support for arm64 platform - Only Dom0 is supported. For DomU pci passthrough feature is required. Basic boot is tested with single ITS node by adding and assigning devices from platform initialization. Changes in v4: - Patch for rate limiting of error message is removed. - Patch #4 and #5 in v3 is merged - Merged #13 and #16 as one patch - hw_irq_controller is implemented for LPIs - GITS and GICR emulation for LPIs in separate patches - Removed build functions for ITS command in physical ITS driver - Added new patch to add and assign devices from platform file - Enable compilation of vits and pits driver in separate patch - Replace msi-parent property in all pci dt nodes to single ITS node generated by Xen for Dom0 Vijaya Kumar K (17): xen/arm: Add bitmap_find_next_zero_area helper function xen: Add log2 functionality xen/arm: ITS: Port ITS driver to Xen xen/arm: ITS: Add helper functions to manage its_devices xen/arm: ITS: implement hw_irq_controller for LPIs xen/arm: ITS: Add virtual ITS driver xen/arm: ITS: Add virtual ITS commands support xen/arm: ITS: Add APIs to add and assign device xen/arm: ITS: Add GITS registers emulation xen/arm: ITS: Enable physical and virtual ITS driver compilation xen/arm: ITS: Add GICR register emulation xen/arm: ITS: Initialize LPI irq descriptors and route xen/arm: ITS: Initialize physical ITS xen/arm: ITS: Add domain specific ITS initialization xen/arm: ITS: Map ITS translation space xen/arm: ITS: Generate ITS node for Dom0 xen/arm: ITS: Add pci devices in ThunderX xen/arch/arm/Makefile |2 + xen/arch/arm/domain_build.c | 78 ++ xen/arch/arm/gic-v3-its.c | 1517 + xen/arch/arm/gic-v3.c | 44 +- xen/arch/arm/gic.c| 64 +- xen/arch/arm/irq.c| 92 ++- xen/arch/arm/platforms/thunderx.c | 77 ++ xen/arch/arm/setup.c |4 +- xen/arch/arm/vgic-v3-its.c| 1160 xen/arch/arm/vgic-v3.c| 103 ++- xen/arch/arm/vgic.c | 114 ++- xen/common/bitmap.c | 37 + xen/include/asm-arm/domain.h |8 + xen/include/asm-arm/gic-its.h | 294 +++ xen/include/asm-arm/gic.h | 33 +- xen/include/asm-arm/gic_v3_defs.h | 134 +++- xen/include/asm-arm/irq.h |9 +- xen/include/asm-arm/vgic.h|2 + xen/include/xen/bitmap.h |5 + xen/include/xen/lib.h |2 + xen/include/xen/log2.h| 167 21 files changed, 3898 insertions(+), 48 deletions(-) create mode 100644 xen/arch/arm/gic-v3-its.c create mode 100644 xen/arch/arm/vgic-v3-its.c create mode 100644 xen/include/asm-arm/gic-its.h create mode 100644 xen/include/xen/log2.h -- 1.7.9.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 01/17] xen/arm: Add bitmap_find_next_zero_area helper function
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
bitmap_find_next_zero_area helper function will be used
by physical ITS driver. This is imported from linux
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Jan Beulich jbeul...@suse.com
CC: Keir Fraser k...@xen.org
CC: Tim Deegan t...@xen.org
---
v4: Removed spaces and added tabs
Moved ALIGN macro to lib.h
v3: Moved changes to xen/common/bitmap.c and
xen/include/xen/bitmap.h
---
xen/common/bitmap.c | 37 +
xen/include/xen/bitmap.h |5 +
xen/include/xen/lib.h|2 ++
3 files changed, 44 insertions(+)
diff --git a/xen/common/bitmap.c b/xen/common/bitmap.c
index 61d1ea4..77c68b0 100644
--- a/xen/common/bitmap.c
+++ b/xen/common/bitmap.c
@@ -489,6 +489,43 @@ int bitmap_allocate_region(unsigned long *bitmap, int pos,
int order)
}
EXPORT_SYMBOL(bitmap_allocate_region);
+/*
+ * bitmap_find_next_zero_area - find a contiguous aligned zero area
+ * @map: The address to base the search on
+ * @size: The bitmap size in bits
+ * @start: The bitnumber to start searching at
+ * @nr: The number of zeroed bits we're looking for
+ * @align_mask: Alignment mask for zero area
+ *
+ * The @align_mask should be one less than a power of 2; the effect is that
+ * the bit offset of all zero areas this function finds is multiples of that
+ * power of 2. A @align_mask of 0 means no alignment is required.
+ */
+unsigned long bitmap_find_next_zero_area(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = ALIGN_MASK(index, align_mask);
+
+ end = index + nr;
+ if (end size)
+ return end;
+ i = find_next_bit(map, end, index);
+ if (i end) {
+ start = i + 1;
+ goto again;
+ }
+ return index;
+}
+EXPORT_SYMBOL(bitmap_find_next_zero_area);
+
#ifdef __BIG_ENDIAN
void bitmap_long_to_byte(uint8_t *bp, const unsigned long *lp, int nbits)
diff --git a/xen/include/xen/bitmap.h b/xen/include/xen/bitmap.h
index e2a3686..238b976 100644
--- a/xen/include/xen/bitmap.h
+++ b/xen/include/xen/bitmap.h
@@ -101,6 +101,11 @@ extern int bitmap_scnlistprintf(char *buf, unsigned int
len,
extern int bitmap_find_free_region(unsigned long *bitmap, int bits, int order);
extern void bitmap_release_region(unsigned long *bitmap, int pos, int order);
extern int bitmap_allocate_region(unsigned long *bitmap, int pos, int order);
+extern unsigned long bitmap_find_next_zero_area(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask);
#define BITMAP_LAST_WORD_MASK(nbits) \
( \
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 4258912..e7d9d95 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -55,6 +55,8 @@
#define ROUNDUP(x, a) (((x) + (a) - 1) ~((a) - 1))
+#define ALIGN_MASK(x, mask) (((x) + (mask)) ~(mask))
+
#define reserve_bootmem(_p,_l) ((void)0)
struct domain;
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 17/17] xen/arm: ITS: Add pci devices in ThunderX
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
ITS initialization required for all PCI devices in
ThunderX platform are done by calling from specific
mapping function.
This patch can be reverted once XEN PCI passthrough
framework for arm64 is in available.
For now all the PCI devices are assigned to Dom0
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/platforms/thunderx.c | 77 +
1 file changed, 77 insertions(+)
diff --git a/xen/arch/arm/platforms/thunderx.c
b/xen/arch/arm/platforms/thunderx.c
index be6f24f..6bd21d2 100644
--- a/xen/arch/arm/platforms/thunderx.c
+++ b/xen/arch/arm/platforms/thunderx.c
@@ -18,6 +18,82 @@
*/
#include asm/platform.h
+#include asm/gic-its.h
+
+struct pci_dev_list
+{
+ uint32_t seg;
+ uint32_t bus;
+ uint32_t dev;
+ uint32_t func;
+};
+
+#define NUM_DEVIDS 39
+
+static struct pci_dev_list bdf[NUM_DEVIDS] =
+{
+{0, 0, 2, 0}, /* 1 */
+{0, 0, 6, 0},
+{0, 0, 7, 0},
+{0, 0, 10, 0},
+{0, 0, 11, 0},
+{0, 1, 0, 0},
+{0, 1, 0, 1},
+{0, 1, 0, 5},
+{0, 1, 1, 4},
+{0, 1, 9, 0}, /* 10 */
+{0, 1, 9, 1},
+{0, 1, 9, 2},
+{0, 1, 9, 3},
+{0, 1, 9, 4},
+{0, 1, 9, 5},
+{0, 1, 10, 0},
+{0, 1, 10, 1},
+{0, 1, 10, 2},
+{0, 1, 10, 3},
+{0, 1, 14, 0}, /* 20 */
+{0, 1, 14, 2},
+{0, 1, 14, 4},
+{0, 1, 16, 0},
+{0, 1, 16, 1},
+{0, 2, 0, 0},
+{0, 3, 0, 0},
+{0, 4, 0, 0},
+{1, 0, 8, 0},
+{1, 0, 9, 0},
+{1, 0, 10, 0}, /* 30 */
+{1, 0, 11, 0},
+{2, 0, 1, 0},
+{2, 0, 2, 0},
+{2, 0, 3, 0},
+{2, 1, 0, 0},
+{2, 1, 0, 1},
+{2, 1, 0, 2},
+{2, 1, 0, 3},
+{3, 0, 1, 0}, /* 39 */
+};
+
+#define BDF_TO_DEVID(seg, bus, dev, func) (seg 16 | bus 8 | dev 3|
func)
+
+/* TODO: add and assign devices using PCI framework */
+static int thunderx_specific_mapping(struct domain *d)
+{
+uint32_t devid, i;
+int res;
+
+for ( i = 0; i NUM_DEVIDS; i++ )
+{
+devid = BDF_TO_DEVID(bdf[i].seg, bdf[i].bus,bdf[i].dev, bdf[i].func);
+res = its_add_device(devid);
+if ( res )
+return res;
+res = its_assign_device(d, devid, devid);
+if ( res )
+return res;
+}
+
+return 0;
+}
static const char * const thunderx_dt_compat[] __initconst =
{
@@ -27,6 +103,7 @@ static const char * const thunderx_dt_compat[] __initconst =
PLATFORM_START(thunderx, THUNDERX)
.compatible = thunderx_dt_compat,
+.specific_mapping = thunderx_specific_mapping,
.dom0_gnttab_start = 0x400,
.dom0_gnttab_size = 0x2,
PLATFORM_END
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/15] x86/hvm: I/O emulation cleanup and fix | Full Backtrace of domU's X crash caused by SSE2 istruction in attachment
Il 09/07/2015 15:10, Paul Durrant ha scritto:
This patch series re-works much of the code involved in emulation of port
and memory mapped I/O for HVM guests.
The code has become very convoluted and, at least by inspection, certain
emulations will apparently malfunction.
The series is broken down into 15 patches (which are also available in
my xenbits repo: http://xenbits.xen.org/gitweb/?p=people/pauldu/xen.git
on the emulation34 branch).
Yesterday I retried with this version and seems that you fixed something
that make possible atleast debug in the domU.
I taken gdb data of X crash inside Sid hvm domU:
#0 sse2_blt (src_bits=optimized out, dst_bits=optimized out,
src_stride=optimized out, dst_stride=optimized out,
src_bpp=optimized out, src_x=optimized out, src_y=0, dest_x=0,
dest_y=0, width=1024, height=optimized out, dst_bpp=optimized out,
imp=optimized out) at ../../pixman/pixman-sse2.c:4773
Latest istruction:
= 0x7f70360ef8eb sse2_blt+459:movaps %xmm0,-0x10(%rsi)
Full log in attachment.
If you need more informations/tests tell me and I'll post them.
Thanks for any reply and sorry for my bad english.
Previous changelog
--
v4:
- Removed previous patch (make sure translated MMIO reads or
writes fall within a page) and rebased rest of series.
- Address Jan's comments on patch #1
v3:
- Addressed comments from Jan
- Re-ordered series to bring a couple of more trivial patches to the
front
- Backport to XenServer (4.5) now passing automated tests
- Tested on unstable with QEMU upstream and trad, with and without
HAP (to force shadow emulation)
v2:
- Removed bogus assertion from patch #15
- Re-worked patch #17 after basic testing of back-port onto XenServer
Subsequent changes are logged in the individual patch files (thanks
to David Vrabel for that).
Testing
---
v6 of the series was been back-ported to staging-4.5 and then dropped
onto the XenServer (Dundee) patch queue. All automated branch-safety tests
pass.
v7 has just been compile tested since changes were largely cosmetic. It
will be back-ported in the near future.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Full backtrace:
#0 sse2_blt (src_bits=optimized out, dst_bits=optimized out,
src_stride=optimized out, dst_stride=optimized out, src_bpp=optimized
out, src_x=optimized out, src_y=0, dest_x=0, dest_y=0, width=1024,
height=optimized out, dst_bpp=optimized out, imp=optimized out) at
../../pixman/pixman-sse2.c:4773
w = 4160
s = 0x7f702985e530 \300\300\300
d = 0x7f70226d3fd0 \300\300\300
src_bytes = 0x7f702985d130
\277\277\277\261\277\277\277\260\277\277\277\257\277\277\277\256\277\277\277\257\277\277\277\261\300\300\300\261\300\300\300\260\277\277\277\261\277\277\277\261\277\277\277\260\277\277\277\257\277\277\277\262\277\277\277\261\277\277\277\262\300\300\300\261\300\300\300\261\300\300\300\261\277\277\277\257\277\277\277\261\277\277\277\261\277\277\277\261\277\277\277\260\300\300\300\262\277\277\277\261\277\277\277\260\277\277\277\260\277\277\277\260\277\277\277\261\277\277\277\261\277\277\277\261\277\277\277\261\277\277\277\261\277\277\277\260\277\277\277\261\277\277\277\261\277\277\277\261\277\277\277\260\277\277\277\261\277\277\277\261\277\277\277\261\277\277\277\260\277\277\277\262\277\277\277\261\277\277\277\261\277\277\277\260\277\277\277\261\277\277\277\261\277\277\277\261\277\277\277\261...
dst_bytes = optimized out
byte_width = 4096
#1 0x7f70360efa39 in sse2_blt (height=768, width=1024, dest_y=0,
dest_x=optimized out, src_y=optimized out, src_x=optimized out,
dst_bpp=optimized out, src_bpp=optimized out, dst_stride=optimized out,
src_stride=optimized out, dst_bits=optimized out, src_bits=optimized out,
imp=optimized out) at ../../pixman/pixman-sse2.c:4822
No locals.
#2 sse2_composite_copy_area (imp=optimized out, info=optimized out) at
../../pixman/pixman-sse2.c:4815
op = optimized out
src_image = optimized out
mask_image = optimized out
dest_image = optimized out
src_x = optimized out
src_y = optimized out
mask_x = optimized out
mask_y = optimized out
dest_x = optimized out
dest_y = 0
width = 1024
height = 768
#3 0x7f7036067711 in pixman_image_composite32 (op=op@entry=PIXMAN_OP_SRC,
src=optimized out, mask=mask@entry=0x0, dest=optimized out,
src_x=src_x@entry=0, src_y=src_y@entry=0, mask_x=0, mask_y=0, dest_x=0,
dest_y=0, width=1024, height=768) at ../../pixman/pixman.c:707
src_format = optimized out
mask_format = 0
dest_format = PIXMAN_a8r8g8b8
region = {extents = {x1 = 0, y1 = 0, x2 = 1024, y2 = 768}, data = 0x0}
extents = {x1 = 0, y1 = 0, x2 = 1024, y2 = 768}
imp = 0x7f7038e848a0
func = 0x7f70360ef9d0 sse2_composite_copy_area
info = {op =
Re: [Xen-devel] [PATCH v4 01/17] xen/arm: Add bitmap_find_next_zero_area helper function
On Fri, Jul 10, 2015 at 2:31 PM, Jan Beulich jbeul...@suse.com wrote: On 10.07.15 at 09:42, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com bitmap_find_next_zero_area helper function will be used by physical ITS driver. This is imported from linux version? Certainly not any 4.x, i.e. nothing reasonably recent. There is no recent changes to this file in linux. Below is the last commit that I have taken linux/log2.h: Fix rounddown_pow_of_two(1) (13c07b0286d340275f2d97adf085cecda37ede37) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-pvh-amd
On Fri, 2015-07-10 at 09:11 +, osstest service owner wrote: branch xen-unstable xen branch xen-unstable job test-amd64-amd64-xl-pvh-amd test xen-boot This is already fixed in staging (and the new test run is looking ok) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 4824bdfdabebd4042277461cb3cbefa61c624804 Bug not present: 0c0cbf72cf9f28070cc5d49955b0a00df5c1d114 commit 4824bdfdabebd4042277461cb3cbefa61c624804 Author: Chao Peng chao.p.p...@linux.intel.com Date: Tue Jul 7 15:42:49 2015 +0200 x86: add socket_cpumask Maintain socket_cpumask which contains all the HT and core siblings in the same socket. Signed-off-by: Chao Peng chao.p.p...@linux.intel.com Acked-by: Jan Beulich jbeul...@suse.com For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-pvh-amd.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Searching for failure / basis pass: 59207 fail [host=pinot1] / 59105 ok. Failure / basis pass flights: 59207 / 59105 (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git Latest a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 89483dc2b3eca29b9b104019bda1883c08150dc9 Basis pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c b9dbe33d15a038500bcc3226a3ca31ee215122cd Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#a0768244828d0da096ce957616150220da607be1-a0768244828d0da096ce957616150220da607be1 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#3e2e51ecc1120bd59537ed19b6bc7066511c7e2e-3e2e51ecc1120bd59537ed19b6bc7066511c7e2e git://xenbits.xen.org/staging/qemu-upstream-unstable.git#c4a962ec0c61aa9b860a3635c8424472e6c2cc2c-c4a962ec0c61aa9b860a3635c8424472e6c2cc2c git://xenbits.xen.org/xen.git#b9dbe33d15a038500bcc3226a3ca31ee215122cd-89483dc2b3eca29b9b104019bda1883c08150dc9 + exec + sh -xe + cd /home/osstest/repos/xen + git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /home/osstest/repos/xen + git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* Loaded 1001 nodes in revision graph Searching for test results: 59058 pass irrelevant 59160 fail a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 9a566a83d6374e7425bcb330e03c8ca9b31a0d0b 59105 pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c b9dbe33d15a038500bcc3226a3ca31ee215122cd 59297 pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c b9dbe33d15a038500bcc3226a3ca31ee215122cd 59276 pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 8022b05284dea80e24813d03180788ec7277a0bd 59270 fail a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 9a566a83d6374e7425bcb330e03c8ca9b31a0d0b 59203 pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c b9dbe33d15a038500bcc3226a3ca31ee215122cd 59288 pass a0768244828d0da096ce957616150220da607be1 c530a75c1e6a472b0eb9558310b518f0dfcd8860
Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
On Fri, 2015-07-10 at 13:40 +0800, Chen, Tiejun wrote:
tools/libxl/libxl_dom.c | 5 +++
tools/libxl/libxl_internal.h | 24 +
tools/libxl/libxl_x86.c | 83
...
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 62ef120..41da479 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1004,6 +1004,11 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
goto out;
}
+if (libxl__domain_construct_e820(gc, d_config, domid, args)) {
+LOG(ERROR, setting domain memory map failed);
+goto out;
+}
This is platform-independent code, isn't it ? In which case this will
break the build on ARM, I think.
Would an ARM maintainer please confirm.
I think you're right. I should make this specific to arch since here
we're talking e820.
So I tried to refactor this patch,
This approach looks like it should work, and I think given the point in
the release it would be acceptable for 4.6.
However long term I think it might make sense to try and reuse one of
the existing libxl__arch hooks, i.e.
libxl__arch_domain_init_hw_description or
libxl__arch_domain_finalise_hw_description. On ARM these are to do with
setting the Device Tree Blob, which included the memory map, so it is
somewhat morally equivalent to configuring the e820 on x86, I think.
Those hooks are only called from libxl__build_pv today, but calling them
from libxl__build_hvm seems like it would be good too.
In particular I think a call to
libxl__arch_domain_finalise_hw_description could be inserted just before
xc_hvm_build, which is similar to PV where it precedes
xc_dom_build_image, and is where you would want to setup the e820.
libxl__arch_domain_init_hw_description I think would still be a NOP on
x86, but it should probably go either just after the call to
libxl__domain_firmware.
Tiejun, would you be willing to commit to refactoring this and the
issues which Ian raised in response to #11 and #16 a subsequent clean up
series? I don't think it would even need to wait for the freeze to be
over to be posted (although it may need to wait to be applied).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 01/27] bsd-sys-queue-h-seddery: Massage `offsetof'
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote: From: Ian Jackson ian.jack...@eu.citrix.com For some reason BSD's queue.h uses `__offsetof'. It expects it to work just like offsetof. So use offsetof. Reported-by: Andrew Cooper andrew.coop...@citrix.com Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/15] x86/hvm: I/O emulation cleanup and fix | Full Backtrace of domU's X crash caused by SSE2 istruction in attachment
-Original Message- From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz] Sent: 10 July 2015 10:28 To: Paul Durrant; xen-devel@lists.xen.org Cc: Jan Beulich; Andrew Cooper Subject: Re: [Xen-devel] [PATCH v7 00/15] x86/hvm: I/O emulation cleanup and fix | Full Backtrace of domU's X crash caused by SSE2 istruction in attachment Il 09/07/2015 15:10, Paul Durrant ha scritto: This patch series re-works much of the code involved in emulation of port and memory mapped I/O for HVM guests. The code has become very convoluted and, at least by inspection, certain emulations will apparently malfunction. The series is broken down into 15 patches (which are also available in my xenbits repo: http://xenbits.xen.org/gitweb/?p=people/pauldu/xen.git on the emulation34 branch). Yesterday I retried with this version and seems that you fixed something that make possible atleast debug in the domU. I taken gdb data of X crash inside Sid hvm domU: #0 sse2_blt (src_bits=optimized out, dst_bits=optimized out, src_stride=optimized out, dst_stride=optimized out, src_bpp=optimized out, src_x=optimized out, src_y=0, dest_x=0, dest_y=0, width=1024, height=optimized out, dst_bpp=optimized out, imp=optimized out) at ../../pixman/pixman-sse2.c:4773 Latest istruction: = 0x7f70360ef8eb sse2_blt+459:movaps %xmm0,-0x10(%rsi) Full log in attachment. If you need more informations/tests tell me and I'll post them. I imagine you got a GP fault due to handle_mmio() returning X86EMUL_UNHANDLEABLE, but that's only a guess. I suggest you try to instrument Xen a little to find out why. Paul Thanks for any reply and sorry for my bad english. Previous changelog -- v4: - Removed previous patch (make sure translated MMIO reads or writes fall within a page) and rebased rest of series. - Address Jan's comments on patch #1 v3: - Addressed comments from Jan - Re-ordered series to bring a couple of more trivial patches to the front - Backport to XenServer (4.5) now passing automated tests - Tested on unstable with QEMU upstream and trad, with and without HAP (to force shadow emulation) v2: - Removed bogus assertion from patch #15 - Re-worked patch #17 after basic testing of back-port onto XenServer Subsequent changes are logged in the individual patch files (thanks to David Vrabel for that). Testing --- v6 of the series was been back-ported to staging-4.5 and then dropped onto the XenServer (Dundee) patch queue. All automated branch-safety tests pass. v7 has just been compile tested since changes were largely cosmetic. It will be back-ported in the near future. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 07/15] VMX: add VMFUNC leaf 0 (EPTP switching) to emulator.
On 10.07.15 at 02:52, edmund.h.wh...@intel.com wrote:
@@ -3234,6 +3256,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
update_guest_eip();
break;
+case EXIT_REASON_VMFUNC:
+if ( vmx_vmfunc_intercept(regs) == X86EMUL_EXCEPTION )
+hvm_inject_hw_exception(TRAP_invalid_op,
HVM_DELIVER_NO_ERROR_CODE);
+else
+update_guest_eip();
+break;
How about X86EMUL_UNHANDLEABLE and X86EMUL_RETRY? As said
before, either get this right, or simply fold the relatively pointless
helper into here.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3816,8 +3816,9 @@ x86_emulate(
struct segment_register reg;
unsigned long base, limit, cr0, cr0w;
-if ( modrm == 0xdf ) /* invlpga */
+switch( modrm )
{
+case 0xdf: /* invlpga AMD */
generate_exception_if(!in_protmode(ctxt, ops), EXC_UD, -1);
generate_exception_if(!mode_ring0(), EXC_GP, 0);
fail_if(ops-invlpg == NULL);
The diff now looks much better. Yet I don't see why you added AMD
to the comment - we don't elsewhere note that certain instructions
are vendor specific (and really which ones are also changes over time,
see RDTSCP for a prominent example).
@@ -3825,10 +3826,7 @@ x86_emulate(
ctxt)) )
goto done;
break;
-}
-
-if ( modrm == 0xf9 ) /* rdtscp */
-{
+case 0xf9: /* rdtscp */ {
uint64_t tsc_aux;
fail_if(ops-read_msr == NULL);
if ( (rc = ops-read_msr(MSR_TSC_AUX, tsc_aux, ctxt)) != 0 )
@@ -3836,7 +3834,19 @@ x86_emulate(
_regs.ecx = (uint32_t)tsc_aux;
goto rdtsc;
}
+case 0xd4: /* vmfunc */
+generate_exception_if(lock_prefix | rep_prefix() | (vex.pfx ==
vex_66),
+ EXC_UD, -1);
+fail_if(ops-vmfunc == NULL);
+if ( (rc = ops-vmfunc(ctxt) != X86EMUL_OKAY) )
+goto done;
+break;
+default:
+goto continue_grp7;
+}
+break;
+ continue_grp7:
Already when first looking at this I disliked this label. Looking at it
again, I'd really like to see it gone: RDTSCP handling already ends
in a goto. Since the only VMFUNC currently implemented doesn't
modify any register state either, its handling could end in an
unconditional goto done too for now. And INVLPG, not modifying
any register state, could follow suit.
And even if you really wanted to cater for future VMFUNCs to alter
register state, I'd still like this ugliness to be avoided - e.g. by
setting rc to a negative value before the switch and break-ing
afterwards when it's no longer negative.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 15/15] tools/xen-access: altp2m testcases
On Fri, 2015-07-10 at 09:55 +0100, Wei Liu wrote: On Fri, Jul 10, 2015 at 09:50:25AM +0100, Ian Campbell wrote: On Thu, 2015-07-09 at 17:52 -0700, Ed White wrote: From: Tamas K Lengyel tleng...@novetta.com Working altp2m test-case. Extended the test tool to support singlestepping to better highlight the core feature of altp2m view switching. Is this the only higher level tool integration which is required for this feature? I was expecting to see at a minimum some libxl/xl integration for enabling/disabling the feature on a per domain basis since AIUI it is a feature which is (or can be) exposed to the guest. There is xl/libxl integration in one patch, which is trivial at the moment. Thanks, armed with that I found it. I missed it the first time because the subject didn't mention the tools. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/27] tools/libxl: Introduce libxl__kill()
On 10/07/15 10:08, Wei Liu wrote:
On Thu, Jul 09, 2015 at 07:26:30PM +0100, Andrew Cooper wrote:
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 19fc425..9147de1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2244,6 +2244,8 @@ struct libxl__async_exec_state {
int libxl__async_exec_start(libxl__async_exec_state *aes);
bool libxl__async_exec_inuse(const libxl__async_exec_state *aes);
+void libxl__kill(libxl__gc *gc, pid_t pid, int sig, const char *what);
_hidden void ...
other than that:
Acked-by: Wei Liu wei.l...@citrix.com
D'oh - fixed as well.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/27] tools/libxl: Introduce libxl__kill()
On Fri, 2015-07-10 at 10:08 +0100, Wei Liu wrote:
On Thu, Jul 09, 2015 at 07:26:30PM +0100, Andrew Cooper wrote:
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 19fc425..9147de1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2244,6 +2244,8 @@ struct libxl__async_exec_state {
int libxl__async_exec_start(libxl__async_exec_state *aes);
bool libxl__async_exec_inuse(const libxl__async_exec_state *aes);
+void libxl__kill(libxl__gc *gc, pid_t pid, int sig, const char *what);
_hidden void ...
other than that:
Acked-by: Wei Liu wei.l...@citrix.com
Likewise.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 01/17] xen/arm: Add bitmap_find_next_zero_area helper function
On Fri, Jul 10, 2015 at 2:58 PM, Vijay Kilari vijay.kil...@gmail.com wrote: On Fri, Jul 10, 2015 at 2:31 PM, Jan Beulich jbeul...@suse.com wrote: On 10.07.15 at 09:42, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com bitmap_find_next_zero_area helper function will be used by physical ITS driver. This is imported from linux version? Certainly not any 4.x, i.e. nothing reasonably recent. There is no recent changes to this file in linux. Below is the last commit that I have taken linux/log2.h: Fix rounddown_pow_of_two(1) (13c07b0286d340275f2d97adf085cecda37ede37) Sorry. this is for log2.h not for this patch Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 06/27] tools/libxl: Split libxl__domain_create_state.restore_fd in two
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote: In a future patch, we shall support automatically converting a legacy stream to a v2 stream, in which case libxc needs to read from a different fd. Simply overwriting restore_fd does not work; the two fd's have different circumstances. The restore_fd needs to be returned to its origial state before libxl_domain_create_restore() returns, while in the converted case, the fd needs allocating and deallocating appropriately. No functional change. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 08/15] x86/altp2m: add control of suppress_ve.
On 10.07.15 at 02:52, edmund.h.wh...@intel.com wrote:
@@ -1528,16 +1528,17 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned
long gla,
vm_event_request_t *req;
int rc;
unsigned long eip = guest_cpu_user_regs()-eip;
+bool_t sve;
/* First, handle rx2rw conversion automatically.
* These calls to p2m-set_entry() must succeed: we have the gfn
* locked and just did a successful get_entry(). */
gfn_lock(p2m, gfn, 0);
-mfn = p2m-get_entry(p2m, gfn, p2mt, p2ma, 0, NULL);
+mfn = p2m-get_entry(p2m, gfn, p2mt, p2ma, 0, NULL, sve);
if ( npfec.write_access p2ma == p2m_access_rx2rw )
{
-rc = p2m-set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
p2m_access_rw);
+rc = p2m-set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt,
p2m_access_rw, sve);
ASSERT(rc == 0);
gfn_unlock(p2m, gfn, 0);
return 1;
@@ -1546,7 +1547,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long
gla,
{
ASSERT(npfec.write_access || npfec.read_access || npfec.insn_fetch);
rc = p2m-set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
-p2mt, p2m_access_rwx);
+p2mt, p2m_access_rwx, -1);
So why -1 here ...
@@ -1566,14 +1567,14 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned
long gla,
else
{
gfn_lock(p2m, gfn, 0);
-mfn = p2m-get_entry(p2m, gfn, p2mt, p2ma, 0, NULL);
+mfn = p2m-get_entry(p2m, gfn, p2mt, p2ma, 0, NULL, sve);
if ( p2ma != p2m_access_n2rwx )
{
/* A listener is not required, so clear the access
* restrictions. This set must succeed: we have the
* gfn locked and just did a successful get_entry(). */
rc = p2m-set_entry(p2m, gfn, mfn, PAGE_ORDER_4K,
-p2mt, p2m_access_rwx);
+p2mt, p2m_access_rwx, sve);
... but sve here, when -1 means retain current setting anyway?
(Same question applies elsewhere.)
While I'd preferable see this simplified, either way
Reviewed-by: Jan Beulich jbeul...@suse.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 10/15] x86/altp2m: add remaining support routines.
On 10.07.15 at 02:52, edmund.h.wh...@intel.com wrote: Add the remaining routines required to support enabling the alternate p2m functionality. So despite George's comments on v3 these are still all disconnected from their users... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 07/27] tools/libxl: Extra management APIs for the save helper
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote:
With migration v2, there are several moving parts needing to be juggled at
once. This requires the error handling logic to be able to query the state of
each moving part, possibly before they have been started, and be able to
cancel them.
Arguably helper_{stop,failed,done} all ought to be patched to use the
new libxl__save_helper_inuse helper. This isn't a blocker IMHO so,
nonetheless:
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 01/17] xen/arm: Add bitmap_find_next_zero_area helper function
On Fri, Jul 10, 2015 at 2:31 PM, Jan Beulich jbeul...@suse.com wrote: On 10.07.15 at 09:42, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com bitmap_find_next_zero_area helper function will be used by physical ITS driver. This is imported from linux version? Certainly not any 4.x, i.e. nothing reasonably recent. This is based on 3.18. However this function in 4.x is calling by bitmap_find_next_zero_area_off() with align_offset set to 0. So functionality wise this is same. Regards Vijay ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 09/27] docs: Libxl migration v2 stream specification
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote: Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com I think this is unchanged from last time, and my comments then were all either rebutted or of the it would be nice but not necessary if.. type. So: Acked-by: Ian Campbell ian.campb...@citrix.com I'm still going to nitick your spelling though :-) +self-contained, extensible stream with each layer responsibile for its own responsible +handed to `xc_domain_restore()`. `libxc` shall be resonsible for reading its Another one. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 12/27] tools/python: Other migration infrastructure
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote: Contains: * Reverse-engineered notes of the legacy format from xg_save_restore.h * Python implementation of the legacy format * Public HVM Params used in the legacy stream * XL header format Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 15/27] tools/libxl: Migration v2 stream format
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote: From: Ross Lagerwall ross.lagerw...@citrix.com C structures describing the Libxl migration v2 stream format Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com (I had an evil thought involving tools/libxl/libxl_types_internal.idl but I shall spare you that...) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 for Xen 4.6 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler
On Wed, 2015-07-08 at 18:16 -0700, Meng Xu wrote: 2015-07-08 1:33 GMT-07:00 Dario Faggioli dario.faggi...@citrix.com: Well, wouldn't the above reasoning about overhead apply here too? Budgets of 5us mean the scheduler can be invoked every 5us for budget enforcement. If 10us was unreasonable, 5 is even more so. Therefore, 100us here too? Or maybe let's allow for lower values (like 50us or 10us), but print a warning? Right. we can use 100us as a threadhold for budget too. Maybe printing warning is a better idea? If users know what they are doing and expecting, it is ok. But too small value (1us) will potentially cause system freeze. I'd be ok with printing a warning for vales below 100us, and rejecting values below 1us, or even below 10us (I don't think it would be that practical to go below that anyway). Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 07/27] tools/libxl: Extra management APIs for the save helper
On 10/07/15 10:41, Ian Campbell wrote:
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote:
With migration v2, there are several moving parts needing to be juggled at
once. This requires the error handling logic to be able to query the state
of
each moving part, possibly before they have been started, and be able to
cancel them.
Arguably helper_{stop,failed,done} all ought to be patched to use the
new libxl__save_helper_inuse helper.
So they should. Done.
~Andrew
This isn't a blocker IMHO so,
nonetheless:
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/15] x86/hvm: I/O emulation cleanup and fix | Full Backtrace of domU's X crash caused by SSE2 istruction in attachment
Il 10/07/2015 11:31, Paul Durrant ha scritto: -Original Message- From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz] Sent: 10 July 2015 10:28 To: Paul Durrant; xen-devel@lists.xen.org Cc: Jan Beulich; Andrew Cooper Subject: Re: [Xen-devel] [PATCH v7 00/15] x86/hvm: I/O emulation cleanup and fix | Full Backtrace of domU's X crash caused by SSE2 istruction in attachment Il 09/07/2015 15:10, Paul Durrant ha scritto: This patch series re-works much of the code involved in emulation of port and memory mapped I/O for HVM guests. The code has become very convoluted and, at least by inspection, certain emulations will apparently malfunction. The series is broken down into 15 patches (which are also available in my xenbits repo: http://xenbits.xen.org/gitweb/?p=people/pauldu/xen.git on the emulation34 branch). Yesterday I retried with this version and seems that you fixed something that make possible atleast debug in the domU. I taken gdb data of X crash inside Sid hvm domU: #0 sse2_blt (src_bits=optimized out, dst_bits=optimized out, src_stride=optimized out, dst_stride=optimized out, src_bpp=optimized out, src_x=optimized out, src_y=0, dest_x=0, dest_y=0, width=1024, height=optimized out, dst_bpp=optimized out, imp=optimized out) at ../../pixman/pixman-sse2.c:4773 Latest istruction: = 0x7f70360ef8eb sse2_blt+459:movaps %xmm0,-0x10(%rsi) Full log in attachment. If you need more informations/tests tell me and I'll post them. I imagine you got a GP fault due to handle_mmio() returning X86EMUL_UNHANDLEABLE, but that's only a guess. I suggest you try to instrument Xen a little to find out why. Thanks for reply, sorry but I not understand exactly what I must do. Can you detail please? Paul Thanks for any reply and sorry for my bad english. Previous changelog -- v4: - Removed previous patch (make sure translated MMIO reads or writes fall within a page) and rebased rest of series. - Address Jan's comments on patch #1 v3: - Addressed comments from Jan - Re-ordered series to bring a couple of more trivial patches to the front - Backport to XenServer (4.5) now passing automated tests - Tested on unstable with QEMU upstream and trad, with and without HAP (to force shadow emulation) v2: - Removed bogus assertion from patch #15 - Re-worked patch #17 after basic testing of back-port onto XenServer Subsequent changes are logged in the individual patch files (thanks to David Vrabel for that). Testing --- v6 of the series was been back-ported to staging-4.5 and then dropped onto the XenServer (Dundee) patch queue. All automated branch-safety tests pass. v7 has just been compile tested since changes were largely cosmetic. It will be back-ported in the near future. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen 4.6 development window closes today and other information
Hi all The development window of Xen 4.6 release closes today. I would like to thank everyone for their hard work to make this happen. Committers, please finish committing all pending patches as soon as possible. The cut off day for committing currently pending features is Friday next week. Maintainers, if you're aware of any patches that need to be committed please inform relevant committers and me. Please also CC me on any bug reports and bug fix patches during the freeze. Committers and maintainers, in next week we also need to review requests for freeze exception (if there is any). Contributors, to request for freeze exception please write email to xen-devel@, CC revelant maintainers and me, provide the information needed as described in [0]. Note that freeze exception can only be granted within next week. Wei. [0]: e1z8rcu-0003v6...@ukmail1.uk.xensource.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 11/15] x86/altp2m: define and implement alternate p2m HVMOP types.
On 10.07.15 at 02:52, edmund.h.wh...@intel.com wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -6443,6 +6443,144 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
break;
}
+case HVMOP_altp2m:
+{
+struct xen_hvm_altp2m_op a;
+struct domain *d = NULL;
+
+if ( copy_from_guest(a, arg, 1) )
+return -EFAULT;
+
+switch ( a.cmd )
+{
+case HVMOP_altp2m_get_domain_state:
+case HVMOP_altp2m_set_domain_state:
+case HVMOP_altp2m_create_p2m:
+case HVMOP_altp2m_destroy_p2m:
+case HVMOP_altp2m_switch_p2m:
+case HVMOP_altp2m_set_mem_access:
+case HVMOP_altp2m_change_gfn:
+d = rcu_lock_domain_by_any_id(a.domain);
+if ( d == NULL )
+return -ESRCH;
+
+if ( !is_hvm_domain(d) || !hvm_altp2m_supported() )
+rc = -EINVAL;
+
+break;
+case HVMOP_altp2m_vcpu_enable_notify:
+
+break;
The blank line ought to go ahead of the case label.
+default:
+return -ENOSYS;
+
+break;
Bogus (unreachable) break.
+}
+
+if ( !rc )
+{
+switch ( a.cmd )
+{
+case HVMOP_altp2m_get_domain_state:
+a.u.domain_state.state = altp2m_active(d);
+rc = __copy_to_guest(arg, a, 1) ? -EFAULT : 0;
+
+break;
+case HVMOP_altp2m_set_domain_state:
+{
+struct vcpu *v;
+bool_t ostate;
+
+if ( nestedhvm_enabled(d) )
+{
+rc = -EINVAL;
+break;
+}
+
+ostate = d-arch.altp2m_active;
+d-arch.altp2m_active = !!a.u.domain_state.state;
+
+/* If the alternate p2m state has changed, handle
appropriately */
+if ( d-arch.altp2m_active != ostate
+ (ostate || !(rc = p2m_init_altp2m_by_id(d, 0))) )
+{
+for_each_vcpu( d, v )
+{
+if ( !ostate )
+altp2m_vcpu_initialise(v);
+else
+altp2m_vcpu_destroy(v);
+}
+
+if ( ostate )
+p2m_flush_altp2m(d);
+}
+
+break;
+}
+default:
+{
Pointless brace.
+if ( !(d ? d : current-domain)-arch.altp2m_active )
This is bogus: d is NULL if and only if altp2m_vcpu_enable_notify,
i.e. I don't see why you can't just use current-domain inside that
case (and you really do). That would then also eliminate the need
for this redundant and obfuscating switch() nesting you use.
+
+struct xen_hvm_altp2m_set_mem_access {
+/* view */
+uint16_t view;
+/* Memory type */
+uint16_t hvmmem_access; /* xenmem_access_t */
+uint8_t pad[4];
+/* gfn */
+uint64_t gfn;
+};
+typedef struct xen_hvm_altp2m_set_mem_access
xen_hvm_altp2m_set_mem_access_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
+
+struct xen_hvm_altp2m_change_gfn {
+/* view */
+uint16_t view;
+uint8_t pad[6];
+/* old gfn */
+uint64_t old_gfn;
+/* new gfn, INVALID_GFN (~0UL) means revert */
+uint64_t new_gfn;
+};
+typedef struct xen_hvm_altp2m_change_gfn xen_hvm_altp2m_change_gfn_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_change_gfn_t);
+
+struct xen_hvm_altp2m_op {
+uint32_t cmd;
+/* Get/set the altp2m state for a domain */
+#define HVMOP_altp2m_get_domain_state 1
+#define HVMOP_altp2m_set_domain_state 2
+/* Set the current VCPU to receive altp2m event notifications */
+#define HVMOP_altp2m_vcpu_enable_notify 3
+/* Create a new view */
+#define HVMOP_altp2m_create_p2m 4
+/* Destroy a view */
+#define HVMOP_altp2m_destroy_p2m 5
+/* Switch view for an entire domain */
+#define HVMOP_altp2m_switch_p2m 6
+/* Notify that a page of memory is to have specific access types */
+#define HVMOP_altp2m_set_mem_access 7
+/* Change a p2m entry to have a different gfn-mfn mapping */
+#define HVMOP_altp2m_change_gfn 8
+domid_t domain;
+uint8_t pad[2];
While you added padding fields as asked for, you still don't verify
them to be zero on input.
Afaict all other questions raised on v3 still stand.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 01/17] xen/arm: Add bitmap_find_next_zero_area helper function
On 10.07.15 at 11:45, vijay.kil...@gmail.com wrote: On Fri, Jul 10, 2015 at 2:31 PM, Jan Beulich jbeul...@suse.com wrote: On 10.07.15 at 09:42, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com bitmap_find_next_zero_area helper function will be used by physical ITS driver. This is imported from linux version? Certainly not any 4.x, i.e. nothing reasonably recent. This is based on 3.18. However this function in 4.x is calling by bitmap_find_next_zero_area_off() with align_offset set to 0. So functionality wise this is same. Yeah, but why would we not take the most up-to-date variant? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] Modified RTDS scheduler to use an event-driven model instead of polling.
On Wed, 2015-07-08 at 20:46 -0700, Meng Xu wrote: 2015-07-08 1:01 GMT-07:00 Dario Faggioli dario.faggi...@citrix.com: But after thinking twice, maybe runq approach is a better way since it just make the position information more meaningful. As you described in the previous email, we can compare the position of a vcpu inserted into the runq with the number of pCPUs so as to quickly know which pCPU to tickle. I appreciate this is a rather big change (although, perhaps it looks bigger said than done), but I think it could be worth pursuing. It is worth pursuing since it simplify the cpu tickling process a lot. Great! :-) I think that I'd like to know why you think adding another queue is necessary, instead of just leaving the vCPUs in the actual runq. Is there something bad about that which I'm missing? Actually, nothing bad. I just recalled the situation when we split a runq to runq and delpetedq. I was thinking it might be the case here as well. (Yes, it is different here since we can get more useful information to tickle cpu if we put vCPUs into runq instead of adding one more queue.) :-) IMO, having things split could be beneficial for scalability *BUT* only in case we also get rid of the big spin lock. Until we won't get there (which is not that urgent) using the same queue is fine. For runq and depletedq, the same applies, with the small difference that, since both need to be sorted, having two actual queues looks easier than having just one with a marker, but that's only an implementation detail, it's fine however it is. OTOH, in this case, using runq only, without introducing another queue, actually helps making things simpler! Yes, but if we use two queues, we defeat at least part of this optimization/simplification. Agree. Thanks! :-D Perfect. Looking also at Dagaen replies, it sounds like we have a plan! Looking forward to see the code! :-D I don't think the added space would be a problem, but I don't see why we need it. If we don't add another queue, no extra space. So we get free lunch here. :-) Yeah, but let's not exaggerate with free lunches, I'm trying to loose some weight! :-P Thanks and Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/15] x86/hvm: I/O emulation cleanup and fix | Full Backtrace of domU's X crash caused by SSE2 istruction in attachment
Il 10/07/2015 11:54, Fabio Fantoni ha scritto: Il 10/07/2015 11:31, Paul Durrant ha scritto: -Original Message- From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz] Sent: 10 July 2015 10:28 To: Paul Durrant; xen-devel@lists.xen.org Cc: Jan Beulich; Andrew Cooper Subject: Re: [Xen-devel] [PATCH v7 00/15] x86/hvm: I/O emulation cleanup and fix | Full Backtrace of domU's X crash caused by SSE2 istruction in attachment Il 09/07/2015 15:10, Paul Durrant ha scritto: This patch series re-works much of the code involved in emulation of port and memory mapped I/O for HVM guests. The code has become very convoluted and, at least by inspection, certain emulations will apparently malfunction. The series is broken down into 15 patches (which are also available in my xenbits repo: http://xenbits.xen.org/gitweb/?p=people/pauldu/xen.git on the emulation34 branch). Yesterday I retried with this version and seems that you fixed something that make possible atleast debug in the domU. I taken gdb data of X crash inside Sid hvm domU: #0 sse2_blt (src_bits=optimized out, dst_bits=optimized out, src_stride=optimized out, dst_stride=optimized out, src_bpp=optimized out, src_x=optimized out, src_y=0, dest_x=0, dest_y=0, width=1024, height=optimized out, dst_bpp=optimized out, imp=optimized out) at ../../pixman/pixman-sse2.c:4773 Latest istruction: = 0x7f70360ef8eb sse2_blt+459:movaps %xmm0,-0x10(%rsi) Full log in attachment. If you need more informations/tests tell me and I'll post them. I imagine you got a GP fault due to handle_mmio() returning X86EMUL_UNHANDLEABLE, but that's only a guess. I suggest you try to instrument Xen a little to find out why. Thanks for reply, sorry but I not understand exactly what I must do. Can you detail please? I take a look in xen/arch/x86/x86_emulate/x86_emulate.c and the istruction seems like this other found by xengt developers: https://github.com/01org/XenGT-Preview-xen/commit/f2bad31f80f698a452c37cb39841da8e4f69350f Paul Thanks for any reply and sorry for my bad english. Previous changelog -- v4: - Removed previous patch (make sure translated MMIO reads or writes fall within a page) and rebased rest of series. - Address Jan's comments on patch #1 v3: - Addressed comments from Jan - Re-ordered series to bring a couple of more trivial patches to the front - Backport to XenServer (4.5) now passing automated tests - Tested on unstable with QEMU upstream and trad, with and without HAP (to force shadow emulation) v2: - Removed bogus assertion from patch #15 - Re-worked patch #17 after basic testing of back-port onto XenServer Subsequent changes are logged in the individual patch files (thanks to David Vrabel for that). Testing --- v6 of the series was been back-ported to staging-4.5 and then dropped onto the XenServer (Dundee) patch queue. All automated branch-safety tests pass. v7 has just been compile tested since changes were largely cosmetic. It will be back-ported in the near future. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/MSI: fix guest unmasking when handling IRQ via event channel
On Wed, 2015-07-08 at 09:56 +0100, Jan Beulich wrote: Rather than assuming only PV guests need special treatment (and dealing with that directly when an IRQ gets set up), keep all guest MSI IRQs masked until either the (HVM) guest unmasks them via vMSI or the (PV, PVHVM, or PVH) guest sets up an event channel for it. To not further clutter the common evtchn_bind_pirq() with x86-specific code, introduce an arch_evtchn_bind_pirq() hook instead. Reported-by: Sander Eikelenboom li...@eikelenboom.it Signed-off-by: Jan Beulich jbeul...@suse.com Tested-by: Sander Eikelenboom li...@eikelenboom.it For the ARM impact; Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 59302: tolerable FAIL - PUSHED
flight 59302 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59302/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59179
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59179
version targeted for testing:
ovmf 0f895683da0613f27ac460a69745a15571d2a2a9
baseline version:
ovmf e109e3fec9245e3fa777802d17e00431e349a6bd
Last test of basis59179 2015-07-08 01:15:55 Z2 days
Failing since 59220 2015-07-08 19:32:31 Z1 days2 attempts
Testing same since59302 2015-07-09 14:52:36 Z0 days1 attempts
People who touched revisions under test:
Brian J. Johnson bjohn...@sgi.com
Bruce Cran br...@cran.org.uk
Feng Tian feng.t...@intel.com
Fu Siyuan siyuan...@intel.com
Hess Chen hesheng.c...@intel.com
Jeff Fan jeff@intel.com
jiaxinwu jiaxin...@intel.com
Laszlo Ersek ler...@redhat.com
Olivier Martin olivier.mar...@arm.com
Qiu Shumin shumin@intel.com
Roy Franz roy.fr...@linaro.org
Ruiyu Ni ruiyu...@intel.com
Star Zeng star.z...@intel.com
Zhang Lubo lubo.zh...@intel.com
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=0f895683da0613f27ac460a69745a15571d2a2a9
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
0f895683da0613f27ac460a69745a15571d2a2a9
+ branch=ovmf
+ revision=0f895683da0613f27ac460a69745a15571d2a2a9
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
Re: [Xen-devel] [PATCH v5] x86/arm/mm: use gfn instead of pfn in p2m_get_mem_access/p2m_set_mem_access
On Fri, 2015-07-10 at 11:43 +0100, Jan Beulich wrote: On 02.07.15 at 18:14, julien.gr...@citrix.com wrote: On 02/07/15 14:18, Vitaly Kuznetsov wrote: 'pfn' and 'start_pfn' are ambiguous, both these functions expect GFNs as input. On x86 the interface of p2m_set_mem_access() in p2m.c doesn't match the declaration in p2m-common.h as 'pfn' is being used instead of 'start_pfn'. On ARM both p2m_set_mem_access and p2m_get_mem_access interfaces don't match declarations from p2m-common.h: p2m_set_mem_access uses 'pfn' instead of 'start_pfn' and p2m_get_mem_access uses 'gpfn' instead of 'pfn'. Convert p2m_get_mem_access/p2m_set_mem_access (and __p2m_get_mem_access on ARM) interfaces to using gft_t instead of unsigned long and update all users of these functions. There is also an issue in p2m_get_mem_access on x86: 'gfn' parameter passed to gfn_lock/gfn_unlock is not defined. This code compiles only because of a coincidence: gfn_lock/gfn_unlock are currently macros which don't use their second argument. Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com For the ARM bits: Reviewed-by: Julien Grall julien.gr...@citrix.com Any chance to get an ARM maintainer ack on this one? On the basis of Julien's R-by: Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [Patch V5 00/16] xen: support pv-domains larger than 512GB
Support 64 bit pv-domains with more than 512GB of memory. Following test have been done: - 64 bit dom0 on 8GB machine - 64 bit dom0 on 1TB machine (resolving p2m/E820-map conflict) - 32 bit dom0 on 8GB machine - 64 bit dom0 on 8GB machine with faked kernel/E820-map conflict - 64 bit dom0 on 8GB machine with faked pgtable/E820-map conflict - 64 bit dom0 on 8GB machine with faked initrd/E820-map conflict - 64 bit dom0 on 8GB machine with faked p2m/E820-map conflict - 64 bit domU (sizes up to 900GB) - 32 bit domU Changes in V5: - support architectures with undefined KERNEL_PAGE_RO in patch 12 - correct memblock_reserve() area of kernel page tables on 32 bit - add some more comments in patch 1 - some modifications in patch 13 (memblock_reserve for shared_info removed, for xenstore only necessary if not dom0) Changes in V4: - new patch 13 (add explicit memblock_reserve() calls for special pages) Changes in V3: - rename xen_chk_e820_reserved() to xen_is_e820_reserved() as requested by David Vrabel - add __initdata tag to global variables in patch 10 - move initrd conflict checking after reserving p2m memory (patch 11) Changes in V2: - some clarifications and better explanations in commit messages - add header changes of include/xen/interface/xen.h (patch 01) - add wmb() when incrementing p2m_generation (patch 02) - add new patch 03 (don't build mfn tree if tools don't need it) - add new patch 06 (split counting of extra memory pages from remapping) - add new patch 07 (check memory area against e820 map) - replace early_iounmap() with early_memunmap() (patch 07-patch 08) - rework patch 09 (check for kernel memory conflicting with memory layout) - rework patch 10 (check pre-allocated page tables for conflict with memory map) - combine old patches 08 and 11 into patch 11 - add new patch 12 (provide early_memremap_ro to establish read-only mapping) - rework old patch 12 (if p2m list located in to be remapped region delay remapping) to copy p2m list in case of a conflict (now patch 13) - correct Kconfig dependency (patch 13-14) - don't limit dom0 to 512GB (patch 13-14) - modify parameter parsing to work in very early boot (patch 13-14) - add new patch 15 to do some cleanup - remove old patch 05 (simplify xen_set_identity_and_remap() by using global variables) - remove old patch 08 (detect pre-allocated memory interfering with e820 map) Juergen Gross (16): xen: sync with xen headers xen: save linear p2m list address in shared info structure xen: don't build mfn tree if tools don't need it xen: eliminate scalability issues from initial mapping setup xen: move static e820 map to global scope xen: split counting of extra memory pages from remapping xen: check memory area against e820 map xen: find unused contiguous memory area xen: check for kernel memory conflicting with memory layout xen: check pre-allocated page tables for conflict with memory map xen: check for initrd conflicting with e820 map mm: provide early_memremap_ro to establish read-only mapping xen: add explicit memblock_reserve() calls for special pages xen: move p2m list if conflicting with e820 map xen: allow more than 512 GB of RAM for 64 bit pv-domains xen: remove no longer needed p2m.h Documentation/kernel-parameters.txt | 7 + arch/x86/include/asm/xen/interface.h | 96 +++- arch/x86/include/asm/xen/page.h | 8 +- arch/x86/xen/Kconfig | 20 +- arch/x86/xen/enlighten.c | 4 +- arch/x86/xen/mmu.c | 397 ++--- arch/x86/xen/p2m.c | 43 +++- arch/x86/xen/p2m.h | 15 -- arch/x86/xen/setup.c | 414 ++- arch/x86/xen/xen-head.S | 2 + arch/x86/xen/xen-ops.h | 7 + include/asm-generic/early_ioremap.h | 2 + include/asm-generic/fixmap.h | 3 + include/xen/interface/xen.h | 35 +-- mm/early_ioremap.c | 12 + 15 files changed, 867 insertions(+), 198 deletions(-) delete mode 100644 arch/x86/xen/p2m.h -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [Patch V5 06/16] xen: split counting of extra memory pages from remapping
Memory pages in the initial memory setup done by the Xen hypervisor
conflicting with the target E820 map are remapped. In order to do this
those pages are counted and remapped in xen_set_identity_and_remap().
Split the counting from the remapping operation to be able to setup
the needed memory sizes in time but doing the remap operation at a
later time. This enables us to simplify the interface to
xen_set_identity_and_remap() as the number of remapped and released
pages is no longer needed here.
Finally move the remapping further down to prepare relocating
conflicting memory contents before the memory might be clobbered by
xen_set_identity_and_remap(). This requires to not destroy the Xen
E820 map when the one for the system is being constructed.
Signed-off-by: Juergen Gross jgr...@suse.com
---
arch/x86/xen/setup.c | 98 +++-
1 file changed, 58 insertions(+), 40 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index ab6c36e..87251b4 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -223,7 +223,7 @@ static int __init xen_free_mfn(unsigned long mfn)
* as a fallback if the remapping fails.
*/
static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn,
- unsigned long end_pfn, unsigned long nr_pages, unsigned long *released)
+ unsigned long end_pfn, unsigned long nr_pages)
{
unsigned long pfn, end;
int ret;
@@ -243,7 +243,7 @@ static void __init
xen_set_identity_and_release_chunk(unsigned long start_pfn,
WARN(ret != 1, Failed to release pfn %lx err=%d\n, pfn, ret);
if (ret == 1) {
- (*released)++;
+ xen_released_pages++;
if (!__set_phys_to_machine(pfn, INVALID_P2M_ENTRY))
break;
} else
@@ -359,8 +359,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
*/
static unsigned long __init xen_set_identity_and_remap_chunk(
unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages,
- unsigned long remap_pfn, unsigned long *released,
- unsigned long *remapped)
+ unsigned long remap_pfn)
{
unsigned long pfn;
unsigned long i = 0;
@@ -385,7 +384,7 @@ static unsigned long __init
xen_set_identity_and_remap_chunk(
if (!remap_range_size) {
pr_warning(Unable to find available pfn range, not
remapping identity pages\n);
xen_set_identity_and_release_chunk(cur_pfn,
- cur_pfn + left, nr_pages, released);
+ cur_pfn + left, nr_pages);
break;
}
/* Adjust size to fit in current e820 RAM region */
@@ -397,7 +396,6 @@ static unsigned long __init
xen_set_identity_and_remap_chunk(
/* Update variables to reflect new mappings. */
i += size;
remap_pfn += size;
- *remapped += size;
}
/*
@@ -412,14 +410,11 @@ static unsigned long __init
xen_set_identity_and_remap_chunk(
return remap_pfn;
}
-static void __init xen_set_identity_and_remap(unsigned long nr_pages,
- unsigned long *released, unsigned long *remapped)
+static void __init xen_set_identity_and_remap(unsigned long nr_pages)
{
phys_addr_t start = 0;
unsigned long last_pfn = nr_pages;
const struct e820entry *entry = xen_e820_map;
- unsigned long num_released = 0;
- unsigned long num_remapped = 0;
int i;
/*
@@ -445,16 +440,12 @@ static void __init xen_set_identity_and_remap(unsigned
long nr_pages,
if (start_pfn end_pfn)
last_pfn = xen_set_identity_and_remap_chunk(
start_pfn, end_pfn, nr_pages,
- last_pfn, num_released,
- num_remapped);
+ last_pfn);
start = end;
}
}
- *released = num_released;
- *remapped = num_remapped;
-
- pr_info(Released %ld page(s)\n, num_released);
+ pr_info(Released %ld page(s)\n, xen_released_pages);
}
/*
@@ -560,6 +551,28 @@ static void __init xen_ignore_unusable(void)
}
}
+static unsigned long __init xen_count_remap_pages(unsigned long max_pfn)
+{
+ unsigned long extra = 0;
+ const struct e820entry *entry = xen_e820_map;
+ int i;
+
+ for (i = 0; i xen_e820_map_entries; i++, entry++) {
+ unsigned long start_pfn = PFN_DOWN(entry-addr);
+ unsigned long end_pfn = PFN_UP(entry-addr + entry-size);
+
+ if (start_pfn = max_pfn)
+
[Xen-devel] [Patch V5 02/16] xen: save linear p2m list address in shared info structure
The virtual address of the linear p2m list should be stored in the
shared info structure read by the Xen tools to be able to support
64 bit pv-domains larger than 512 GB. Additionally the linear p2m
list interface includes a generation count which is changed prior
to and after each mapping change of the p2m list. Reading the
generation count the Xen tools can detect changes of the mappings
and re-read the p2m list eventually.
Signed-off-by: Juergen Gross jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
arch/x86/xen/p2m.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8b7f18e..b89983e 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -263,6 +263,10 @@ void xen_setup_mfn_list_list(void)
HYPERVISOR_shared_info-arch.pfn_to_mfn_frame_list_list =
virt_to_mfn(p2m_top_mfn);
HYPERVISOR_shared_info-arch.max_pfn = xen_max_p2m_pfn;
+ HYPERVISOR_shared_info-arch.p2m_generation = 0;
+ HYPERVISOR_shared_info-arch.p2m_vaddr = (unsigned long)xen_p2m_addr;
+ HYPERVISOR_shared_info-arch.p2m_cr3 =
+ xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
}
/* Set up p2m_top to point to the domain-builder provided p2m pages */
@@ -478,8 +482,12 @@ static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t
*pte_pg)
ptechk = lookup_address(vaddr, level);
if (ptechk == pte_pg) {
+ HYPERVISOR_shared_info-arch.p2m_generation++;
+ wmb(); /* Tools are synchronizing via p2m_generation. */
set_pmd(pmdp,
__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+ wmb(); /* Tools are synchronizing via p2m_generation. */
+ HYPERVISOR_shared_info-arch.p2m_generation++;
pte_newpg[i] = NULL;
}
@@ -577,8 +585,12 @@ static bool alloc_p2m(unsigned long pfn)
spin_lock_irqsave(p2m_update_lock, flags);
if (pte_pfn(*ptep) == p2m_pfn) {
+ HYPERVISOR_shared_info-arch.p2m_generation++;
+ wmb(); /* Tools are synchronizing via p2m_generation. */
set_pte(ptep,
pfn_pte(PFN_DOWN(__pa(p2m)), PAGE_KERNEL));
+ wmb(); /* Tools are synchronizing via p2m_generation. */
+ HYPERVISOR_shared_info-arch.p2m_generation++;
if (mid_mfn)
mid_mfn[mididx] = virt_to_mfn(p2m);
p2m = NULL;
@@ -630,6 +642,11 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned
long mfn)
return true;
}
+ /*
+* The interface requires atomic updates on p2m elements.
+* xen_safe_write_ulong() is using __put_user which does an atomic
+* store via asm().
+*/
if (likely(!xen_safe_write_ulong(xen_p2m_addr + pfn, mfn)))
return true;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [Patch V5 04/16] xen: eliminate scalability issues from initial mapping setup
Direct Xen to place the initial P-M table outside of the initial
mapping, as otherwise the 1G (implementation) / 2G (theoretical)
restriction on the size of the initial mapping limits the amount
of memory a domain can be handed initially.
As the initial P-M table is copied rather early during boot to
domain private memory and it's initial virtual mapping is dropped,
the easiest way to avoid virtual address conflicts with other
addresses in the kernel is to use a user address area for the
virtual address of the initial P-M table. This allows us to just
throw away the page tables of the initial mapping after the copy
without having to care about address invalidation.
It should be noted that this patch won't enable a pv-domain to USE
more than 512 GB of RAM. It just enables it to be started with a
P-M table covering more memory. This is especially important for
being able to boot a Dom0 on a system with more than 512 GB memory.
Signed-off-by: Juergen Gross jgr...@suse.com
Based-on-patch-by: Jan Beulich jbeul...@suse.com
---
arch/x86/xen/mmu.c | 126
arch/x86/xen/setup.c| 67 ++---
arch/x86/xen/xen-head.S | 2 +
3 files changed, 156 insertions(+), 39 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index dd151b2..c04e14e 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1114,6 +1114,77 @@ static void __init xen_cleanhighmap(unsigned long vaddr,
xen_mc_flush();
}
+/*
+ * Make a page range writeable and free it.
+ */
+static void __init xen_free_ro_pages(unsigned long paddr, unsigned long size)
+{
+ void *vaddr = __va(paddr);
+ void *vaddr_end = vaddr + size;
+
+ for (; vaddr vaddr_end; vaddr += PAGE_SIZE)
+ make_lowmem_page_readwrite(vaddr);
+
+ memblock_free(paddr, size);
+}
+
+static void __init xen_cleanmfnmap_free_pgtbl(void *pgtbl)
+{
+ unsigned long pa = __pa(pgtbl) PHYSICAL_PAGE_MASK;
+
+ ClearPagePinned(virt_to_page(__va(pa)));
+ xen_free_ro_pages(pa, PAGE_SIZE);
+}
+
+/*
+ * Since it is well isolated we can (and since it is perhaps large we should)
+ * also free the page tables mapping the initial P-M table.
+ */
+static void __init xen_cleanmfnmap(unsigned long vaddr)
+{
+ unsigned long va = vaddr PMD_MASK;
+ unsigned long pa;
+ pgd_t *pgd = pgd_offset_k(va);
+ pud_t *pud_page = pud_offset(pgd, 0);
+ pud_t *pud;
+ pmd_t *pmd;
+ pte_t *pte;
+ unsigned int i;
+
+ set_pgd(pgd, __pgd(0));
+ do {
+ pud = pud_page + pud_index(va);
+ if (pud_none(*pud)) {
+ va += PUD_SIZE;
+ } else if (pud_large(*pud)) {
+ pa = pud_val(*pud) PHYSICAL_PAGE_MASK;
+ xen_free_ro_pages(pa, PUD_SIZE);
+ va += PUD_SIZE;
+ } else {
+ pmd = pmd_offset(pud, va);
+ if (pmd_large(*pmd)) {
+ pa = pmd_val(*pmd) PHYSICAL_PAGE_MASK;
+ xen_free_ro_pages(pa, PMD_SIZE);
+ } else if (!pmd_none(*pmd)) {
+ pte = pte_offset_kernel(pmd, va);
+ for (i = 0; i PTRS_PER_PTE; ++i) {
+ if (pte_none(pte[i]))
+ break;
+ pa = pte_pfn(pte[i]) PAGE_SHIFT;
+ xen_free_ro_pages(pa, PAGE_SIZE);
+ }
+ xen_cleanmfnmap_free_pgtbl(pte);
+ }
+ va += PMD_SIZE;
+ if (pmd_index(va))
+ continue;
+ xen_cleanmfnmap_free_pgtbl(pmd);
+ }
+
+ } while (pud_index(va) || pmd_index(va));
+ xen_cleanmfnmap_free_pgtbl(pud_page);
+}
+
static void __init xen_pagetable_p2m_free(void)
{
unsigned long size;
@@ -1128,18 +1199,25 @@ static void __init xen_pagetable_p2m_free(void)
/* using __ka address and sticking INVALID_P2M_ENTRY! */
memset((void *)xen_start_info-mfn_list, 0xff, size);
- /* We should be in __ka space. */
- BUG_ON(xen_start_info-mfn_list __START_KERNEL_map);
addr = xen_start_info-mfn_list;
- /* We roundup to the PMD, which means that if anybody at this stage is
-* using the __ka address of xen_start_info or
xen_start_info-shared_info
-* they are in going to crash. Fortunatly we have already revectored
-* in xen_setup_kernel_pagetable and in xen_setup_shared_info. */
+ /*
+* We could be in __ka space.
+* We roundup to the PMD, which means that if anybody at this stage is
+* using the __ka address of xen_start_info or
+*
[Xen-devel] [Patch V5 09/16] xen: check for kernel memory conflicting with memory layout
Checks whether the pre-allocated memory of the loaded kernel is in
conflict with the target memory map. If this is the case, just panic
instead of run into problems later, as there is nothing we can do
to repair this situation.
Signed-off-by: Juergen Gross jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
arch/x86/xen/setup.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 973d294..9bd3f35 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -27,6 +27,7 @@
#include xen/interface/memory.h
#include xen/interface/physdev.h
#include xen/features.h
+#include xen/hvc-console.h
#include xen-ops.h
#include vdso.h
#include p2m.h
@@ -790,6 +791,17 @@ char * __init xen_memory_setup(void)
sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), e820.nr_map);
+ /*
+* Check whether the kernel itself conflicts with the target E820 map.
+* Failing now is better than running into weird problems later due
+* to relocating (and even reusing) pages with kernel text or data.
+*/
+ if (xen_is_e820_reserved(__pa_symbol(_text),
+ __pa_symbol(__bss_stop) - __pa_symbol(_text))) {
+ xen_raw_console_write(Xen hypervisor allocated kernel memory
conflicts with E820 map\n);
+ BUG();
+ }
+
xen_reserve_xen_mfnlist();
/*
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [Patch V5 03/16] xen: don't build mfn tree if tools don't need it
In case the Xen tools indicate they don't need the p2m 3 level tree as they support the virtual mapped linear p2m list, just omit building the tree. Signed-off-by: Juergen Gross jgr...@suse.com Reviewed-by: David Vrabel david.vra...@citrix.com --- arch/x86/xen/p2m.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index b89983e..c719f7c 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -199,7 +199,8 @@ void __ref xen_build_mfn_list_list(void) unsigned int level, topidx, mididx; unsigned long *mid_mfn_p; - if (xen_feature(XENFEAT_auto_translated_physmap)) + if (xen_feature(XENFEAT_auto_translated_physmap) || + xen_start_info-flags SIF_VIRT_P2M_4TOOLS) return; /* Pre-initialize p2m_top_mfn to be completely missing */ @@ -260,8 +261,11 @@ void xen_setup_mfn_list_list(void) BUG_ON(HYPERVISOR_shared_info == xen_dummy_shared_info); - HYPERVISOR_shared_info-arch.pfn_to_mfn_frame_list_list = - virt_to_mfn(p2m_top_mfn); + if (xen_start_info-flags SIF_VIRT_P2M_4TOOLS) + HYPERVISOR_shared_info-arch.pfn_to_mfn_frame_list_list = ~0UL; + else + HYPERVISOR_shared_info-arch.pfn_to_mfn_frame_list_list = + virt_to_mfn(p2m_top_mfn); HYPERVISOR_shared_info-arch.max_pfn = xen_max_p2m_pfn; HYPERVISOR_shared_info-arch.p2m_generation = 0; HYPERVISOR_shared_info-arch.p2m_vaddr = (unsigned long)xen_p2m_addr; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [Patch V5 08/16] xen: find unused contiguous memory area
For being able to relocate pre-allocated data areas like initrd or
p2m list it is mandatory to find a contiguous memory area which is
not yet in use and doesn't conflict with the memory map we want to
be in effect.
In case such an area is found reserve it at once as this will be
required to be done in any case.
Signed-off-by: Juergen Gross jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
arch/x86/xen/setup.c | 34 ++
arch/x86/xen/xen-ops.h | 1 +
2 files changed, 35 insertions(+)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 99ef82c..973d294 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -597,6 +597,40 @@ bool __init xen_is_e820_reserved(phys_addr_t start,
phys_addr_t size)
}
/*
+ * Find a free area in physical memory not yet reserved and compliant with
+ * E820 map.
+ * Used to relocate pre-allocated areas like initrd or p2m list which are in
+ * conflict with the to be used E820 map.
+ * In case no area is found, return 0. Otherwise return the physical address
+ * of the area which is already reserved for convenience.
+ */
+phys_addr_t __init xen_find_free_area(phys_addr_t size)
+{
+ unsigned mapcnt;
+ phys_addr_t addr, start;
+ struct e820entry *entry = xen_e820_map;
+
+ for (mapcnt = 0; mapcnt xen_e820_map_entries; mapcnt++, entry++) {
+ if (entry-type != E820_RAM || entry-size size)
+ continue;
+ start = entry-addr;
+ for (addr = start; addr start + size; addr += PAGE_SIZE) {
+ if (!memblock_is_reserved(addr))
+ continue;
+ start = addr + PAGE_SIZE;
+ if (start + size entry-addr + entry-size)
+ break;
+ }
+ if (addr = start + size) {
+ memblock_reserve(start, size);
+ return start;
+ }
+ }
+
+ return 0;
+}
+
+/*
* Reserve Xen mfn_list.
* See comment above struct start_info in xen/interface/xen.h
* We tried to make the the memblock_reserve more selective so
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index c3629bd..f189684 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -43,6 +43,7 @@ bool __init xen_is_e820_reserved(phys_addr_t start,
phys_addr_t size);
unsigned long __ref xen_chk_extra_mem(unsigned long pfn);
void __init xen_inv_extra_mem(void);
void __init xen_remap_memory(void);
+phys_addr_t __init xen_find_free_area(phys_addr_t size);
char * __init xen_memory_setup(void);
char * xen_auto_xlated_memory_setup(void);
void __init xen_arch_setup(void);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 06/15] vmx: Extend struct pi_desc to support VT-d Posted-Interrupts
On 24.06.15 at 07:18, feng...@intel.com wrote:
@@ -81,8 +81,19 @@ struct vmx_domain {
struct pi_desc {
DECLARE_BITMAP(pir, NR_VECTORS);
-u32 control;
-u32 rsvd[7];
+union {
+struct
+{
+u16 on : 1, /* bit 256 - Outstanding Notification */
+sn : 1, /* bit 257 - Suppress Notification */
+rsvd_1 : 14; /* bit 271:258 - Reserved */
+u8 nv; /* bit 279:272 - Notification Vector */
+u8 rsvd_2; /* bit 287:280 - Reserved */
+u32 ndst;/* bit 319:288 - Notification Destination */
+};
+u64 control;
+};
So current code, afaics, uses e.g. test_and_set_bit() to set ON.
By also declaring this as a bitfield you're opening the structure for
non-atomic accesses. If that's correct, why is other code not
being changed to _only_ use the bitfield mechanism (likely also
eliminating the need for it being a union with the now 64-bit
control? If atomic accesses are required, then I'd strongly
suggest against making this a bit field.
And in no event can I see why ndst needs to be union-ized
with control if it doesn't need to be updated atomically with
e.g. nv.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest
Chen, Tiejun writes (Re: [v7][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest): I think you're right. I should make this specific to arch since here we're talking e820. So I tried to refactor this patch, That looks good to me. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 17/27] tools/libxl: Support converting a legacy stream to a v2 stream
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote: When a legacy stream is found, it needs to be converted to a v2 stream for the reading logic. This is done by exec()ing the python conversion utility. One complication is that the caller of this interface needs to assume ownership of the output fd, to prevent it being closed while still in use in a datacopier. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com I think various internals should use the libxl__convert_legacy_stream_inuse helper. With that: Acked-by: Ian Campbell ian.campb...@citrix.com Perhaps libxl__conversion_helper_state could become empty on !x86? My Ack stands either way. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 18/27] tools/libxl: Convert a legacy stream if needed
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote: For backwards compatibility, a legacy stream needs converting before it can be read by the v2 stream logic. This causes the v2 stream logic to need to juggle two parallel tasks. check_stream_finished() is introduced for the purpose of joining the tasks in both success and error cases. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/9] libxl: poll: Use poller_get and poller_put for poller_app
On Thu, Jul 09, 2015 at 06:47:50PM +0100, Ian Jackson wrote: This makes the code more regular. We are going to want to do some more work in poller_get and poller_put, which work also wants to be done for poller_app. Two very minor functional changes: * We call malloc an extra time since poller_app is now a pointer * ERROR_FAIL on poller_get failing for poller_app is generated in libxl_ctx_init rather than passed through by libxl_poller_init from libxl__pipe_nonblock. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com CC: Jim Fehlig jfeh...@suse.com Acked-by: Wei Liu wei.l...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/9] libxl: poll: Make libxl__poller_get have only one success return path
On Thu, Jul 09, 2015 at 06:47:49PM +0100, Ian Jackson wrote: In preparation for doing some more work on successful exit. No functional change. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com CC: Jim Fehlig jfeh...@suse.com Acked-by: Wei Liu wei.l...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/15] x86/hvm: I/O emulation cleanup and fix | Full Backtrace of domU's X crash caused by SSE2 istruction in attachment
Hi Gurus: We found that MOVD instruction are used by some windows driver during developing XenGT, and also we found this one: (XEN) MMIO emulation failed: d7v1 64bit @ 0010:f8000294e273 - 66 0f e7 00 48 83 c0 10 45 3 b cb 73 f0 45 85 c9 If anyone can help us to upstream this one into instruction emulator and plus the MOVD instruction emulation, that will be nice. :) Thanks, Zhi. δΊ 07/10/15 19:00, Jan Beulich ει: On 10.07.15 at 12:51, fabio.fant...@m2r.biz wrote: Il 10/07/2015 12:20, Jan Beulich ha scritto: Other than MOVD, MOVAPS is already being supported by the insn emulator. Then why do you think MOVAPS fails in my test? No idea. That's what Paul asked you to narrow down. Sse2 was introduced in cpus 11 years ago, so I think it would be useful to add support for all missing instructions to avoid more cases like this (and it seems to improve performance too, comparing the same task executed with/without sse2). The reason we didn't add any more of the SSE insns so far is that we don't expect them to be used for accessing MMIO. Once we learn they're needed, we'll add emulation for them, but you realize this is a significant task? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 16/27] tools/libxl: Infrastructure for reading a libxl migration v2 stream
Andrew Cooper writes (Re: [PATCH v2 16/27] tools/libxl: Infrastructure for
reading a libxl migration v2 stream):
On 10/07/15 11:23, Ian Campbell wrote:
+void libxl__stream_read_start(libxl__egc *egc,
+ libxl__stream_read_state *stream)
+{
+libxl__datacopier_state *dc = stream-dc;
+int ret = 0;
+
+/* State initialisation. */
+assert(!stream-running);
Since running is declared private and there is no _init function (I
think _start is effectively filling that role) I'm not sure that the
caller can necessarily be expected to have initialised anything other
than the ao, fd and callback fields.
It was a sanity check that _start() doesn't get called twice (guess what
I managed to do while developing). It can probably be dropped.
I don't mind this at all but I think if you do this you should:
* provide an _init method
* document that _init must be called before start
You might choose to handle this as a request for a doc comment (must
call LIBXL_FILLZERO on it to init), or to add a separate init function
containing the memset or to do away with this check. I've not gotten to
the caller yet so I don't know which you will prefer.
It is all zeroed because of the way dcs is constructed. I suppose I can
also drop the zeroing of the dc.
Providing an init method would mean that if this thing needs to grow
calls to sub-states' init methods, there is somewhere to put them.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 18/27] tools/libxl: Convert a legacy stream if needed
Andrew Cooper writes ([PATCH v2 18/27] tools/libxl: Convert a legacy stream if
needed):
For backwards compatibility, a legacy stream needs converting before it can be
read by the v2 stream logic.
This causes the v2 stream logic to need to juggle two parallel tasks.
check_stream_finished() is introduced for the purpose of joining the tasks in
both success and error cases.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_internal.h|7 +++
tools/libxl/libxl_stream_read.c | 98
++-
2 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 68e7f02..1cf1884 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3274,6 +3274,7 @@ struct libxl__stream_read_state {
/* filled by the user */
libxl__ao *ao;
int fd;
+bool legacy;
void (*completion_callback)(libxl__egc *egc,
libxl__stream_read_state *srs,
int rc);
@@ -3281,6 +3282,12 @@ struct libxl__stream_read_state {
int rc;
bool running;
+/* Active-stuff handling */
+int joined_rc;
+
+/* Conversion helper */
+libxl__carefd *v2_carefd;
This needs proper documentation of what states this is valid in. See
my observations on 16/ about this. I would expect that this patch
would add appropriate commentary documenting the
invariants/states/whatever for these.
+static void check_stream_finished(libxl__egc *egc,
+ libxl__stream_read_state *stream,
+ int rc, const char *what)
+{
+libxl__domain_create_state *dcs = CONTAINER_OF(stream, *dcs, srs);
+STATE_AO_GC(stream-ao);
+
+LOG(DEBUG, Task '%s' joining (rc %d), what, rc);
+
+if (rc !stream-joined_rc) {
+bool skip = false;
+/* First reported failure from joining tasks. Tear everything down
*/
+stream-joined_rc = rc;
This function has room for improvement, I think.
* You compute
libxl__stream_read_inuse(dcs-srs) ||
libxl__convert_legacy_stream_inuse(dcs-chs)
twice, once in the if (rc ...) and once in the straight line.
You could combine these.
* I think libxl__blah_abort are all no-ops on initialised but inactive
objects. (Ie, objects in state Idle.) So you can call them
unconditionally.
* I don't think joined_rc is particularly helpful. Why not simply
combine the incoming rc with the existing rc ? That is, if nothing
has gone wrong already, set the rc to the incoming one; otherwise
keep the existing rc. That assumes that the best rc value to report
is the one from the first detected problem, which is probably
correct. (Consider ERROR_ABORTED.)
+#if defined(__x86_64__) || defined(__i386__)
+static void conversion_done(libxl__egc *egc,
+libxl__conversion_helper_state *chs, int rc)
+{
+STATE_AO_GC(chs-ao);
+libxl__domain_create_state *dcs = CONTAINER_OF(chs, *dcs, chs);
+
+check_stream_finished(egc, dcs-srs, rc, conversion);
+}
+#endif
Again, I would prefer to avoid the ifdeffery if it's not terribly
awkward to do the other way (see libxl_no*.c for some examples). If
you do invent ifdeffery it should definitely have its own #define to
trigger off, rather than directly using __x86_64__ etc.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 16/27] tools/libxl: Infrastructure for reading a libxl migration v2 stream
On 10/07/15 13:46, Ian Jackson wrote: Andrew Cooper writes (Re: [PATCH v2 16/27] tools/libxl: Infrastructure for reading a libxl migration v2 stream): On 10/07/15 12:25, Ian Campbell wrote: Do you mean they would do so legitimately in that case, or in error? It is wrong in all cases to mutually recurse like this. The data controlling the degree of mutual recursion is read from a pipe. The issue with the TOOLSTACK record is that it a synchronous library call, not an aync one. This is not a problem pe say, but it means that process_record() must queue something further to do. In a checkpoint it is possible (although very unlikely) to have $N thousand TOOLSTACK records back to back. The guards are in place to prevent introducing a codepath which does end up in mutual recursion. Such a calltree would function for any reasonable input, but would fall off the stack given a certain sequence of records. I just wanted to say that I have read this and it helps my understanding but I still worry about the correctness of stream_continue and process_record if the queue has more than one record. This might also make more sense with the context from patch 25, which is where the Remus/COLO buffering is introduced. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 9/9] libxl: event tests: test_timedereg: Fix rc handling
On Thu, Jul 09, 2015 at 06:47:57PM +0100, Ian Jackson wrote:
In 31c836f4 libxl: events: Permit timeouts to signal ao abort,
timeout callbacks take an extra rc argument.
In that patch the wrong assertion is made about the rc in
test_timedereg's `occurs' callback. Fix this to make the test pass
again.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Acked-by: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_test_timedereg.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_test_timedereg.c
b/tools/libxl/libxl_test_timedereg.c
index c464663..a567db6 100644
--- a/tools/libxl/libxl_test_timedereg.c
+++ b/tools/libxl/libxl_test_timedereg.c
@@ -67,7 +67,7 @@ static void occurs(libxl__egc *egc, libxl__ev_time *ev,
int off = ev - et[0][0];
LOG(DEBUG,occurs[%d][%d] seq=%d rc=%d, off/NTIMES, off%NTIMES, seq,
rc);
-assert(!rc);
+assert(rc == ERROR_TIMEDOUT);
switch (seq) {
case 0:
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Requesting for freeze exception for ARM/ITS patches
Hi Wei, I would like to have freeze exception for ITS feature on ARM64. Design got freeze few weeks back and I have sent v4 version of patch series today. This patches will not impact any generic code of other platforms and have minor changes generic arm related code. Also these patches are only for ARM64 platform. These patches are pre-requisite for PCI support / Pass-through support on ARM64 platforms. The risk is minor and as of today only used by Cavium ThunderX platform. Regards Vijay ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 8/9] libxl: event tests: Introduce `fdderegrace' test
On Thu, Jul 09, 2015 at 06:47:56PM +0100, Ian Jackson wrote: This exercises the potential race between fd deregistration and poll(). (Because we have control of the individual steps, we can do the whole test in a single thread and ensure that the pessimal order is always reached.) Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Wei Liu wei.l...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 19/27] tools/libxc+libxl+xl: Restore v2 streams
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote:
#define LIBXL_HAVE_SOCKET_BITMAP_ALLOC 1
+/*
+ * LIBXL_HAVE_STREAM_V2
These all need another word in them I think. _MIGRATION_, or _SRM_
or ... (I think I prefer SRM since migration is just one aspect)
@@ -439,6 +447,28 @@ static void record_body_done(libxl__egc *egc,
stream_failed(egc, stream, ret);
}
+void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
+ int ret, int retval, int errnoval)
+{
+libxl__domain_create_state *dcs = dcs_void;
+STATE_AO_GC(dcs-ao);
+
+if (ret)
+goto err;
+
+if (retval) {
+LOGEV(ERROR, errnoval, restoring domain);
+ret = ERROR_FAIL;
+goto err;
+}
+
+stream_continue(egc, dcs-srs);
This confused me briefly (done==continue??), a comment indicating that
this callback represents libxc handing back control of the fd to libxl
would maybe be useful?
With those two minor tweaks,
Acked-by: Ian Campbell ian.campb...@citrix.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 20/27] tools/libxl: Infrastructure for writing a v2 stream
On 10/07/15 11:55, Ian Campbell wrote:
On Mon, 2015-06-15 at 14:44 +0100, Andrew Cooper wrote:
+void libxl__stream_write_start(libxl__egc *egc,
+ libxl__stream_write_state *stream)
+{
+libxl__datacopier_state *dc = stream-dc;
+STATE_AO_GC(stream-ao);
+struct libxl_sr_hdr hdr = { 0 };
+int ret = 0;
+
+assert(!stream-running);
This has the same issue wrt who initialises this when as the restore
side.
+stream-running = true;
+
+memset(dc, 0, sizeof(*dc));
+dc-readwhat = ;
+dc-copywhat = suspend header;
+dc-writewhat = save/migration stream;
+dc-ao = ao;
+dc-readfd = -1;
+dc-writefd = stream-fd;
+dc-maxsz = INT_MAX;
+dc-bytes_to_read = INT_MAX;
+dc-callback = stream_header_done;
On the read side some of this was nicely encapsulated in a helper. Not a
blocker, just an observation for a potential future tidying.
So, the only immediate issue is the -running one, which I suppose will
be discussed on the restore side patch and the same conclusion applied
here.
You realise you have moved back onto v1 of the series? This is very
different in v2.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 25/27] tools/libxl: Handle checkpoint records in a libxl migration v2 stream
On Thu, 2015-07-09 at 19:26 +0100, Andrew Cooper wrote:
@@ -3349,6 +3353,8 @@ struct libxl__stream_read_state {
LIBXL_STAILQ_HEAD(, libxl__sr_record_buf) record_queue;
enum {
SRS_PHASE_NORMAL,
+SRS_PHASE_BUFFERING,
+SRS_PHASE_UNBUFFERING,
I'd be inclined towards calling the latter DRAINING or PROCESSING or
some such, perhaps tying into my comment about the separate recursion
guard thing earlier on in the series.
But that's a bikeshedding issue on an internal thing so my only real
comment is:
+if (rc == 0)
+ret = 0; /* Success */
+else if (stream-phase == SRS_PHASE_BUFFERING)
+ret = 2; /* Failover */
+else
+ret = 1; /* Error (fatal) */
Maybe we should have had an enum or some #defines for these (this is
really a comment on some previous patch).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 00/15] x86/hvm: I/O emulation cleanup and fix | Full Backtrace of domU's X crash caused by SSE2 istruction in attachment
On 09.07.15 at 21:32, zhi.a.w...@intel.com wrote: We found that MOVD instruction are used by some windows driver during developing XenGT, and also we found this one: (XEN) MMIO emulation failed: d7v1 64bit @ 0010:f8000294e273 - 66 0f e7 00 48 83 c0 10 45 3 b cb 73 f0 45 85 c9 If anyone can help us to upstream this one into instruction emulator and plus the MOVD instruction emulation, that will be nice. :) The thread you hijacked already references a patch to that effect; I don't recall it having got submitted formally, hence it's not clear what help us to upstream really is supposed to mean here. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 16/27] tools/libxl: Infrastructure for reading a libxl migration v2 stream
On 10/07/15 12:25, Ian Campbell wrote:
+
+stream-completion_callback(egc, stream, stream-rc);
+}
+
+static void stream_continue(libxl__egc *egc,
+libxl__stream_read_state *stream)
+{
+STATE_AO_GC(stream-ao);
+
+/* Must not mutually recurse with process_record() */
+assert(stream-recursion_guard == false);
+stream-recursion_guard = true;
This smells a bit like it ought to be a SRS_PHASE_PROCESSING or some
such, but lets leave that alone...
This check is pre-emptively avoid the naive bug which would occur if
process_record() called back into stream_continue() and there were many
TOOLSTACK records back to back in the processing queue.
In that case (and potentially future records as well), the two functions
would mutually recurse based on the contents of the stream.
Do you mean they would do so legitimately in that case, or in error?
It is wrong in all cases to mutually recurse like this. The data
controlling the degree of mutual recursion is read from a pipe.
The issue with the TOOLSTACK record is that it a synchronous library
call, not an aync one. This is not a problem pe say, but it means that
process_record() must queue something further to do.
In a checkpoint it is possible (although very unlikely) to have $N
thousand TOOLSTACK records back to back.
The guards are in place to prevent introducing a codepath which does end
up in mutual recursion. Such a calltree would function for any
reasonable input, but would fall off the stack given a certain sequence
of records.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
