Re: [Xen-devel] ./configure: line 7058: python-config: command not found after commit 0013245
Ian Campbell writes (Re: ./configure: line 7058: python-config: command not found after commit 0013245): On Wed, 2015-03-04 at 15:02 +0100, Roger Pau Monné wrote: Yes, I think so, for python versions 2.4 we should require python-config. ACK. IMHO python_fortify_noopt.m4 should also be fixed to deal with older python version that don't have python-config. That would be ideal, but unless someone shows me/us a system with Python =2.4 which suffers from this issue I'd also be inclined to accept a patch which made that check only apply iff python-config was found (assuming that would be simpler. it might actually be harder...). Isn't that what the current code does (rather messily) ? That is, it invokes python-config, doesn't notice that python-config fails, finds that the no output produced by python-config doesn't contain the problematic fortify options, and disables the workaround. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] VT-d Posted-interrupt (PI) design for XEN
On 04.03.15 at 14:30, feng...@intel.com wrote: - Introduce a new global vector which is used to wake up the HLT'ed vCPU. Currently, there is a global vector 'posted_intr_vector', which is used as the global notification vector for all vCPUs in the system. This vector is stored in VMCS and CPU considers it as a special vector, uses it to notify the related pCPU when an interrupt is recorded in the posted-interrupt descriptor. After having VT-d PI, VT-d engine can issue notification event when the assigned devices issue interrupts. We need add a new global vector to wakeup the HLT'ed vCPU, please refer to the following scenario for the usage of this new global vector: 1. vCPU0 is running on pCPU0 2. vCPU0 is HLT'ed and vCPU1 is currently running on pCPU0 3. An external interrupt from an assigned device occurs for vCPU0, if we still use 'posted_intr_vector' as the notification vector for vCPU0, the notification event for vCPU0 (the event will go to pCPU1) will be consumed by vCPU1 incorrectly. The worst case is that vCPU0 will never be woken up again since the wakeup event for it is always consumed by other vCPUs incorrectly. So we need introduce another global vector, naming 'pi_wakeup_vector' to wake up the HTL'ed vCPU. I'm afraid you describe a particular scenario here, but I don't see how this is related to the introduction of another global vector: Either the current (global) vector is sufficient, or another global vector also can't solve your problem. I'm sure I'm missing something here, so please be explicit. - Update posted-interrupt descriptor during vCPU scheduling The basic idea here is: 1. When vCPU's state is RUNSTATE_running, - Set 'NV' to 'posted_intr_vector'. - Clear 'SN' to accept posted-interrupts. - Set 'NDST' to the pCPU on which the vCPU will be running. [...] This is pretty hard to read without knowing what the abbreviations actually stand for, and suggesting to hunt for them in the spec isn't very reader friendly either. Please explain these fields, at the very least by way of comments on the structure fields presented earlier. On Xen side, what is your opinion about support lowest-priority interrupts for VT-d PI? I certainly think (as with every other virtualized piece of hardware) that hardware behavior should be emulated as closely as possible. I.e. yes, we should have it eventually. As to the two stage approach mentioned for KVM - I've grown reservations against Intel people making promises towards future implementation of something, i.e. I'm kind of hesitant to agree to such an implementation model. Yet you're to contribute the patches, and I'm surely not planning to veto a stage-1-only implementation as it would be an improvement anyway. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On Wed, Mar 04, 2015 at 02:31:08PM +0100, Juergen Gross wrote: On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. You can drive USB devices at line speed using libusb just fine. Try it out and see please, processors copy data _very_ fast these days. thanks, greg k-h ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code
On Wed, Mar 04, 2015 at 09:55:11AM -0500, Boris Ostrovsky wrote:
On 03/04/2015 09:43 AM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 02:31:51PM -0800, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 05:06:50PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 04:26 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 03:13:07PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 02:42 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 02:17:24PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 12:42 PM, Paul E. McKenney wrote:
}
@@ -511,7 +508,8 @@ static void xen_cpu_die(unsigned int cpu)
schedule_timeout(HZ/10);
}
- cpu_die_common(cpu);
+ (void)cpu_wait_death(cpu, 5);
+ /* FIXME: Are the below calls really safe in case of timeout? */
Not for HVM guests (PV guests will only reach this point after
target cpu has been marked as down by the hypervisor).
We need at least to have a message similar to what native_cpu_die()
prints on cpu_wait_death() failure. And I think we should not call
the two routines below (three, actually --- there is also
xen_teardown_timer() below, which is not part of the diff).
-boris
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
So something like this, then?
if (cpu_wait_death(cpu, 5)) {
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
xen_teardown_timer(cpu);
}
else
pr_err(CPU %u didn't die...\n, cpu);
Easy change for me to make if so!
Or do I need some other check for HVM-vs.-PV guests, and, if so, what
would that check be? And also if so, is it OK to online a PV guest's
CPU that timed out during its previous offline?
I believe PV VCPUs will always be CPU_DEAD by the time we get here
since we are (indirectly) waiting for this in the loop at the
beginning of xen_cpu_die():
'while (xen_pv_domain() HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu,
NULL))' will exit only after 'HYPERVISOR_vcpu_op(VCPUOP_down,
smp_processor_id()' in xen_play_dead(). Which happens after
play_dead_common() has marked the cpu as CPU_DEAD.
So no test is needed.
OK, so I have the following patch on top of my previous patch, which
I will merge if testing goes well. So if a CPU times out going offline,
the above three functions will not be called, the didn't die message
will be printed, and any future attempt to online that CPU will fail.
Is that the correct semantics?
Yes.
I am not sure whether not ever onlining the CPU is the best outcome
but then I don't think trying to online it again with all interrupts
and such still set up will work well. And it's an improvement over
what we have now anyway (with current code we may clean up things
for a non-dead cpu).
Another strategy is to key off of the return value of
cpu_check_up_prepare().
If it returns -EBUSY, then the outgoing CPU finished up after the
surviving CPU timed out. The CPU trying to bring the new CPU online
could (in theory, anyway) do the xen_smp_intr_free(), xen_uninit_lock_cpu(),
and xen_teardown_timer() at that point.
And the code for this, in xen_cpu_up(), might look something like the
following:
rc = cpu_check_up_prepare(cpu);
if (rc rc != -EBUSY)
return rc;
if (rc == EBUSY) {
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
xen_teardown_timer(cpu);
}
The idea is that we detect when the CPU eventually took itself offline,
but only did so after the surviving CPU timed out. (Of course, it
would probably be best to put those three statements into a small
function that is called from both places.)
I have no idea whether this approach would really work, especially given
your earlier statement that CPU_DEAD happens early on. But in case it
is helpful or sparks some better idea.
Let me test this, I think it may work.
In the meantime, it turned out that HVM guests are broken by this
patch (with our without changes that we've been discussing), because
HVM CPUs die with
static void xen_hvm_cpu_die(unsigned int cpu)
{
xen_cpu_die(cpu);
native_cpu_die(cpu);
}
Which means that cpu_wait_death() is called twice, and second call
moves the CPU to CPU_BROKEN.
Yikes! I did miss this one. :-(
The simple solution is to stop calling native_cpu_die() above but
I'd like to use common code in native_cpu_die(). I'll see if I can
carve it out without too much damage to x86.
Very good, thank you! I look forward to seeing your patch.
Thanx, Paul
Thanks.
-boris
Thanx, Paul
But I must defer to you on this sort of thing.
Thanx, Paul
Thanks.
-boris
Thanx, Paul
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 03/04/2015 04:27 PM, Greg KH wrote: On Wed, Mar 04, 2015 at 02:31:08PM +0100, Juergen Gross wrote: On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. You can drive USB devices at line speed using libusb just fine. Try it out and see please, processors copy data _very_ fast these days. Okay, thanks for the information. I'll take this as a hint to try the user space variant. :-) Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ./configure: line 7058: python-config: command not found after commit 0013245
On Wed, 2015-03-04 at 16:07 +, Ian Jackson wrote: Ian Campbell writes (Re: ./configure: line 7058: python-config: command not found after commit 0013245): That would be ideal, but unless someone shows me/us a system with Python =2.4 which suffers from this issue I'd also be inclined to accept a patch which made that check only apply iff python-config was found (assuming that would be simpler. it might actually be harder...). Isn't that what the current code does (rather messily) ? Yes, I misread Julien's original mail and thought configure was failing due to the lack of python-config, but you are right, it carries on. So it sounds like perhaps all that is needed is some judicious use of 2/dev/null? That is, it invokes python-config, doesn't notice that python-config fails, finds that the no output produced by python-config doesn't contain the problematic fortify options, and disables the workaround. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen-scsiback: use DRV_PFX in the pr macros and DPRINTK
On Wed, 2015-03-04 at 18:32 +, Tao Chen wrote:
Defined the string of {xen-pvscsi: } as DRV_PFX, then use it in the pr
sentences and DPRINTK.
Also fixed up some comments just as eliminate redundant white spaces and
format the code.
These will make the code easier to read.
It'd probaby be better just to use pr_fmt
before any include and remove all the DRV_PRV uses
#define pr_fmt(fmt) xen-pvscsi: fmt
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
[]
@@ -69,8 +69,10 @@
#include xen/interface/grant_table.h
#include xen/interface/io/vscsiif.h
+#define DRV_PFX xen-pvscsi:
#define DPRINTK(_f, _a...) \
- pr_debug((file=%s, line=%d) _f, __FILE__ , __LINE__ , ## _a)
+ pr_debug(DRV_PFX (file=%s, line=%d) _f, \
+ __FILE__ , __LINE__ , ## _a)
I'd also remove DPRINTK and just use pr_debug directly
as dynamic_debug can emit file and line as desired.
@@ -84,7 +86,7 @@ struct ids_tuple {
struct v2p_entry {
struct ids_tuple v; /* translate from */
- struct scsiback_tpg *tpg; /* translate to */
+ struct scsiback_tpg *tpg; /* translate to */
superfluous change.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [MirageOS-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are
On 4 Mar 2015, at 17:40, Amir Chaudhry am...@cam.ac.uk wrote: I noticed this the other day and had a quick scout around. Mozilla not accepted for Google Summer of Code 2015 http://blog.queze.net/post/2015/03/03/Mozilla-not-accepted-for-Google-Summer-of-Code-2015 Google’s program is enormously popular, and over-subscribed, meaning Google has had to rotate organisation membership http://news.open-bio.org/news/2015/03/sadly-obf-not-accepted-for-gsoc-2015/ I am not particularly surprised. The number of projects is growing, so is competition. Very unfortunate as we've had interest in the MirageOS projects. I wondered about talking to relevant accepted orgs about adding some MirageOS projects but haven't really had a chance to look into this. Please go ahead. Of course we will again participate in OPW. I am still one Advisory Board vote short for approval. Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code
On 03/04/2015 10:45 AM, David Vrabel wrote:
On 04/03/15 14:55, Boris Ostrovsky wrote:
In the meantime, it turned out that HVM guests are broken by this patch
(with our without changes that we've been discussing), because HVM CPUs
die with
static void xen_hvm_cpu_die(unsigned int cpu)
{
xen_cpu_die(cpu);
native_cpu_die(cpu);
}
Which means that cpu_wait_death() is called twice, and second call moves
the CPU to CPU_BROKEN.
The simple solution is to stop calling native_cpu_die() above but I'd
like to use common code in native_cpu_die(). I'll see if I can carve it
out without too much damage to x86.
If not really been following this thread but...
Would it be preferable to refactor xen_cpu_die() instead to factor out
its the cpu_wait_death() call?
That's essentially what I was going to do. Except that native_cpu_die()
returns void so I'll need some common non-void code that lives in x86.
And then we can drop xen_hvm_cpu_die() and use xen_cpu_die() for all guests.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are
Hi folks, just a quick note to let you know that we were not accepted for GSoC this year. Do note that the Linux Foundation, OpenStack Foundation and many of the other usual suspects have not been accepted this year. We will find out more why on Friday. However, there are at least 4 Xen related projects that are managed by other I made a note at the top of http://wiki.xenproject.org/wiki/Archived/GSoC_2015 http://wiki.xenproject.org/wiki/Archived/GSoC_2015 to point applicants to some of those projects. I have found 5 so far (which may bot be a complete list): Xen based Hypervisor in a Box @ Centos http://wiki.centos.org/GSoC/2015/Ideas#head-ecb615be72e53950f08df92809020721d44c6694 Xen guest support for OpenBSD @ Open BSD Foundation http://www.openbsdfoundation.org/gsoc2015.html#xenguest 3 Xen related projects @ Ganeti https://code.google.com/p/ganeti/wiki/SummerOfCode2015Ideas Other projects which were accepted are QEMU https://www.google-melange.com/gsoc/org2/google/gsoc2015/qemu: note that there are no Xen related projects, but given that Xen has good relationships with the QEMU community we may be able to get one or two projects onto the list if someone steps up and is willing to mentor Best Regards Lars___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen/iommu: fix usage of shared EPT/IOMMU page tables on PVH guests
On 27/02/15 11:33, Roger Pau Monne wrote: iommu_share_p2m_table should not prevent PVH guests from using a shared page table between the IOMMU and EPT. Clean the code by removing the asserts in the vendor specific implementations (amd_iommu_share_p2m, iommu_set_pgd), and moving the hap_enabled assert to the caller (iommu_share_p2m_table). Also fix another incorrect usage of is_hvm_domain usage in arch_iommu_populate_page_table. This has not given problems so far because all the pages in PVH guests are of type PGT_writable_page. dom0 PVH failed to boot on my test system without this patch so: Tested-by: David Vrabel david.vra...@citrix.com Thanks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.16 test] 35847: regressions - FAIL
flight 35847 linux-3.16 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35847/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 15 guest-localmigrate/x10fail REGR. vs. 34167 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 34167 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-localmigrate/x10 fail pass in 35762 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 guest-destroyfail blocked in 34167 test-amd64-i386-libvirt 9 guest-start fail like 34167 test-amd64-amd64-xl-sedf 5 xen-boot fail like 34167 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10 fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-multivcpu 15 guest-localmigrate/x10 fail never pass test-amd64-i386-freebsd10-i386 7 freebsd-install fail never pass test-amd64-i386-freebsd10-amd64 7 freebsd-install fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-xl-sedf15 guest-localmigrate/x10 fail in 35762 never pass version targeted for testing: linux3ad4b121bd065d8ce88bab8790b64f538842ad24 baseline version: linux19583ca584d6f574384e17fe7613dfaeadcdc4a6 1069 people touched revisions under test, not listing them all jobs: 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 pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd
Re: [Xen-devel] VT-d Posted-interrupt (PI) design for XEN
On 04/03/15 13:30, Wu, Feng wrote:
VT-d Posted-interrupt (PI) design for XEN
Thankyou very much for this!
Background
==
With the development of virtualization, there are more and more device
assignment requirements. However, today when a VM is running with
assigned devices (such as, NIC), external interrupt handling for the assigned
devices always needs VMM intervention.
VT-d Posted-interrupt is a more enhanced method to handle interrupts
in the virtualization environment. Interrupt posting is the process by
which an interrupt request is recorded in a memory-resident
posted-interrupt-descriptor structure by the root-complex, followed by
an optional notification event issued to the CPU complex.
With VT-d Posted-interrupt we can get the following advantages:
- Directly delivery of external interrupts to running vCPUs without VMM
intervention
- Decease the interrupt migration complexity. On vCPU migration, software
can atomically co-migrate all interrupts targeting the migrating vCPU.
I presume you mean Decrease ?
Decease means something quite different.
Posted-interrupt Introduction
There are two components to the Posted-interrupt architecture:
Processor Support and Root-Complex Support
- Processor Support
Posted-interrupt processing is a feature by which a processor processes
the virtual interrupts by recording them as pending on the virtual-APIC
page.
Posted-interrupt processing is enabled by setting the process posted
interrupts VM-execution control. The processing is performed in response
to the arrival of an interrupt with the posted-interrupt notification vector.
In response to such an interrupt, the processor processes virtual interrupts
recorded in a data structure called a posted-interrupt descriptor.
More information about APICv and CPU-side Posted-interrupt, please refer
to Chapter 29, and Section 29.6 in the Intel SDM:
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
- Root-Complex Support
Interrupt posting is the process by which an interrupt request (from IOAPIC
or MSI/MSIx capable sources) is recorded in a memory-resident
posted-interrupt-descriptor structure by the root-complex, followed by
an optional notification event issued to the CPU complex. The interrupt
request arriving at the root-complex carry the identity of the interrupt
request source and a 'remapping-index'. The remapping-index is used to
look-up an entry from the memory-resident interrupt-remap-table. Unlike
with interrupt-remapping, the interrupt-remap-table-entry for a posted-
interrupt, specifies a virtual-vector and a pointer to the posted-interrupt
descriptor. The virtual-vector specifies the vector of the interrupt to be
recorded in the posted-interrupt descriptor. The posted-interrupt descriptor
hosts storage for the virtual-vectors and contains the attributes of the
notification event (interrupt) to be issued to the CPU complex to inform
CPU/software about pending interrupts recorded in the posted-interrupt
descriptor.
More information about VT-d PI, please refer to
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html
Design Overview
==
In this design, we will cover the following items:
1. Add a variant to control whether enable VT-d posted-interrupt or not.
2. VT-d PI feature detection.
3. Extend posted-interrupt descriptor structure to cover VT-d PI specific
stuff.
4. Extend IRTE structure to support VT-d PI.
5. Introduce a new global vector which is used for waking up the HLT'ed vCPU.
6. Update IRTE when guest modifies the interrupt configuration (MSI/MSIx
configuration).
7. Update posted-interrupt descriptor during vCPU scheduling (when the state
of the vCPU is transmitted among RUNSTATE_running / RUNSTATE_blocked/
RUNSTATE_runnable / RUNSTATE_offline).
8. New boot command line for Xen, which controls VT-d PI feature by user.
9. Multicast/broadcast and lowest priority interrupts consideration.
Implementation details
===
- New variant to control VT-d PI
I know what you are trying to say, but New variant does not express
what you mean.
A new control relating to VT-d PI perhaps?
Like variant 'iommu_intremap' for interrupt remapping, it is very
straightforward
to add a new one 'iommu_intpost' for posted-interrupt. 'iommu_intpost' is set
only when interrupt remapping and VT-d posted-interrupt are both enabled.
I would avoid mixing names such as PI and intpost. If anything, it
should be iommu_postint to keep the naming consistent. (Here and
elsewhere).
- VT-d PI feature detection.
Bit 59 in VT-d Capability Register is used to report VT-d Posted-interrupt
support.
- Extend posted-interrupt descriptor structure to cover VT-d PI specific
stuff.
Here is the new structure for posted-interrupt descriptor:
struct pi_desc {
Re: [Xen-devel] [PATCH 3.18 129/151] x86/xen: Treat SCI interrupt as normal GSI interrupt
On Wed, Mar 04, 2015 at 01:51:53PM +0100, Stefan Bader wrote: On 04.03.2015 07:14, Greg Kroah-Hartman wrote: 3.18-stable review patch. If anyone has any objections, please let me know. I thought I replied earlier today but I cannot seem to find it coming back via the mailing list. Hope this is not duplicating too much... There was a regression with that patch and it requires the below commit as well to prevent that: commit 1ea76fbadd667b19c4fa4466f3a3b55a505e83d9 Author: Jiang Liu jiang@linux.intel.com Date: Mon Feb 16 10:11:13 2015 +0800 x86/irq: Fix regression caused by commit b568b8601f05 Commit b568b8601f05 (Treat SCI interrupt as normal GSI interrupt) accidently removes support of legacy PIC interrupt when fixing a regression for Xen, which causes a nasty regression on HP/Compaq nc6000 where we fail to register the ACPI interrupt, and thus lose eg. thermal notifications leading a potentially overheated machine. Thanks for this, now applied. greg k-h ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.
On Tue, Mar 03, 2015 at 04:11:09PM +0800, Wang Xiaoming wrote:
The maximum of SW-IOMMU is limited to 2^11*128 = 256K.
And the size of IO_TLB_DEFAULT_SIZE is limited to (64UL20) 64M now.
While in different platform and different requirement this seems improper.
So modifing the IO_TLB_SEGSIZE to io_tlb_segsize and IO_TLB_DEFAULT_SIZE
to io_tlb_default_size which can configure by kernel cmdline.
This can meet different requirement.
Signed-off-by: Chuansheng Liu chuansheng@intel.com
Signed-off-by: Zhang Dongxing dongxing.zh...@intel.com
Signed-off-by: Wang Xiaoming xiaoming.w...@intel.com
---
patch v1 make this change at Kconfig
which needs to edit the .config manually.
https://lkml.org/lkml/2015/1/25/571
patch v2 only change IO_TLB_SEGSIZE configurable.
https://lkml.org/lkml/2015/2/5/812
patch v3 parsing io_tlb_segsize and
io_tlb_default_size independently.
https://lkml.org/lkml/2015/2/15/217
patch v4 hasn't validated the data from
command line.
Thank you for redoing this per review.
https://lkml.org/lkml/2015/2/17/114
Documentation/kernel-parameters.txt |9 -
arch/mips/cavium-octeon/dma-octeon.c |2 +-
arch/mips/netlogic/common/nlm-dma.c |2 +-
drivers/xen/swiotlb-xen.c|6 +--
include/linux/swiotlb.h |8 +---
lib/swiotlb.c| 68
+-
6 files changed, 65 insertions(+), 30 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 4df73da..1f50e86 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3438,10 +3438,17 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
it if 0 is given (See Documentation/cgroups/memory.txt)
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
- Format: { int | force }
+ Format: { int | force | int | int}
,
s/|/,/
int -- Number of I/O TLB slabs
force -- force using of bounce buffers even if they
wouldn't be automatically used by the kernel
+ int -- Maximum allowable number of contiguous slabs
to map
+ int -- The size of SW-MMU mapped.
+ Using , to separate them one by one.
Use ',' to seperate them.
+ Example:
+ BOARD_KERNEL_CMDLINE +=
swiotlb=32768,force,512,268435456
+ io_tlb_nslabs=32768, swiotlb_force=1,
+ io_tlb_segsize=512, io_tlb_default_size=268435456
I think you can remove the example - and just have it in the C code.
switches= [HW,M68k]
diff --git a/arch/mips/cavium-octeon/dma-octeon.c
b/arch/mips/cavium-octeon/dma-octeon.c
index 3778655..a521af6 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -312,7 +312,7 @@ void __init plat_swiotlb_setup(void)
swiotlbsize = 64 * (120);
#endif
swiotlb_nslabs = swiotlbsize IO_TLB_SHIFT;
- swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
+ swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
swiotlbsize = swiotlb_nslabs IO_TLB_SHIFT;
octeon_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
diff --git a/arch/mips/netlogic/common/nlm-dma.c
b/arch/mips/netlogic/common/nlm-dma.c
index f3d4ae8..eeffa8f 100644
--- a/arch/mips/netlogic/common/nlm-dma.c
+++ b/arch/mips/netlogic/common/nlm-dma.c
@@ -99,7 +99,7 @@ void __init plat_swiotlb_setup(void)
swiotlbsize = 1 20; /* 1 MB for now */
swiotlb_nslabs = swiotlbsize IO_TLB_SHIFT;
- swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
+ swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
swiotlbsize = swiotlb_nslabs IO_TLB_SHIFT;
nlm_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..3b3e9fe 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -164,11 +164,11 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long
nslabs)
dma_addr_t dma_handle;
phys_addr_t p = virt_to_phys(buf);
- dma_bits = get_order(IO_TLB_SEGSIZE IO_TLB_SHIFT) + PAGE_SHIFT;
+ dma_bits = get_order(io_tlb_segsize IO_TLB_SHIFT) + PAGE_SHIFT;
i = 0;
do {
- int slabs = min(nslabs - i, (unsigned long)IO_TLB_SEGSIZE);
+ int slabs = min(nslabs - i, (unsigned long)io_tlb_segsize);
do {
rc = xen_create_contiguous_region(
@@ -187,7 +187,7 @@ static unsigned long xen_set_nslabs(unsigned long nr_tbl)
{
if (!nr_tbl) {
xen_io_tlb_nslabs = (64 * 1024 * 1024 IO_TLB_SHIFT);
-
Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code
On 04/03/15 14:55, Boris Ostrovsky wrote:
In the meantime, it turned out that HVM guests are broken by this patch
(with our without changes that we've been discussing), because HVM CPUs
die with
static void xen_hvm_cpu_die(unsigned int cpu)
{
xen_cpu_die(cpu);
native_cpu_die(cpu);
}
Which means that cpu_wait_death() is called twice, and second call moves
the CPU to CPU_BROKEN.
The simple solution is to stop calling native_cpu_die() above but I'd
like to use common code in native_cpu_die(). I'll see if I can carve it
out without too much damage to x86.
If not really been following this thread but...
Would it be preferable to refactor xen_cpu_die() instead to factor out
its the cpu_wait_death() call?
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 35825: tolerable FAIL - PUSHED
flight 35825 ovmf real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35825/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 35673 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass version targeted for testing: ovmf 22455087dc3750cc7eed0841cf77e8b6d410efde baseline version: ovmf 9ff926d6d7c694c09f63008819b8930b9fa79d1a People who touched revisions under test: Ard Biesheuvel ard.biesheu...@linaro.org Jordan Justen jordan.l.jus...@intel.com Laszlo Ersek ler...@redhat.com Olivier Martin olivier.mar...@arm.com jobs: 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 pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd 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-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-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64fail test-amd64-amd64-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-amd64-xl-pvh-intelfail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpupass test-amd64-amd64-pairpass test-amd64-i386-pair
Re: [Xen-devel] [PATCH 04/10] xen/blkfront: separate ring information to an new struct
David assertion that better performance and scalbility can be gained with grant table locking and TLB flush avoidance is interesting - as 1). The grant locking is going in Xen 4.6 but not earlier - so when running on older hypervisors this gives an performance benefit. 2). I have not seen any prototype TLB flush avoidance code so not know when that would be available. Perhaps a better choice is to do the removal of the persistence support when the changes in Xen hypervisor are known? With patch: [PATCH v5 0/2] gnttab: Improve scaleability, I can get nearly the same performance as without persistence support. But I'm not sure about the benchmark described here: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/block/xen-blkfront.c?id=0a8704a51f386cab7394e38ff1d66eef924d8ab8 Meaning you weren't able to do the same test? -- Regards, -Bob ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/4] fix freemem loop
On Tuesday, March 03, 2015 02:54:50 PM Mike Latimer wrote: Thanks for all the help and patience as we've worked through this. Ack to the whole series: Acked-by: Mike Latimer mlati...@suse.com I guess the more correct response is: Reviewed-by: Mike Latimer mlati...@suse.com Tested-by: Mike Latimer mlati...@suse.com -Mike ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 4/4] tools, docs: add total/local memory bandwith monitoring
On Wed, Mar 04, 2015 at 10:07:56AM +, Ian Campbell wrote:
On Wed, 2015-03-04 at 09:04 +0800, Chao Peng wrote:
On Tue, Mar 03, 2015 at 10:09:39AM +, Ian Campbell wrote:
On Tue, 2015-03-03 at 16:00 +0800, Chao Peng wrote:
On Mon, Mar 02, 2015 at 01:48:43PM +, Ian Campbell wrote:
On Thu, 2015-02-26 at 16:45 +0800, Chao Peng wrote:
Add Memory Bandwidth Monitoring(MBM) for VMs. Two types of
monitoring
are supported: total and local memory bandwidth monitoring. To use
it,
CMT should be enabled in hypervisor.
Signed-off-by: Chao Peng chao.p.p...@linux.intel.com
This looks good. I have one question and one small comment/idea:
[...]
diff --git a/tools/libxc/include/xenctrl.h
b/tools/libxc/include/xenctrl.h
index 09d819f..54043ee 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2688,6 +2688,8 @@ int xc_resource_op(xc_interface *xch,
uint32_t nr_ops, xc_resource_op_t *ops);
#if defined(__i386__) || defined(__x86_64__)
enum xc_psr_cmt_type {
XC_PSR_CMT_L3_OCCUPANCY,
+XC_PSR_CMT_TOTAL_MEM_BANDWIDTH,
+XC_PSR_CMT_LOCAL_MEM_BANDWIDTH,
Is bandwidth still the correct term here (and more importantly in
the
libxl interface e.g. enum), given that we now do the sampling at the
application level and just expose the current count from Xen via
libxl?
I feel comfortable either changing it or not. The reason to change it is
what you said here that we do return the counter value to the caller, so
a consistent name would be nice. While the reason to keep it is: the
names are listed as the monitoring event type from spec, so the caller
perhaps knows that the returned data is the sample value from event
counter register related to that type.
Anyway, if you feel it's better to change, then I will do.
What names does Intel's documentation use for these registers?
The register is IA32_QM_CTR(Monitoring Counter Register), to read the
count in this register,
I'm thinking then that COUNT is the right name, .e.g.
XC_PSR_CMT_TOTAL_MEM_COUNT (and for libxl names too). Does that sound
alright?
Yes. See my changes sent in another thread.
Chao
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 04/10] xen/blkfront: separate ring information to an new struct
On 03/05/2015 05:21 AM, Konrad Rzeszutek Wilk wrote: David assertion that better performance and scalbility can be gained with grant table locking and TLB flush avoidance is interesting - as 1). The grant locking is going in Xen 4.6 but not earlier - so when running on older hypervisors this gives an performance benefit. 2). I have not seen any prototype TLB flush avoidance code so not know when that would be available. Perhaps a better choice is to do the removal of the persistence support when the changes in Xen hypervisor are known? With patch: [PATCH v5 0/2] gnttab: Improve scaleability, I can get nearly the same performance as without persistence support. But I'm not sure about the benchmark described here: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/block/xen-blkfront.c?id=0a8704a51f386cab7394e38ff1d66eef924d8ab8 Meaning you weren't able to do the same test? I can if there are more details about how to set up this 5 and 10 guests environment and test pattern have been used. Just think it might be save time if somebody still have the similar environment by hand. Roger and Felipe, if you still have the environment could you please have a quick compare about feature-persistent performance with patch [PATCH v5 0/2] gnttab: Improve scaleability? Thanks, -Bob ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Why gpa instead of mfn is directed used in emulated nic
Hi, all: I want to learn how the emulated NICs work in XEN. So I boot a DomU with an emulated rtl8139 NIC, ping host from DomU and capture the trace info using xentrace tool, and then check the log of qemu-dm and trace info analyzed by xenalyze tool. I have enabled debug in rtl8139.c and added debug info to qemu-dm when receiving ioreq. The host runs XEN 4.4.1 and have EPT enabled. If I understand right, the TX procedure from DomU to Dom0 is as follows: 1. RTL8139 driver in Guest Kernel write Guest Physical Address of data to be sent to the corresponding registers of RTL8139 2. The address space of registers were marked special in hvmloader, so the DomU will exit with EPT_VIOLATION reason 3. Hypervisor will handle the exit in ept_handle_violation() function and then call hvm_hap_nested_page_fault(gfn). In the latter function, hypervisor will get the mfn from gfn and judge that the gfn is emulated MMIO, and then pass the fault to mmio handler 4. The MMIO handler will generate an IOREQ with related info and push it to Shared Memory Page between DomU and Qemu-Dm in Dom0, which is initialized when booting DomU via hvm_init() function, and then notify qemu-dm via event channel which is also initialized in hvm_init function 5. QEMU-DM will get the IOREQ and call the corresponding callbacks registered by RTL8139.c in qemu However, from the qemu-dm's log and trace info, I have two questions: 1. In step 4 mentioned above, is the ioreq passed through shared memory page or buffed io page? Both of them are initialized in hvm_init function. 2. From the trace info and qemu-dm's log, it seems that it is GPA (Guest Physical Address) instead of MFN in the IOREQ's data field received by qemu-dm: a. EPT_VIOLATION related records in xentrace: ] 1.744702725 -x-- d3v1 vmexit exit_reason EPT_VIOLATION eip a01624ae 1.744702725 -x-- d3v1 npf gpa f2051020 q 182 mfn t 4 ] 1.744702725 -x-- d3v1 mmio_assist w gpa f2051020 data d4e6c400 1.744706888 -x-- d3v1 runstate_change d0v0 blocked-runnable As shown above, the value of data is d4e6c400, I think it is the data represents the txbuf address written by DomU, so it should be the GPA of DomU. From the code I do find that the data is the ram_gpa argument in xen/arch/x86/hvm/emulate.c:hvmemul_do_io function. b. Related ioreq received by qemu-dm and handled by RTL8139.c in Dom0: xen: I/O request: 1, ptr: 0, port: f2051020, data: d4e6c400, count: 1, size: 4 RTL8139: TxAddr write offset=0x0 val=0xd4e6c400 As shown above, the data field of ioreq received by qemu-dm is also 0xd4e6c400 which is the GPA of DomU. c. RTL8139.c does the transmit work: RTL8139: C+ TxPoll write(b) val=0x40 RTL8139: C+ TxPoll normal priority transmission RTL8139: +++ C+ mode reading TX descriptor 0 from host memory at d4e6c400 = 0xd4e6c400 RTL8139: +++ C+ mode TX descriptor 0 b05a ead20802 RTL8139: +++ C+ Tx mode : transmitting from descriptor 0 RTL8139: +++ C+ Tx mode : descriptor 0 is first segment descriptor RTL8139: +++ C+ mode transmission buffer allocated space 65536 RTL8139: +++ C+ mode transmit reading 90 bytes from host memory at ead20802 to offset 0 RTL8139: +++ C+ Tx mode : descriptor 0 is last segment descriptor RTL8139: +++ C+ mode transmitting 90 bytes packet RTL8139: +++ C+ mode reading TX descriptor 1 from host memory at d4e6c400 = 0xd4e6c410 RTL8139: +++ C+ mode TX descriptor 1 RTL8139: C+ Tx mode : descriptor 1 is owned by host RTL8139: Set IRQ to 1 (0004 80ff) As shown above, RTL8139 will read TX descriptor from HOST MEMORY at 0xd4e6c400, which is the GPA of DomU. I think qemu-dm/rtl8139 should read/write data from MFN address in host memory instaed of GPA, and I find that there isn't hypercall from dom0 to translate the gpa to mfn in subsequent xentrace info. Is my understanding is wrong? I would really appreciate your help. -- Best Regards ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.10 test] 35860: regressions - FAIL
flight 35860 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35860/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303 test-amd64-amd64-xl-winxpsp3 7 windows-install fail like 26303 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 5 xen-boot fail never pass test-armhf-armhf-libvirt 5 xen-boot fail never pass test-armhf-armhf-xl-midway5 xen-boot fail never pass test-armhf-armhf-xl-sedf 5 xen-boot fail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-armhf-armhf-xl-multivcpu 5 xen-boot fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass version targeted for testing: linuxef16065a9e97e4fbcecc42e9effa3d2f15119794 baseline version: linuxbe67db109090b17b56eb8eb2190cd70700f107aa 923 people touched revisions under test, not listing them all jobs: 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 pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64fail 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 fail test-amd64-amd64-xl-qemut-win7-amd64
Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m
Right. The key observation is that at any single point in time, a given hardware thread can be fetching an instruction or reading data, but not both. Fine, as long as an instruction reading itself isn't going to lead to a live lock. That's not how the hardware works. By the time you figure out that the instruction you are executing reads memory, the instruction itself has been fetched and decoded. That won't happen again during this execution. Can you explain? If the instruction faults and is returned to, execution starts again, right? So for an instruction that reads itself: - the fetch succeeds; - the read fails, and we fault; - the hypervisor switches from mapping MFN 1 (--x) to MFN 2 (r--); - the hypervisor returns to the guest. Are you relying on the icache/trace cache/whatever to restart the instruction from a cached value rather than fault immediately? (Because the hypervisor didn't flush the TLB when it changed the mapping)? Nope. I just typed before drinking enough coffee. That whole answer was bogus. Of course, if an instruction reads itself you can get a live lock using these techniques, but it's a software-induced live lock and software can avoid it. One way is compare the address being read with the instruction pointer, and if they are on the same page emulate instead of switching p2m's. Ed Hi Ed, we have been poking at this idea of achieving singlestepping through altp2m view-switching (which would be supported by the VMFUNC EPTP-switching) and the problem discussed above is not limited to instructions that perform data accesses on the same page where the instruction executing was fetched from. In order to achieve true single-stepping, the immediate next instruction should be causing an EPT violation. Let's assume we trap an instruction that only performs data accesses on pages other than the one the instruction was fetched from. Since the instruction fetch is repeated after a failed data access due to EPT violation, the page containing the instruction has to be at least --x and the pages that will be touched by it rw- (or the proper combination or r-- and rw-) simultaneously in order to avoid getting into a live-lock. This results in all subsequent instruction fetches to succeed from the original page. Furthermore, as long as all such subsequent instructions keep accessing only the pages touched by the first instruction, we could end up missing a good chunk of code execution. Is there something we are missing here or is this a known limitation to the EPT-based singlestepping mechanism? Or is there something in the way VMFUNC is implemented that will avoid this limitation? Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 35863: regressions - FAIL
flight 35863 libvirt real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35863/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 12 guest-start.2 fail REGR. vs. 35524 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt 9 guest-start fail like 35524 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass version targeted for testing: libvirt 63889e0c775010d8d70b71d25340bab995aa83ce baseline version: libvirt 719cd2182bf06196b26204a8cf88d28001b1d79b People who touched revisions under test: Daniel Veillard veill...@redhat.com Erik Skultety eskul...@redhat.com John Ferlan jfer...@redhat.com Ján Tomko jto...@redhat.com Martin Kletzander mklet...@redhat.com Michal Privoznik mpriv...@redhat.com Pavel Hrdina phrd...@redhat.com Peter Krempa pkre...@redhat.com Prerna Saxena pre...@linux.vnet.ibm.com jobs: 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 test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 605 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] kasan_map_early_shadow() on Xen
On Wed, Mar 4, 2015 at 6:36 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote: If it is like that - then just using what had to be implemented for the stack protection as a template ought to pave most of the work? Probably. I think I could make this work. However, I won't be able to work on this until the end of the next week. While a solution is likely possible here I'd like for us to notice how two features have gone now under our nose for Xen on v4.0 which have issues. Proactive maintainer reviews would detect these issues but we can't bet on these, and testing is just as reactive and slow. I'm hinting we keep our eyes out for an architectural solution that would avoid these issues. Don't ask me what that is just yet... Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/tboot: invalidate FIX_TBOOT_MAP_ADDRESS mapping after use
On Feb 18, 2015 17:03, Jan Beulich wrote: In order for commit cbeeaa7d (x86/nmi: fix shootdown of pcpus running in VMX non-root mode)'s re-use of that fixmap entry to not cause undesirable (in crash context) cross-CPU TLB flushes, invalidate the fixmap entry right after use. Signed-off-by: Jan Beulich jbeul...@suse.com --- a/xen/arch/x86/tboot.c +++ b/xen/arch/x86/tboot.c @@ -138,6 +138,7 @@ void __init tboot_probe(void) TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE); tboot_copy_memory((unsigned char *)sinit_size, sizeof(sinit_size), TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE); +__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0); } /* definitions from xen/drivers/passthrough/vtd/iommu.h @@ -476,6 +477,8 @@ int __init tboot_parse_dmar_table(acpi_t dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length); tboot_copy_memory(dmar_table_raw, dmar_table_length, pa); dmar_table = (struct acpi_table_header *)dmar_table_raw; +__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0); + rc = dmar_handler(dmar_table); xfree(dmar_table_raw); It might be better to move the fixmap invalidations into tboot_copy_memory like below. diff -r 37706d651593 xen/arch/x86/tboot.c --- a/xen/arch/x86/tboot.c Wed Mar 04 10:03:48 2015 +0100 +++ b/xen/arch/x86/tboot.c Thu Mar 05 12:40:25 2015 +0800 @@ -88,6 +88,8 @@ static void __init tboot_copy_memory(uns } va[i] = map_addr[pa + i - (map_base PAGE_SHIFT)]; } + +__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0); } void __init tboot_probe(void) Thanks Jimmy ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/tboot: simplify DMAR table copying
On Feb 18, 2015 17:03, Jan Beulich wrote:
There's no need for more than one variable, no need for casts, and no
point in using the type-safe xmalloc_array() here.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -435,13 +435,12 @@ int __init tboot_protect_mem_regions(voi
int __init tboot_parse_dmar_table(acpi_table_handler dmar_handler) {
-struct acpi_table_header *dmar_table;
int rc;
uint64_t size;
uint32_t dmar_table_length;
unsigned long pa;
sinit_mle_data_t sinit_mle_data;
-unsigned char *dmar_table_raw;
+void *dmar_table;
if ( !tboot_in_measured_env() )
return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler); @@ -
474,13 +473,12 @@ int __init tboot_parse_dmar_table(acpi_t
tboot_copy_memory((unsigned char *)dmar_table_length,
sizeof(dmar_table_length),
pa + sizeof(char) * ACPI_NAME_SIZE);
-dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length);
-tboot_copy_memory(dmar_table_raw, dmar_table_length, pa);
-dmar_table = (struct acpi_table_header *)dmar_table_raw;
+dmar_table = xmalloc_bytes(dmar_table_length);
+tboot_copy_memory(dmar_table, dmar_table_length, pa);
__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0);
rc = dmar_handler(dmar_table);
-xfree(dmar_table_raw);
+xfree(dmar_table);
/* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table */
/* but dom0 will read real table, so must zap it there too */
Ack.
Jimmy
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC V2 1/5] libxl: add pvusb definitions
On 3/4/2015 at 08:33 PM, in message 1425472438.25940.147.ca...@citrix.com, Ian Campbell ian.campb...@citrix.com wrote: On Wed, 2015-03-04 at 12:26 +, George Dunlap wrote: On 03/04/2015 10:00 AM, Ian Campbell wrote: On Wed, 2015-03-04 at 00:26 -0700, Chun Yan Liu wrote: On 3/3/2015 at 07:10 PM, in message 1425381019.24959.87.ca...@citrix.com, Ian Campbell ian.campb...@citrix.com wrote: On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote: Sorry for the long delay in replying. To attach a usb device, a virtual usb controller should be created first. This patch defines usbctrl and usbdevice related structs. Per 54ca17df026600095...@relay2.provo.novell.com please could you mention here that the HVM guest related parts (i.e. LIBXL_USBCTRL_TYPE_DEVICEMODEL) and libxl_usb_type are placeholders for emulated HVM support. Yes, I agree it's better placed in libxl_usb_type rather than ctrl_type. In fact I wonder if it should just be omitted, we will need a LIBXL_HAVE for HVM USB support anyway once it is implemented so we can add the enum then. It won't harm to omit it for current pvusb work. Acceptable to me to add enum later when adding HVM qemu emulated usb device implementation. I suppose users of libxl would like to be able to expose to their users whether or not HVM USB passthrough will work (i.e. to hide UI options). So I think we will want the #define eventually so they can know at compile time if HVM USB will work. We could add a negative one now (LIBXC_NO_HVM_USB_PASSTHROUGH) and remove it later, but that's icky I think. So I think omit the HVM stuff for now, it's less confusing overall that way. George, is that OK with you? Yes; particularly as I'm hoping that having the PVUSB stuff in will make it easier for me to add my HVM usb hot-plug stuff before the feature freeze. :-) Great. To usb controller index. A usb device should be connected to a usb port of a usb controller. e.g.: there is 2 usb controllers in system, each with 8 ports, then: 1st usb controller index will be 0, port will be 1~8. 2nd usb controller index will be 1, port will be 1~8. To attach a usb device through pvusb way, it should be pointed to connect to which controller and which port. I guess what I'm missing is how do I create this controller? I saw nothing in the guest cfg which would allow me to create one. Is there some way to say I don't care, find a controller and use it? This isn't documented, but if you set ctrl to -1, the code as written will automatically: * find an empty port on a controller, if there is one * create a controller if there isn't one. I meant to mention this in my mail yesterday though -- I think probably there should be a defined constant in the IDL (LIBXL_USBCTRL_AUTO or something) you should use for that, rather than just remembering a magic value. Yes, and it should be the init_val in the idl I think so that the default is to do something useful after _init is called. Got it. Will update. Can we arrange for the default/auto value to be 0, or is that too confusing because it is expected that controllers will be zero based? Yeah, controller index is zero based, so it might be confusing if setting default/auto to be 0. - Chunyan + @@ -547,6 +578,7 @@ libxl_domain_config = Struct(domain_config, [ (disks, Array(libxl_device_disk, num_disks)), (nics, Array(libxl_device_nic, num_nics)), (pcidevs, Array(libxl_device_pci, num_pcidevs)), +(usbs, Array(libxl_device_usb, num_usbs)), So, I'm unsure how this interacts with the controllers, which it doesn't seem to be possible to specify at domain build time. In domain config, user only needs to specify usb=['2-1.6'], by default, it will create a default usb contoller, and probe the 1st available controller:port for the usb device to attach. So, it can work to specify usbs here only. Reason didn't include controller in libxl_domain_config: for HVM qemu emulated usb device, all work is done in qemu (create usb controller and attach usb device), no controller exists in libxl in that case. OK, so it's an HVM only thing. I think that makes sense, but then how does the libxl_device_usb.ctrl field make sense or how do I use it? Well for one, you can use libxl_device_usbctrl_add() to make a new one on a running VM; then you can use libxl_device_usb_add() to attach it. (These are exposed in xl as usb-ctrl-attach and usb-attach.) I was thinking in the context of the domain_config struct above, so runtime xl commands other than create aren't usable. Ian.
Re: [Xen-devel] [PATCH RFC V2 1/5] libxl: add pvusb definitions
On 3/4/2015 at 10:41 PM, in message 54f71992.5080...@eu.citrix.com, George Dunlap george.dun...@eu.citrix.com wrote: On 03/04/2015 08:28 AM, Chun Yan Liu wrote: On 3/4/2015 at 01:15 AM, in message 54f5ec4e.6020...@eu.citrix.com, George Dunlap george.dun...@eu.citrix.com wrote: On 01/19/2015 08:28 AM, Chunyan Liu wrote: To attach a usb device, a virtual usb controller should be created first. This patch defines usbctrl and usbdevice related structs. Signed-off-by: Chunyan Liu cy...@suse.com Signed-off-by: Simon Cao caobosi...@gmail.com Chunyan, thanks for picking up this work! A couple of things. First, I think that having the IDL stuff separate from the patches where they are used actually makes it *harder* to review, because you can't easily go to the code where it's used and see what's actually happening. I think that the IDL stuff used in patch 3 should be in patch 3; and the domain creation IDL stuff should be included in patch 5. Tha's OK. I'll update. Great, thanks. +libxl_device_usbctrl = Struct(device_usbctrl, [ +(name, string), +(type, libxl_usbctrl_type), +(backend_domid, libxl_domid), +(backend_domname, string), +(devid, libxl_devid), +(usb_version, uint8), +(num_ports, uint8), +]) + +libxl_device_usb = Struct(device_usb, [ +(ctrl, integer), +(port, integer), +(intf, string), +(u, KeyedUnion(None, libxl_usb_type, type, +[(hostdev, Struct(None, [ +(hostbus, integer), +(hostaddr, integer) ])) +])) +]) So intf here is wrong. To begin with, it's information specific to the hostdev type; so it would go under the type keyed union under hostdev. Secondly, this requires people to figure out that their media reader has an intf of 1-2.1.1:1.0. I don't think that's a good idea, for two reasons: one, it just seems like a really hard interface to use. I couldn't find any straightforward tools to map USB devices onto intf; Right. One can only use usb-assignable-list for a fast look. That follows the old xend toolstack way. tools like lsusb instead give you a bus:addr combination. Secondly, it's inconsistent with qemu -- which means we'd either have to have two different ways of specifying the device, or we'd need to translate from intf back into bus:addr You are right. Using bus:addr could unify qemu and pvusb. I also thought about that. Only concern is it's different from old xend toolstack usage. If that doesn't affect, we can update to use bus:addr, no problem. Right, I see. I think overall that the bus:addr is a better interface; it's also what's exposed by lsusb, qemu, and libvirt, AFAICT. So I definitely think that at the libxl level that's what we should be using. Thanks. Got it. Will update. We're already defining a new config file format, right? So domain configs that used pvusb with xend won't work with this patch series anyway, correct? If we're not going to make something 100% compatible, I don't see any particular value in making it 25% compatible. :-) I think the right thing to do here is to take intf out of this struct, and to translate bus:addr into intf internally. It looks like the values qemu and lsusb use can be found in busnum and devnum in the sysfs files. You've already got code to scan those devices; you just need to add a bit of code to find which of those corresponds to a given hostbus:hostaddr combination. + libxl_device_vtpm = Struct(device_vtpm, [ (backend_domid,libxl_domid), (backend_domname, string), @@ -547,6 +578,7 @@ libxl_domain_config = Struct(domain_config, [ (disks, Array(libxl_device_disk, num_disks)), (nics, Array(libxl_device_nic, num_nics)), (pcidevs, Array(libxl_device_pci, num_pcidevs)), +(usbs, Array(libxl_device_usb, num_usbs)), Any reason you don't make it possible to specify usb controllers as well? For qemu emulated HVM usb device, usb controller is created by qemu, no way to specify it (?) Also I wonder if specifying usb controller is necessary, seems it won't affect without usb controller here. Correct me if I'm wrong. If it's necessary, we can add it. On the contrary, there is a way to specify it. :-) See usbversion=[n]. At the moment we specify the usb device on the qemu command-line; but I'm pretty sure that we can use qmp to hot-plug a USB controller just like we can use it to hot-plug a USB device. qemu will automatically hot-plug a USB controller as necessary, similar to your automatically create a pvusb controller functionality for pvusb add. But there may be circumstances where we want to specify a
Re: [Xen-devel] [PATCH v5] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.
-Original Message-
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Thursday, March 5, 2015 3:43 AM
To: Wang, Xiaoming
Cc: ch...@chris-wilson.co.uk; david.vra...@citrix.com;
lau...@codeaurora.org; heiko.carst...@de.ibm.com; li...@horizon.com;
l...@aserp2030.oracle.com; Liu, Chuansheng; zh...@aserp2030.oracle.com;
Zhang, Dongxing; takahiro.aka...@linaro.org; a...@linux-foundation.org;
linux-m...@linux-mips.org; r...@linux-mips.org; xen-
de...@lists.xenproject.org; boris.ostrov...@oracle.com;
d.kasat...@samsung.com; pebo...@tiscali.nl; linux-ker...@vger.kernel.org;
jbeul...@suse.com
Subject: Re: [PATCH v5] modify the IO_TLB_SEGSIZE and
IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-
IOMMU.
On Tue, Mar 03, 2015 at 04:11:09PM +0800, Wang Xiaoming wrote:
The maximum of SW-IOMMU is limited to 2^11*128 = 256K.
And the size of IO_TLB_DEFAULT_SIZE is limited to (64UL20) 64M now.
While in different platform and different requirement this seems improper.
So modifing the IO_TLB_SEGSIZE to io_tlb_segsize and
IO_TLB_DEFAULT_SIZE to io_tlb_default_size which can configure by
kernel cmdline.
This can meet different requirement.
Signed-off-by: Chuansheng Liu chuansheng@intel.com
Signed-off-by: Zhang Dongxing dongxing.zh...@intel.com
Signed-off-by: Wang Xiaoming xiaoming.w...@intel.com
---
patch v1 make this change at Kconfig
which needs to edit the .config manually.
https://lkml.org/lkml/2015/1/25/571
patch v2 only change IO_TLB_SEGSIZE configurable.
https://lkml.org/lkml/2015/2/5/812
patch v3 parsing io_tlb_segsize and
io_tlb_default_size independently.
https://lkml.org/lkml/2015/2/15/217
patch v4 hasn't validated the data from command line.
Thank you for redoing this per review.
https://lkml.org/lkml/2015/2/17/114
Documentation/kernel-parameters.txt |9 -
arch/mips/cavium-octeon/dma-octeon.c |2 +-
arch/mips/netlogic/common/nlm-dma.c |2 +-
drivers/xen/swiotlb-xen.c|6 +--
include/linux/swiotlb.h |8 +---
lib/swiotlb.c| 68
+-
6 files changed, 65 insertions(+), 30 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 4df73da..1f50e86 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3438,10 +3438,17 @@ bytes respectively. Such letter suffixes can
also be entirely omitted.
it if 0 is given (See
Documentation/cgroups/memory.txt)
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
- Format: { int | force }
+ Format: { int | force | int | int}
,
s/|/,/
How about change the Format to
Format: { int,force,int,int}
Force the parameter input in consecutive order.
int -- Number of I/O TLB slabs
force -- force using of bounce buffers even if they
wouldn't be automatically used by the kernel
+ int -- Maximum allowable number of contiguous
slabs to map
+ int -- The size of SW-MMU mapped.
+ Using , to separate them one by one.
Use ',' to seperate them.
+ Example:
+ BOARD_KERNEL_CMDLINE +=
swiotlb=32768,force,512,268435456
+ io_tlb_nslabs=32768, swiotlb_force=1,
+ io_tlb_segsize=512, io_tlb_default_size=268435456
I think you can remove the example - and just have it in the C code.
switches= [HW,M68k]
diff --git a/arch/mips/cavium-octeon/dma-octeon.c
b/arch/mips/cavium-octeon/dma-octeon.c
index 3778655..a521af6 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -312,7 +312,7 @@ void __init plat_swiotlb_setup(void)
swiotlbsize = 64 * (120);
#endif
swiotlb_nslabs = swiotlbsize IO_TLB_SHIFT;
- swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
+ swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
swiotlbsize = swiotlb_nslabs IO_TLB_SHIFT;
octeon_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
diff --git a/arch/mips/netlogic/common/nlm-dma.c
b/arch/mips/netlogic/common/nlm-dma.c
index f3d4ae8..eeffa8f 100644
--- a/arch/mips/netlogic/common/nlm-dma.c
+++ b/arch/mips/netlogic/common/nlm-dma.c
@@ -99,7 +99,7 @@ void __init plat_swiotlb_setup(void)
swiotlbsize = 1 20; /* 1 MB for now */
swiotlb_nslabs = swiotlbsize IO_TLB_SHIFT;
- swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
+ swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
swiotlbsize = swiotlb_nslabs IO_TLB_SHIFT;
nlm_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
diff
Re: [Xen-devel] VT-d Posted-interrupt (PI) design for XEN
-Original Message- From: Andrew Cooper [mailto:andrew.coop...@citrix.com] Sent: Thursday, March 05, 2015 2:48 AM To: Wu, Feng; xen-devel@lists.xen.org Cc: Zhang, Yang Z; Tian, Kevin; Jan Beulich Subject: Re: [Xen-devel] VT-d Posted-interrupt (PI) design for XEN On 04/03/15 13:30, Wu, Feng wrote: VT-d Posted-interrupt (PI) design for XEN Thankyou very much for this! Background == With the development of virtualization, there are more and more device assignment requirements. However, today when a VM is running with assigned devices (such as, NIC), external interrupt handling for the assigned devices always needs VMM intervention. VT-d Posted-interrupt is a more enhanced method to handle interrupts in the virtualization environment. Interrupt posting is the process by which an interrupt request is recorded in a memory-resident posted-interrupt-descriptor structure by the root-complex, followed by an optional notification event issued to the CPU complex. With VT-d Posted-interrupt we can get the following advantages: - Directly delivery of external interrupts to running vCPUs without VMM intervention - Decease the interrupt migration complexity. On vCPU migration, software can atomically co-migrate all interrupts targeting the migrating vCPU. I presume you mean Decrease ? Yes! Decease means something quite different. Sorry for the typo. Posted-interrupt Introduction There are two components to the Posted-interrupt architecture: Processor Support and Root-Complex Support - Processor Support Posted-interrupt processing is a feature by which a processor processes the virtual interrupts by recording them as pending on the virtual-APIC page. Posted-interrupt processing is enabled by setting the process posted interrupts VM-execution control. The processing is performed in response to the arrival of an interrupt with the posted-interrupt notification vector. In response to such an interrupt, the processor processes virtual interrupts recorded in a data structure called a posted-interrupt descriptor. More information about APICv and CPU-side Posted-interrupt, please refer to Chapter 29, and Section 29.6 in the Intel SDM: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/6 4-ia-32-architectures-software-developer-manual-325462.pdf - Root-Complex Support Interrupt posting is the process by which an interrupt request (from IOAPIC or MSI/MSIx capable sources) is recorded in a memory-resident posted-interrupt-descriptor structure by the root-complex, followed by an optional notification event issued to the CPU complex. The interrupt request arriving at the root-complex carry the identity of the interrupt request source and a 'remapping-index'. The remapping-index is used to look-up an entry from the memory-resident interrupt-remap-table. Unlike with interrupt-remapping, the interrupt-remap-table-entry for a posted- interrupt, specifies a virtual-vector and a pointer to the posted-interrupt descriptor. The virtual-vector specifies the vector of the interrupt to be recorded in the posted-interrupt descriptor. The posted-interrupt descriptor hosts storage for the virtual-vectors and contains the attributes of the notification event (interrupt) to be issued to the CPU complex to inform CPU/software about pending interrupts recorded in the posted-interrupt descriptor. More information about VT-d PI, please refer to http://www.intel.com/content/www/us/en/intelligent-systems/intel-technolog y/vt-directed-io-spec.html Design Overview == In this design, we will cover the following items: 1. Add a variant to control whether enable VT-d posted-interrupt or not. 2. VT-d PI feature detection. 3. Extend posted-interrupt descriptor structure to cover VT-d PI specific stuff. 4. Extend IRTE structure to support VT-d PI. 5. Introduce a new global vector which is used for waking up the HLT'ed vCPU. 6. Update IRTE when guest modifies the interrupt configuration (MSI/MSIx configuration). 7. Update posted-interrupt descriptor during vCPU scheduling (when the state of the vCPU is transmitted among RUNSTATE_running / RUNSTATE_blocked/ RUNSTATE_runnable / RUNSTATE_offline). 8. New boot command line for Xen, which controls VT-d PI feature by user. 9. Multicast/broadcast and lowest priority interrupts consideration. Implementation details === - New variant to control VT-d PI I know what you are trying to say, but New variant does not express what you mean. A new control relating to VT-d PI perhaps? Like variant 'iommu_intremap' for interrupt remapping, it is very straightforward to add a new one 'iommu_intpost' for posted-interrupt. 'iommu_intpost' is set only when interrupt remapping and VT-d posted-interrupt are both enabled. I would
Re: [Xen-devel] VT-d Posted-interrupt (PI) design for XEN
On 05.03.15 at 06:04, feng...@intel.com wrote: From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Wednesday, March 04, 2015 11:19 PM On 04.03.15 at 14:30, feng...@intel.com wrote: - Introduce a new global vector which is used to wake up the HLT'ed vCPU. Currently, there is a global vector 'posted_intr_vector', which is used as the global notification vector for all vCPUs in the system. This vector is stored in VMCS and CPU considers it as a special vector, uses it to notify the related pCPU when an interrupt is recorded in the posted-interrupt descriptor. After having VT-d PI, VT-d engine can issue notification event when the assigned devices issue interrupts. We need add a new global vector to wakeup the HLT'ed vCPU, please refer to the following scenario for the usage of this new global vector: 1. vCPU0 is running on pCPU0 2. vCPU0 is HLT'ed and vCPU1 is currently running on pCPU0 3. An external interrupt from an assigned device occurs for vCPU0, if we still use 'posted_intr_vector' as the notification vector for vCPU0, the notification event for vCPU0 (the event will go to pCPU1) will be consumed by vCPU1 incorrectly. The worst case is that vCPU0 will never be woken up again since the wakeup event for it is always consumed by other vCPUs incorrectly. So we need introduce another global vector, naming 'pi_wakeup_vector' to wake up the HTL'ed vCPU. I'm afraid you describe a particular scenario here, but I don't see how this is related to the introduction of another global vector: Either the current (global) vector is sufficient, or another global vector also can't solve your problem. I'm sure I'm missing something here, so please be explicit. In fact, the new global vector is used for the above scenario. Let me explain this a bit more: After having VT-d PI, when an external interrupt from an assigned device happens, here is the hardware processing flow: 1. Interrupts happen. 2. Find the associated IRTE. 3. Find the destination vCPU from IRTE (from Posted-interrupt descriptor address) 4. Sync the interrupt (stored in IRTE as 'virtual vector') to PIRR fields in Posted-interrupt descriptor. 5. If needed (Please refer to the VT-d Spec about the condition of issuing Notification Event), issue notification event to the destination CPU which is store in posted-interrupt descriptor as 'NDST' Back to the above scenario: 1. vCPU0 is running in pCPU0, and the 'NDST' filed of vCPU0's posted-interrupt descriptor is pCPU0 2. vCPU0 is HLT'ed and vCPU1 is currently running on pCPU0. 3. An external interrupt from an assigned device happens, the destination of this interrupt will be determined as above flow (IRTE -- posted-interrupt descriptor address/vCPU -- notification event to 'NDST'), If this external interrupt is for vCPU0, the notification event will be delivered to pCPU0 since the 'NDST' field of vCPU0's posted-interrupt descriptor is pCPU0. if we use the current (global) vector for the notification event for vCPU0 in the above case, since the current global vector (notification vector) is a particular vector to CPU, vCPU1 will consume it while vCPU1 is currently running on pCPU0, so we failed to wake up the HLT'ed vCPU0. please refer to Section 29.6 in the Intel SDM about how CPU handles this particular vector: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-ar chitectures-software-developer-manual-325462.pdf After introducing a new global vector naming 'pi_wakeup_vector', before vCPU is being HLT'ed, we set The 'NV' filed (Notification Vector) in the vCPU's posted-interrupt descriptor to 'pi_wakeup_vector', and this is a normal vector to CPU and CPU will not do special things for it (different from the current global vector). In the handler of this vector, we can wake up the HLT'ed vCPU. So suppose you have more than on vCPU which most recently ran on pCPU0 - how will the handler for the new vector know which of the vCPU-s it should kick? And if it can know, why couldn't the handler for posted_intr_vector not know either (i.e. after introducing a specific handler for it in place of the currently used event_check_interrupt)? (One of the reasons I'm asking, i.e. apart from wanting to understand the model, is the limited amount of vectors we have.) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m
On 03/04/2015 03:06 PM, Tamas K Lengyel wrote: Right. The key observation is that at any single point in time, a given hardware thread can be fetching an instruction or reading data, but not both. Fine, as long as an instruction reading itself isn't going to lead to a live lock. That's not how the hardware works. By the time you figure out that the instruction you are executing reads memory, the instruction itself has been fetched and decoded. That won't happen again during this execution. Can you explain? If the instruction faults and is returned to, execution starts again, right? So for an instruction that reads itself: - the fetch succeeds; - the read fails, and we fault; - the hypervisor switches from mapping MFN 1 (--x) to MFN 2 (r--); - the hypervisor returns to the guest. Are you relying on the icache/trace cache/whatever to restart the instruction from a cached value rather than fault immediately? (Because the hypervisor didn't flush the TLB when it changed the mapping)? Nope. I just typed before drinking enough coffee. That whole answer was bogus. Of course, if an instruction reads itself you can get a live lock using these techniques, but it's a software-induced live lock and software can avoid it. One way is compare the address being read with the instruction pointer, and if they are on the same page emulate instead of switching p2m's. Ed Hi Ed, we have been poking at this idea of achieving singlestepping through altp2m view-switching (which would be supported by the VMFUNC EPTP-switching) and the problem discussed above is not limited to instructions that perform data accesses on the same page where the instruction executing was fetched from. In order to achieve true single-stepping, the immediate next instruction should be causing an EPT violation. Let's assume we trap an instruction that only performs data accesses on pages other than the one the instruction was fetched from. Since the instruction fetch is repeated after a failed data access due to EPT violation, the page containing the instruction has to be at least --x and the pages that will be touched by it rw- (or the proper combination or r-- and rw-) simultaneously in order to avoid getting into a live-lock. This results in all subsequent instruction fetches to succeed from the original page. Furthermore, as long as all such subsequent instructions keep accessing only the pages touched by the first instruction, we could end up missing a good chunk of code execution. Is there something we are missing here or is this a known limitation to the EPT-based singlestepping mechanism? Or is there something in the way VMFUNC is implemented that will avoid this limitation? Thanks, Tamas If you truly need single-step, then there is no alternative to doing that the traditional way using TF. What I was hinting at before (and I seem to have offended you by doing so) is that if your only reason for single-stepping is to revert a view switch, then depending on your use-case the single-step may be avoidable. At the risk of offending you again, I still can't talk about that in more detail. Is there any chance you might reconsider your decision not to help with toolstack support of the patch series? I'm still trying to find an internal resource to do that work, but right now it's the biggest risk I see to getting the series into 4.6. Since this discussion has started up again, I should tell you that after today I probably won't be able to post to the list until next week. Ed ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [MirageOS-devel] GSoC 2015 - Not accepted ... but some mentoring organisations which have several Xen related projects in them are
I noticed this the other day and had a quick scout around. Mozilla not accepted for Google Summer of Code 2015 http://blog.queze.net/post/2015/03/03/Mozilla-not-accepted-for-Google-Summer-of-Code-2015 Google’s program is enormously popular, and over-subscribed, meaning Google has had to rotate organisation membership http://news.open-bio.org/news/2015/03/sadly-obf-not-accepted-for-gsoc-2015/ Very unfortunate as we've had interest in the MirageOS projects. I wondered about talking to relevant accepted orgs about adding some MirageOS projects but haven't really had a chance to look into this. Best wishes, Amir On 4 Mar 2015, at 17:31, Lars Kurth lars.kurth@gmail.com wrote: Hi folks, just a quick note to let you know that we were not accepted for GSoC this year. Do note that the Linux Foundation, OpenStack Foundation and many of the other usual suspects have not been accepted this year. We will find out more why on Friday. However, there are at least 4 Xen related projects that are managed by other I made a note at the top of http://wiki.xenproject.org/wiki/Archived/GSoC_2015 to point applicants to some of those projects. I have found 5 so far (which may bot be a complete list): • Xen based Hypervisor in a Box @ Centos • Xen guest support for OpenBSD @ Open BSD Foundation • 3 Xen related projects @ Ganeti Other projects which were accepted are QEMU: note that there are no Xen related projects, but given that Xen has good relationships with the QEMU community we may be able to get one or two projects onto the list if someone steps up and is willing to mentor Best Regards Lars ___ MirageOS-devel mailing list mirageos-de...@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.3-testing test] 35867: regressions - trouble: blocked/broken/fail/pass
flight 35867 xen-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35867/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 35702 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt 9 guest-start fail like 35702 test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 35702 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail like 35702 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 test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 5 xen-boot fail never pass test-armhf-armhf-xl-sedf-pin 5 xen-boot fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-armhf-armhf-xl-midway5 xen-boot fail never pass test-armhf-armhf-xl-multivcpu 5 xen-boot fail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass version targeted for testing: xen 75cd1503a683aa92f73730f1b21e80d1223b043a baseline version: xen eb3594ca13e36f4a1826fef1e4bd8f62cd31dc99 People who touched revisions under test: Jan Beulich jbeul...@suse.com jobs: 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 fail test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd 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 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64
[Xen-devel] [PATCH] drop Joseph Cihula from TXT section
... because of him indicating that he hasn't been working on it for the past 4+ years. Signed-off-by: Jan Beulich jbeul...@suse.com --- a/MAINTAINERS +++ b/MAINTAINERS @@ -180,7 +180,6 @@ F: tools/debugger/kdd/ INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT) -M: Joseph Cihula joseph.cih...@intel.com M: Gang Wei gang@intel.com M: Shane Wang shane.w...@intel.com S: Supported ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 35810: regressions - FAIL
On 04.03.15 at 04:26, ian.jack...@eu.citrix.com wrote: flight 35810 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35810/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumpuserxen-amd64 5 xen-bootfail REGR. vs. 34629 test-amd64-amd64-libvirt 5 xen-boot fail REGR. vs. 34629 test-amd64-amd64-xl-pvh-intel 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-rhel6hvm-intel 5 xen-bootfail REGR. vs. 34629 test-amd64-i386-qemut-rhel6hvm-amd 5 xen-bootfail REGR. vs. 34629 test-amd64-i386-qemut-rhel6hvm-intel 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-qemuu-rhel6hvm-amd 5 xen-bootfail REGR. vs. 34629 test-amd64-i386-freebsd10-i386 5 xen-bootfail REGR. vs. 34629 test-amd64-i386-xl-qemut-winxpsp3 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-qemuu-winxpsp3 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-qemuu-ovmf-amd64 5 xen-boot fail REGR. vs. 34629 test-amd64-amd64-xl-winxpsp3 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-winxpsp3 5 xen-boot fail REGR. vs. 34629 test-amd64-amd64-xl-qemut-winxpsp3 5 xen-bootfail REGR. vs. 34629 The several ones I looked at all have an undue delay after Starting MTA:, which I assume was related to some infrastructure issue (and hence we should disregard). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Ping: [PATCH 0/2] x86: tboot adjustments
(re-adding xen-devel to Cc) On 04.03.15 at 08:59, joseph.cih...@intel.com wrote: FYI, I no longer work on tboot (haven't for 4+ years). Jimmy is still Mr. tboot, however ;-) Thanks for letting us know. I'll send a patch to update ./MAINTAINERS then. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC V2 1/5] libxl: add pvusb definitions
On 3/4/2015 at 01:15 AM, in message 54f5ec4e.6020...@eu.citrix.com, George Dunlap george.dun...@eu.citrix.com wrote: On 01/19/2015 08:28 AM, Chunyan Liu wrote: To attach a usb device, a virtual usb controller should be created first. This patch defines usbctrl and usbdevice related structs. Signed-off-by: Chunyan Liu cy...@suse.com Signed-off-by: Simon Cao caobosi...@gmail.com Chunyan, thanks for picking up this work! A couple of things. First, I think that having the IDL stuff separate from the patches where they are used actually makes it *harder* to review, because you can't easily go to the code where it's used and see what's actually happening. I think that the IDL stuff used in patch 3 should be in patch 3; and the domain creation IDL stuff should be included in patch 5. Tha's OK. I'll update. --- tools/libxl/libxl_types.idl | 58 +++- tools/libxl/libxl_types_internal.idl | 1 + 2 files changed, 58 insertions(+), 1 deletion(-) diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 1214d2e..0639434 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -111,6 +111,16 @@ libxl_nic_type = Enumeration(nic_type, [ (2, VIF), ]) +libxl_usbctrl_type = Enumeration(usbctrl_type,[ +(0, AUTO), +(1, PV), +(2, DEVICEMODEL), +]) + +libxl_usb_type = Enumeration(device_usb_type, [ +(1, HOSTDEV), +]) + libxl_action_on_shutdown = Enumeration(action_on_shutdown, [ (1, DESTROY), @@ -394,7 +404,7 @@ libxl_domain_build_info = Struct(domain_build_info,[ (ioports, Array(libxl_ioport_range, num_ioports)), (irqs, Array(uint32, num_irqs)), (iomem,Array(libxl_iomem_range, num_iomem)), -(claim_mode, libxl_defbool), +(claim_mode, libxl_defbool), Spurious whitespace change -- please kill this. (event_channels, uint32), (kernel, string), (cmdline, string), @@ -521,6 +531,27 @@ libxl_device_pci = Struct(device_pci, [ (seize, bool), ]) +libxl_device_usbctrl = Struct(device_usbctrl, [ +(name, string), +(type, libxl_usbctrl_type), +(backend_domid, libxl_domid), +(backend_domname, string), +(devid, libxl_devid), +(usb_version, uint8), +(num_ports, uint8), +]) + +libxl_device_usb = Struct(device_usb, [ +(ctrl, integer), +(port, integer), +(intf, string), +(u, KeyedUnion(None, libxl_usb_type, type, +[(hostdev, Struct(None, [ +(hostbus, integer), +(hostaddr, integer) ])) +])) +]) So intf here is wrong. To begin with, it's information specific to the hostdev type; so it would go under the type keyed union under hostdev. Secondly, this requires people to figure out that their media reader has an intf of 1-2.1.1:1.0. I don't think that's a good idea, for two reasons: one, it just seems like a really hard interface to use. I couldn't find any straightforward tools to map USB devices onto intf; Right. One can only use usb-assignable-list for a fast look. That follows the old xend toolstack way. tools like lsusb instead give you a bus:addr combination. Secondly, it's inconsistent with qemu -- which means we'd either have to have two different ways of specifying the device, or we'd need to translate from intf back into bus:addr You are right. Using bus:addr could unify qemu and pvusb. I also thought about that. Only concern is it's different from old xend toolstack usage. If that doesn't affect, we can update to use bus:addr, no problem. I think the right thing to do here is to take intf out of this struct, and to translate bus:addr into intf internally. It looks like the values qemu and lsusb use can be found in busnum and devnum in the sysfs files. You've already got code to scan those devices; you just need to add a bit of code to find which of those corresponds to a given hostbus:hostaddr combination. + libxl_device_vtpm = Struct(device_vtpm, [ (backend_domid,libxl_domid), (backend_domname, string), @@ -547,6 +578,7 @@ libxl_domain_config = Struct(domain_config, [ (disks, Array(libxl_device_disk, num_disks)), (nics, Array(libxl_device_nic, num_nics)), (pcidevs, Array(libxl_device_pci, num_pcidevs)), +(usbs, Array(libxl_device_usb, num_usbs)), Any reason you don't make it possible to specify usb controllers as well? For qemu emulated HVM usb device, usb controller is created by qemu, no way to specify it (?) Also I wonder if specifying usb controller is necessary, seems it won't affect without usb controller here. Correct me if I'm wrong. If it's
Re: [Xen-devel] ./configure: line 7058: python-config: command not found after commit 0013245
On Tue, 2015-03-03 at 19:41 +, Julien Grall wrote: python-dev is not installed. Although I have libpython-dev installed. And this used to work I suppose? As I said in 1425404173.25940.82.ca...@citrix.com: m4/python_devel.m4 seems to suggest it was made optional on purpose, I don't know why or which versions of Python were the first to include the tool though. So it appears to be deliberate that the Python checks do not require python-config. But the new Python vs. Fortify checks _do_ require it. So the question is: why was it optional in the first place? Then we should know if we can make it a requirement or if we need to fix the Fortify check. Aha, adding --follow to my earlier git log m4/python_devel.m4 leads me to: commit 474a0e59d821bfb49b64c3d722a000bd9b5b7599 Author: Roger Pau Monne roger@entel.upc.edu Date: Tue Apr 3 14:28:45 2012 +0100 autoconf: fix python-dev detection on old python versions Replaced the use of python-config (that is only present in Python = 2.5.x) with the distutils python module. Signed-off-by: Roger Pau Monne roger@entel.upc.edu Cc: Zhang, Yang Z yang.z.zh...@intel.com Tested-by: KUWAMURA Shin'ya k...@jp.fujitsu.com Cc: Ian Campbell ian.campb...@citrix.com Committed-by: Ian Jackson ian.jack...@eu.citrix.com So it seems like it is necessary to continue to work without python-config present. In my same earlier mail I said: Perhaps AX_CHECK_PYTHON_FORTIFY_NOOPT should be a nop unless python-config is available? Or perhaps AX_CHECK_PYTHON_DEVEL should export PYTHON_CFLAGS etc which the fortify test should look at instead of invoking python-cofnig? I think it would be acceptable in the first instance to simply only run the Fortify check if python-config is present and hope that older distros didn't have the incompatibility. If we then find such an older distro then we can look at switching to something more complex. Can someone cook up a patch please? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1 2/2] xen-netback: unref frags when handling a from-guest skb with a frag list
On Tue, 2015-03-03 at 16:26 +, David Vrabel wrote:
Every time a VIF is destroyed up-to 256 pages may be leaked if packets
with more than MAX_SKB_FRAGS frags where transmitted from the guest.
Even worse, if another user of ballooned pages allocated one of these
ballooned pages it would not handle the the unexpectedly non-zero page
count (e.g., gntdev would deadlock when unmapping a grant because the
page count would never reach 1).
When handling a from-guest skb with a frag list, unref the frags
before releasing them so they are freed correctly when the VIF is
destroyed.
Am I right that the majority of the first 2 hunks (and various bits of
the 3rd) are just switching the outer loop to nr_frags instead of i, to
free up i for use in the new code below? And also to switch j to the now
available i in the inner loop.
Also swap over to the new (local) frags /after/ calling the skb
destructor. This isn't strictly necessary but it's less confusing.
My only concern would be that this now means there is a period where the
frags list is invalid. However I think the calling context is such that
nobody else can have a reference to an skb which has the same shinfo as
the one in our hand. Is that right?
(If not then I think the old code was also buggy/racy, but with a
smaller window)
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/net/xen-netback/netback.c | 43
+++--
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index f7a31d2..3d06eeb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1343,7 +1343,7 @@ static int xenvif_handle_frag_list(struct xenvif_queue
*queue, struct sk_buff *s
{
unsigned int offset = skb_headlen(skb);
skb_frag_t frags[MAX_SKB_FRAGS];
- int i;
+ int i, nr_frags;
struct ubuf_info *uarg;
struct sk_buff *nskb = skb_shinfo(skb)-frag_list;
@@ -1357,17 +1357,16 @@ static int xenvif_handle_frag_list(struct
xenvif_queue *queue, struct sk_buff *s
skb-data_len += nskb-len;
/* create a brand new frags array and coalesce there */
- for (i = 0; offset skb-len; i++) {
+ for (nr_frags = 0; offset skb-len; nr_frags++) {
struct page *page;
unsigned int len;
- BUG_ON(i = MAX_SKB_FRAGS);
+ BUG_ON(nr_frags = MAX_SKB_FRAGS);
page = alloc_page(GFP_ATOMIC);
if (!page) {
- int j;
skb-truesize += skb-data_len;
- for (j = 0; j i; j++)
- put_page(frags[j].page.p);
+ for (i = 0; i nr_frags; i++)
+ put_page(frags[i].page.p);
return -ENOMEM;
}
@@ -1379,27 +1378,29 @@ static int xenvif_handle_frag_list(struct
xenvif_queue *queue, struct sk_buff *s
BUG();
offset += len;
- frags[i].page.p = page;
- frags[i].page_offset = 0;
- skb_frag_size_set(frags[i], len);
+ frags[nr_frags].page.p = page;
+ frags[nr_frags].page_offset = 0;
+ skb_frag_size_set(frags[nr_frags], len);
}
- /* swap out with old one */
- memcpy(skb_shinfo(skb)-frags,
-frags,
-i * sizeof(skb_frag_t));
- skb_shinfo(skb)-nr_frags = i;
- skb-truesize += i * PAGE_SIZE;
-
- /* remove traces of mapped pages and frag_list */
+
+ /* Copied all the bits from the frag list -- free it. */
skb_frag_list_init(skb);
- uarg = skb_shinfo(skb)-destructor_arg;
- /* increase inflight counter to offset decrement in callback */
+ xenvif_skb_zerocopy_prepare(queue, nskb);
+ kfree_skb(nskb);
+
+ /* Release all the original (foreign) frags. */
+ for (i = 0; i skb_shinfo(skb)-nr_frags; i++)
+ skb_frag_unref(skb, i);
atomic_inc(queue-inflight_packets);
+ uarg = skb_shinfo(skb)-destructor_arg;
uarg-callback(uarg, true);
skb_shinfo(skb)-destructor_arg = NULL;
- xenvif_skb_zerocopy_prepare(queue, nskb);
- kfree_skb(nskb);
+ /* Fill the skb with the new (local) frags. */
+ memcpy(skb_shinfo(skb)-frags, frags,
+nr_frags * sizeof(skb_frag_t));
+ skb_shinfo(skb)-nr_frags = nr_frags;
+ skb-truesize += nr_frags * PAGE_SIZE;
return 0;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC V2 1/5] libxl: add pvusb definitions
On Wed, 2015-03-04 at 00:26 -0700, Chun Yan Liu wrote: On 3/3/2015 at 07:10 PM, in message 1425381019.24959.87.ca...@citrix.com, Ian Campbell ian.campb...@citrix.com wrote: On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote: Sorry for the long delay in replying. To attach a usb device, a virtual usb controller should be created first. This patch defines usbctrl and usbdevice related structs. Per 54ca17df026600095...@relay2.provo.novell.com please could you mention here that the HVM guest related parts (i.e. LIBXL_USBCTRL_TYPE_DEVICEMODEL) and libxl_usb_type are placeholders for emulated HVM support. Yes, I agree it's better placed in libxl_usb_type rather than ctrl_type. In fact I wonder if it should just be omitted, we will need a LIBXL_HAVE for HVM USB support anyway once it is implemented so we can add the enum then. It won't harm to omit it for current pvusb work. Acceptable to me to add enum later when adding HVM qemu emulated usb device implementation. I suppose users of libxl would like to be able to expose to their users whether or not HVM USB passthrough will work (i.e. to hide UI options). So I think we will want the #define eventually so they can know at compile time if HVM USB will work. We could add a negative one now (LIBXC_NO_HVM_USB_PASSTHROUGH) and remove it later, but that's icky I think. So I think omit the HVM stuff for now, it's less confusing overall that way. George, is that OK with you? +]) + +libxl_device_usb = Struct(device_usb, [ +(ctrl, integer), Is this an index into something? If so what? To usb controller index. A usb device should be connected to a usb port of a usb controller. e.g.: there is 2 usb controllers in system, each with 8 ports, then: 1st usb controller index will be 0, port will be 1~8. 2nd usb controller index will be 1, port will be 1~8. To attach a usb device through pvusb way, it should be pointed to connect to which controller and which port. I guess what I'm missing is how do I create this controller? I saw nothing in the guest cfg which would allow me to create one. Is there some way to say I don't care, find a controller and use it? There seems to be no usbctrl array added to the domain_config struct, so I'm unsure how this is used. +(port, integer), Port on the hub? +(intf, string), What is this one? (This may just be my lack of usb knowledge) It means sysfs interface for the usb device under /sys/bus/usb/devices/, like: 2-1.6. Thanks. I think given Georges feedback we will be dropping this? ntly not used. + @@ -547,6 +578,7 @@ libxl_domain_config = Struct(domain_config, [ (disks, Array(libxl_device_disk, num_disks)), (nics, Array(libxl_device_nic, num_nics)), (pcidevs, Array(libxl_device_pci, num_pcidevs)), +(usbs, Array(libxl_device_usb, num_usbs)), So, I'm unsure how this interacts with the controllers, which it doesn't seem to be possible to specify at domain build time. In domain config, user only needs to specify usb=['2-1.6'], by default, it will create a default usb contoller, and probe the 1st available controller:port for the usb device to attach. So, it can work to specify usbs here only. Reason didn't include controller in libxl_domain_config: for HVM qemu emulated usb device, all work is done in qemu (create usb controller and attach usb device), no controller exists in libxl in that case. OK, so it's an HVM only thing. I think that makes sense, but then how does the libxl_device_usb.ctrl field make sense or how do I use it? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11] tools, docs: add total/local memory bandwith monitoring
Add Memory Bandwidth Monitoring(MBM) for VMs. Two types of monitoring
are supported: total and local memory bandwidth monitoring. To use it,
CMT should be enabled in hypervisor.
Signed-off-by: Chao Peng chao.p.p...@linux.intel.com
---
Changes in v11:
1. term change: *_MEM_BANDWIDTH = *_MEM_COUNT.
2. Add assert(nr = ARRAY_SIZE(entries)).
Changes in v10:
1. Move refactoring code into standalone patch.
2. Create generic interface libxl_psr_cmt_get_sample for both
cache_occupancy and memory bandwith.
Changes in v9:
1. Refactor code in xc_psr_cmt_get_data.
2. Move bandwidth calculation(sleep) from libxl to xl.
3. Broadcast feature with LIBXL_HAVE_PSR_MBM.
4. Check event mask with libxl_psr_cmt_type_supported.
5. Coding style/Document fix.
Changes in v6:
1. Remove DISABLE_IRQ flag as hypervisor disable IRQ for MSR_IA32_TSC
implicitly.
Changes in v5:
1. Add MBM description in xen command line.
2. Use the tsc from hypervisor directly which is already ns.
3. Call resource_op with DISABLE_IRQ flag.
Changes in v4:
1. Get timestamp from hypervisor and use that for bandwidth calculation.
2. Minor document and coding style fix.
---
docs/man/xl.pod.1 | 11 -
docs/misc/xen-command-line.markdown | 3 ++
tools/libxc/include/xenctrl.h | 6 ++-
tools/libxc/xc_msr_x86.h| 1 +
tools/libxc/xc_psr.c| 47 ++-
tools/libxl/libxl.h | 17 +++
tools/libxl/libxl_psr.c | 56 ++-
tools/libxl/libxl_types.idl | 2 +
tools/libxl/xl_cmdimpl.c| 90 ++---
tools/libxl/xl_cmdtable.c | 4 +-
10 files changed, 207 insertions(+), 30 deletions(-)
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 6b89ba8..cd80ffc 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1461,6 +1461,13 @@ is domain level. To monitor a specific domain, just
attach the domain id with
the monitoring service. When the domain doesn't need to be monitored any more,
detach the domain id from the monitoring service.
+Intel Broadwell and later server platforms also offer total/local memory
+bandwidth monitoring. Xen supports per-domain monitoring for these two
+additional monitoring types. Both memory bandwidth monitoring and L3 cache
+occupancy monitoring share the same set of underlying monitoring service. Once
+a domain is attached to the monitoring service, monitoring data can be showed
+for any of these monitoring types.
+
=over 4
=item Bpsr-cmt-attach [Idomain-id]
@@ -1475,7 +1482,9 @@ detach: Detach the platform shared resource monitoring
service from a domain.
Show monitoring data for a certain domain or all domains. Current supported
monitor types are:
- - cache-occupancy: showing the L3 cache occupancy.
+ - cache-occupancy: showing the L3 cache occupancy(KB).
+ - total-mem-bandwidth: showing the total memory bandwidth(KB/s).
+ - local-mem-bandwidth: showing the local memory bandwidth(KB/s).
=back
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index bc316be..a09ec01 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1097,6 +1097,9 @@ The following resources are available:
L3 cache occupancy.
* `cmt` instructs Xen to enable/disable Cache Monitoring Technology.
* `rmid_max` indicates the max value for rmid.
+* Memory Bandwidth Monitoring (Broadwell and later). Information regarding the
+ total/local memory bandwidth. Follow the same options with Cache Monitoring
+ Technology.
### reboot
`= t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]`
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 09d819f..df18292 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2688,6 +2688,8 @@ int xc_resource_op(xc_interface *xch, uint32_t nr_ops,
xc_resource_op_t *ops);
#if defined(__i386__) || defined(__x86_64__)
enum xc_psr_cmt_type {
XC_PSR_CMT_L3_OCCUPANCY,
+XC_PSR_CMT_TOTAL_MEM_COUNT,
+XC_PSR_CMT_LOCAL_MEM_COUNT,
};
typedef enum xc_psr_cmt_type xc_psr_cmt_type;
int xc_psr_cmt_attach(xc_interface *xch, uint32_t domid);
@@ -2697,10 +2699,12 @@ int xc_psr_cmt_get_domain_rmid(xc_interface *xch,
uint32_t domid,
int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t *total_rmid);
int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
uint32_t *upscaling_factor);
+int xc_psr_cmt_get_l3_event_mask(xc_interface *xch, uint32_t *event_mask);
int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
uint32_t *l3_cache_size);
int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid, uint32_t cpu,
-uint32_t psr_cmt_type, uint64_t *monitor_data);
+uint32_t psr_cmt_type, uint64_t *monitor_data,
+uint64_t *tsc);
int
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
On 03/04/2015 11:06 AM, Ian Campbell wrote: On Wed, 2015-03-04 at 09:42 +, Jan Beulich wrote: On 04.03.15 at 10:35, ian.campb...@citrix.com wrote: On Wed, 2015-03-04 at 08:58 +, Jan Beulich wrote: On 03.03.15 at 11:32, jgr...@suse.com wrote: On 03/03/2015 11:27 AM, Jan Beulich wrote: On 03.03.15 at 10:29, jgr...@suse.com.non-mime.internet wrote: In order to indicate the Xen tools capability to support the virtual mapped linear p2m list instead the 3 level mfn tree add a flag to the start_info page. Signed-off-by: Juergen Gross jgr...@suse.com --- xen/include/public/xen.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 3703c39..36c6d62 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -777,6 +777,8 @@ typedef struct start_info start_info_t; #define SIF_INITDOMAIN(11) /* Is this the initial control domain? */ #define SIF_MULTIBOOT_MOD (12) /* Is mod_start a multiboot module? */ #define SIF_MOD_START_PFN (13) /* Is mod_start a PFN? */ +#define SIF_VIRT_P2M (14) /* Does Xen understand a virt. mapped P-M */ + /* making the 3 level tree obsolete? */ #define SIF_PM_MASK (0xFF8) /* reserve 1 byte for xen-pm options */ /* Is there any reason why this can't be part of the tools patch (series) actually going to make use of it? The main reason is I want to make use of it in the related kernel series first. And this requires the Xen header implementation. I was about to apply v3, but I'm still unconvinced: How would you test those kernel side changes without having anything to set the flag? It does seem odd to be committing to an ABI with no xen.git side implementation having been posted yet. Normally we ask that things go into xen.git first before any guests start using them. Your reply seems ambiguous to me: If it was sent to Jürgen (with me Cc-ed) I'd read it as supporting my earlier statement. Since, however, it was sent to me (with Jürgen Cc-ed), I could also read it as supporting the public header change alone to go in (even if in slight collision with the word implementation in there). Could you clarify? Sorry, I was in support of you (Jan) here. Sometime an ABI header change might be all which is needed before guests start using things (e.g. an io protocol change), but I think in this case we really need to at least have seen the complete solution (so any relevant Xen/tools changes) before we commit to an ABI. It _might_ be sufficient if this patch included some documentation about what this flag actually means, but best would be to see the actual tools side (or even a design, sorry if I've missed this somewhere along the line). What I don't want to happen is for me to request a change during tools review only to be told kernels in the field already do it this way. I'd like to do an appropriate change in xl, but I've been told this would make sense only for migration protocol V2. OTOH I don't want to wait for an undefined amount of time until this will be posted, so I sent the ABI change first. I could, of course, wait with the flag bit until xl is ready and post another kernel patch then. Unfortunately this would delay Linux support for automatically be able to run as a pv-domain 500GB further, so I strongly recommend accepting the interface change now. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-scsiback: use DRV_PFX in the pr macros
Hi, Juergen.
Thanks for your advice. I will send a v2 patch based on your suggested
modifications.
On 2015/3/3 17:52, Juergen Gross wrote:
On 03/03/2015 09:37 AM, Tao Chen wrote:
Replace the string of {xen-pvscsi:} in the pr sentences with DRV_PFX,
it makes the code easier to read.
I'm not really convinced this is worth a patch. OTOH I'm not completely
against it. If nobody rejects this and all my further comments are
addressed you can have my:
Acked-by: Juergen Gross jgr...@suse.com
Signed-off-by: Tao Chen boby.c...@huawei.com
---
drivers/xen/xen-scsiback.c | 67
+++---
1 file changed, 34 insertions(+), 33 deletions(-)
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 9faca6a..307100d 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -69,6 +69,7 @@
#include xen/interface/grant_table.h
#include xen/interface/io/vscsiif.h
+#define DRV_PFX xen-pvscsi:
Using xen-pvscsi: wouldn't delete the white space after the colon in
most messages.
#define DPRINTK(_f, _a...)\
pr_debug((file=%s, line=%d) _f, __FILE__ , __LINE__ , ## _a)
@@ -84,7 +85,7 @@ struct ids_tuple {
struct v2p_entry {
struct ids_tuple v;/* translate from */
-struct scsiback_tpg *tpg;/* translate to */
+struct scsiback_tpg *tpg;/* translate to */
Unrelated white space change (others as well). Either omit them or
mention them in the commit message.
unsigned int lun;
struct kref kref;
struct list_head l;
@@ -271,7 +272,7 @@ static void scsiback_print_status(char
*sense_buffer, int errors,
{
struct scsiback_tpg *tpg = pending_req-v2p-tpg;
-pr_err(xen-pvscsi[%s:%d] cmnd[0]=%02x - st=%02x msg=%02x
host=%02x drv=%02x\n,
+pr_err(DRV_PFX [%s:%d] cmnd[0]=%02x - st=%02x msg=%02x
host=%02x drv=%02x\n,
tpg-tport-tport_name, pending_req-v2p-lun,
pending_req-cmnd[0], status_byte(errors), msg_byte(errors),
host_byte(errors), driver_byte(errors));
@@ -427,7 +428,7 @@ static int scsiback_gnttab_data_map_batch(struct
gnttab_map_grant_ref *map,
BUG_ON(err);
for (i = 0; i cnt; i++) {
if (unlikely(map[i].status != GNTST_okay)) {
-pr_err(xen-pvscsi: invalid buffer -- could not remap
it\n);
+pr_err(DRV_PFX invalid buffer -- could not remap it\n);
map[i].handle = SCSIBACK_INVALID_HANDLE;
err = -ENOMEM;
} else {
@@ -449,7 +450,7 @@ static int scsiback_gnttab_data_map_list(struct
vscsibk_pend *pending_req,
for (i = 0; i cnt; i++) {
if (get_free_page(pg + mapcount)) {
put_free_pages(pg, mapcount);
-pr_err(xen-pvscsi: no grant page\n);
+pr_err(DRV_PFX no grant page\n);
return -ENOMEM;
}
gnttab_set_map_op(map[mapcount], vaddr_page(pg[mapcount]),
@@ -492,7 +493,7 @@ static int scsiback_gnttab_data_map(struct
vscsiif_request *ring_req,
return 0;
if (nr_segments VSCSIIF_SG_TABLESIZE) {
-DPRINTK(xen-pvscsi: invalid parameter nr_seg = %d\n,
+DPRINTK(DRV_PFX invalid parameter nr_seg = %d\n,
As DPRINTK already contains the file name, you can omit the prefix.
Alternatively include DRV_PFX in the DPRINTK macro.
ring_req-nr_segments);
return -EINVAL;
}
@@ -516,13 +517,13 @@ static int scsiback_gnttab_data_map(struct
vscsiif_request *ring_req,
nr_segments += n_segs;
}
if (nr_segments SG_ALL) {
-DPRINTK(xen-pvscsi: invalid nr_seg = %d\n,
+DPRINTK(DRV_PFX invalid nr_seg = %d\n,
nr_segments);
return -EINVAL;
}
}
-/* free of (sgl) in fast_flush_area()*/
+/* free of (sgl) in fast_flush_area() */
pending_req-sgl = kmalloc_array(nr_segments,
sizeof(struct scatterlist), GFP_KERNEL);
if (!pending_req-sgl)
@@ -679,7 +680,7 @@ static int prepare_pending_reqs(struct
vscsibk_info *info,
v2p = scsiback_do_translation(info, vir);
if (!v2p) {
pending_req-v2p = NULL;
-DPRINTK(xen-pvscsi: doesn't exist.\n);
+DPRINTK(DRV_PFX doesn't exist.\n);
return -ENODEV;
}
pending_req-v2p = v2p;
@@ -690,14 +691,14 @@ static int prepare_pending_reqs(struct
vscsibk_info *info,
(pending_req-sc_data_direction != DMA_TO_DEVICE)
(pending_req-sc_data_direction != DMA_FROM_DEVICE)
(pending_req-sc_data_direction != DMA_NONE)) {
-DPRINTK(xen-pvscsi: invalid parameter data_dir = %d\n,
+DPRINTK(DRV_PFX invalid parameter data_dir = %d\n,
pending_req-sc_data_direction);
return -EINVAL;
}
pending_req-cmd_len = ring_req-cmd_len;
if (pending_req-cmd_len VSCSIIF_MAX_COMMAND_SIZE) {
-DPRINTK(xen-pvscsi: invalid parameter cmd_len = %d\n,
+
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
On Wed, 2015-03-04 at 08:58 +, Jan Beulich wrote: On 03.03.15 at 11:32, jgr...@suse.com wrote: On 03/03/2015 11:27 AM, Jan Beulich wrote: On 03.03.15 at 10:29, jgr...@suse.com.non-mime.internet wrote: In order to indicate the Xen tools capability to support the virtual mapped linear p2m list instead the 3 level mfn tree add a flag to the start_info page. Signed-off-by: Juergen Gross jgr...@suse.com --- xen/include/public/xen.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 3703c39..36c6d62 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -777,6 +777,8 @@ typedef struct start_info start_info_t; #define SIF_INITDOMAIN(11) /* Is this the initial control domain? */ #define SIF_MULTIBOOT_MOD (12) /* Is mod_start a multiboot module? */ #define SIF_MOD_START_PFN (13) /* Is mod_start a PFN? */ +#define SIF_VIRT_P2M (14) /* Does Xen understand a virt. mapped P-M */ + /* making the 3 level tree obsolete? */ #define SIF_PM_MASK (0xFF8) /* reserve 1 byte for xen-pm options */ /* Is there any reason why this can't be part of the tools patch (series) actually going to make use of it? The main reason is I want to make use of it in the related kernel series first. And this requires the Xen header implementation. I was about to apply v3, but I'm still unconvinced: How would you test those kernel side changes without having anything to set the flag? It does seem odd to be committing to an ABI with no xen.git side implementation having been posted yet. Normally we ask that things go into xen.git first before any guests start using them. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
On 04.03.15 at 10:35, ian.campb...@citrix.com wrote: On Wed, 2015-03-04 at 08:58 +, Jan Beulich wrote: On 03.03.15 at 11:32, jgr...@suse.com wrote: On 03/03/2015 11:27 AM, Jan Beulich wrote: On 03.03.15 at 10:29, jgr...@suse.com.non-mime.internet wrote: In order to indicate the Xen tools capability to support the virtual mapped linear p2m list instead the 3 level mfn tree add a flag to the start_info page. Signed-off-by: Juergen Gross jgr...@suse.com --- xen/include/public/xen.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 3703c39..36c6d62 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -777,6 +777,8 @@ typedef struct start_info start_info_t; #define SIF_INITDOMAIN(11) /* Is this the initial control domain? */ #define SIF_MULTIBOOT_MOD (12) /* Is mod_start a multiboot module? */ #define SIF_MOD_START_PFN (13) /* Is mod_start a PFN? */ +#define SIF_VIRT_P2M (14) /* Does Xen understand a virt. mapped P-M */ + /* making the 3 level tree obsolete? */ #define SIF_PM_MASK (0xFF8) /* reserve 1 byte for xen-pm options */ /* Is there any reason why this can't be part of the tools patch (series) actually going to make use of it? The main reason is I want to make use of it in the related kernel series first. And this requires the Xen header implementation. I was about to apply v3, but I'm still unconvinced: How would you test those kernel side changes without having anything to set the flag? It does seem odd to be committing to an ABI with no xen.git side implementation having been posted yet. Normally we ask that things go into xen.git first before any guests start using them. Your reply seems ambiguous to me: If it was sent to Jürgen (with me Cc-ed) I'd read it as supporting my earlier statement. Since, however, it was sent to me (with Jürgen Cc-ed), I could also read it as supporting the public header change alone to go in (even if in slight collision with the word implementation in there). Could you clarify? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: introduce clear_fixmap()
On 04/03/15 09:10, Jan Beulich wrote:
... making more obvious what its so far open coded users intend.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -310,7 +310,7 @@ void free_vcpu_guest_context(struct vcpu
{
if ( !per_cpu(vgc_pages[i], cpu) )
continue;
-__set_fixmap(idx - i, 0, 0);
+clear_fixmap(idx - i);
free_domheap_page(per_cpu(vgc_pages[i], cpu));
per_cpu(vgc_pages[i], cpu) = NULL;
}
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2552,7 +2552,7 @@ void __init init_ioapic_mappings(void)
if ( bad_ioapic_register(i) )
{
-__set_fixmap(idx, 0, 0);
+clear_fixmap(idx);
continue;
}
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -541,7 +541,7 @@ static inline void __init construct_defa
static __init void efi_unmap_mpf(void)
{
if (efi_enabled)
- __set_fixmap(FIX_EFI_MPF, 0, 0);
+ clear_fixmap(FIX_EFI_MPF);
}
static struct intel_mp_floating *__initdata mpf_found;
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -112,7 +112,7 @@ static void msix_put_fixmap(struct arch_
if ( --msix-table_refcnt[i] == 0 )
{
-__set_fixmap(idx, 0, 0);
+clear_fixmap(idx);
msix_fixmap_free(idx);
msix-table_idx[i] = 0;
}
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -138,7 +138,7 @@ void __init tboot_probe(void)
TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE);
tboot_copy_memory((unsigned char *)sinit_size, sizeof(sinit_size),
TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE);
-__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0);
+clear_fixmap(FIX_TBOOT_MAP_ADDRESS);
}
/* definitions from xen/drivers/passthrough/vtd/iommu.h
@@ -477,7 +477,7 @@ int __init tboot_parse_dmar_table(acpi_t
dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length);
tboot_copy_memory(dmar_table_raw, dmar_table_length, pa);
dmar_table = (struct acpi_table_header *)dmar_table_raw;
-__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0);
+clear_fixmap(FIX_TBOOT_MAP_ADDRESS);
rc = dmar_handler(dmar_table);
xfree(dmar_table_raw);
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -78,6 +78,8 @@ extern void __set_fixmap(
#define set_fixmap_nocache(idx, phys) \
__set_fixmap(idx, (phys)PAGE_SHIFT, PAGE_HYPERVISOR_NOCACHE)
+#define clear_fixmap(idx) __set_fixmap(idx, 0, 0)
+
#define __fix_to_virt(x) (FIXADDR_TOP - ((x) PAGE_SHIFT))
#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)PAGE_MASK)) PAGE_SHIFT)
___
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] QEMU e820 Reservation (FW_CFG_E820_TABLE and fw_cfg etc/e820)
On Tue, 3 Mar 2015, Gordan Bobic wrote: Hi, I've been looking into custom e820 maps for domUs again, and found that functionality to provide QEMU with hints regarding e820 mapping has been upstream since some time in 2010 (FW_CFG_E820_TABLE) with more finely grained control (usable rather than just reserved entries) upstream since 2013 (fw_cfg etc/e820). The respective patches are here: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00996.html http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00593.html What I have not been able to find is any documentation at all on how this e820 data can be given to QEMU when starting a domain. I can see from the structs in the patches how the data is packed for the relevant code to consume, but I cannot figure out what is the delivery vector for this data. How can I get QEMU to ingest the hints about any additional reserved e820 blocks? For context, I need this to work around IOMMU implementation bugs and mark areas of address space as reserved so that the guest doesn't trample over the host's PCI I/O ranges (which IOMMU should intercept, but being buggy, it doesn't). Many thanks in advance. Hello Gordan, FW_CFG_E820_TABLE is a special interface between SeaBios and QEMU but is not used on Xen. I guess it could be made to work on Xen, but I am pretty sure it doesn't at the moment. I think you would probably want to look at hvmloader instead: tools/firmware/hvmloader/e820.c. Cheers, Stefano ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 17/19] xen/arm: its: Support ITS interrupt handling
On Tue, 3 Mar 2015, Julien Grall wrote: Hi Stefano, On 03/03/2015 18:07, Stefano Stabellini wrote: I would like to see a more generic handling of virq != physical irq. This is not specific to LPIs but to any scenario where the physical irq differs from the virtual irq. I though we talked about it during the meeting at Connect... I've already got a patch for making virq != pirq : https://patches.linaro.org/43012/ That would drop the static 8K added because of the changes in irq_desc. I was pretty sure you had a patch for this already but I didn't have a link to it ready. Your patch could be a requirement for this series. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/5] x86: allow specifying the NUMA nodes Dom0 should run on
On Tue, 2015-03-03 at 10:51 +, Jan Beulich wrote: On 27.02.15 at 15:54, dario.faggi...@citrix.com wrote: The idea is that, whether the mask is full because no one touched this default, or because it has been manually set like that, there is nothing to do at the soft affinity balancing level. In that case I think __vcpu_has_soft_affinity() simply isn't general enough: Along with checking whether all bits are set in the soft affinity, it should also check whether soft is a subset of hard (or the passed in second mask). And really it should imo also cover the case where not all bits are set in the mask, but all those corresponding to online CPUs (both of which ought to have the same effect) I'm fine with this. That would then leave introducing a relaxed (or strict, depending on what we'd like to be the default) mode in the patch here, controlling whether -cpu_hard_affinity gets overridden (and we'd always override -cpu_soft_affinity). And with this too... I'll comment the code in the other email, the one with the patch. Regards, Dario 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 1/2] x86/xen/apic: Work with UP, non-SMP 32-bit kernels.
On 03/03/15 20:29, Konrad Rzeszutek Wilk wrote:
On Tue, Mar 03, 2015 at 03:20:41PM -0500, Konrad Rzeszutek Wilk wrote:
Most of the APIC code that use APIC_LDR is not used on
64-bit. On 32-bit it is bit of an hack - and the mechanism
it is uses is to setup the APIC_LDR via apci-init_apic_ldr
(which we set to NULL) and then use apic-x86_32_early_logical_apicid
to get an CPU to APIC ID mapping and also apic-read to match
the APIC_LDR.
The 'x86_32_early_logical_apicid' is called from 'setup_local_APIC'
which is called from the following functions:
- start_secondary -smp_callin - apic_ap_setup [not called on PV]
- native_smp_prepare_cpus - apci_bsp_setup [not called on PV]
- up_late_init - APIC_init_uniprocessor - apic_bsp_setup
-setup_local_APIC
[called on PV with CONFIG_SMP not defined, CONFIG_X86_32 and UP kernel]
This patch fixes the build issue and also allows the bootup
to continue without warnings.
Reported-by: Boris Ostrovsky boris.ostrov...@oracle.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/xen/apic.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
index 86bea3e..de1c74d 100644
--- a/arch/x86/xen/apic.c
+++ b/arch/x86/xen/apic.c
@@ -56,7 +56,10 @@ static u32 xen_apic_read(u32 reg)
if (reg == APIC_LVR)
return 0x10;
-
+#ifdef CONFIG_X86_32
+if (reg == APIC_LDR)
+return SET_APIC_LOGICAL_ID(1UL smp_processor_id());
+#endif
if (reg != APIC_ID)
return 0;
@@ -117,6 +120,12 @@ static int xen_phys_pkg_id(int initial_apic_id, int
index_msb)
return initial_apic_id index_msb;
}
+static int xen_x86_32_early_logical_apicid(int cpu)
+{
+/* Match with APIC_LDR read. Otherwise setup_local_APIC complains. */
+return 1 cpu;
+}
+
Argh. That should have been wrapped with CONFIG_X86_32 otherwise it will
complain
on 64-bit (not used.. etc).
David, I can commit it in and fix it up.
Can you fold all fixes these into the original patch? No need to
unnecessary break bisection.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 35819: regressions - FAIL
flight 35819 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35819/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 5 xen-boot fail REGR. vs. 35572 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 35572 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: qemuu2dffe5516e74215fadf2e0f5ee401db4d5a86f7a baseline version: qemuu041ccc922ee474693a2869d4e3b59e920c739bc0 People who touched revisions under test: Eduardo Habkost ehabk...@redhat.com Michael S. Tsirkin m...@redhat.com Peter Maydell peter.mayd...@linaro.org jobs: 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 test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd 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-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-amd64-amd64-xl-win7-amd64 fail
Re: [Xen-devel] [PATCHv1 2/2] xen-netback: unref frags when handling a from-guest skb with a frag list
On Wed, 2015-03-04 at 09:56 +, David Vrabel wrote: On 04/03/15 09:48, Ian Campbell wrote: On Tue, 2015-03-03 at 16:26 +, David Vrabel wrote: Every time a VIF is destroyed up-to 256 pages may be leaked if packets with more than MAX_SKB_FRAGS frags where transmitted from the guest. Even worse, if another user of ballooned pages allocated one of these ballooned pages it would not handle the the unexpectedly non-zero page count (e.g., gntdev would deadlock when unmapping a grant because the page count would never reach 1). When handling a from-guest skb with a frag list, unref the frags before releasing them so they are freed correctly when the VIF is destroyed. Am I right that the majority of the first 2 hunks (and various bits of the 3rd) are just switching the outer loop to nr_frags instead of i, to free up i for use in the new code below? And also to switch j to the now available i in the inner loop. Yes. If you prefer I can split this into one patch that adds the skb_frag_unref() calls and one that reorders/refactors. If you can be bothered that might make things easier to read, thanks. Also swap over to the new (local) frags /after/ calling the skb destructor. This isn't strictly necessary but it's less confusing. My only concern would be that this now means there is a period where the frags list is invalid. However I think the calling context is such that nobody else can have a reference to an skb which has the same shinfo as the one in our hand. Is that right? That is correct. This skb is allocated by netback and has not yet been passed up to the network stack. Phew! ;-) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 4/4] tools, docs: add total/local memory bandwith monitoring
On Wed, 2015-03-04 at 09:04 +0800, Chao Peng wrote:
On Tue, Mar 03, 2015 at 10:09:39AM +, Ian Campbell wrote:
On Tue, 2015-03-03 at 16:00 +0800, Chao Peng wrote:
On Mon, Mar 02, 2015 at 01:48:43PM +, Ian Campbell wrote:
On Thu, 2015-02-26 at 16:45 +0800, Chao Peng wrote:
Add Memory Bandwidth Monitoring(MBM) for VMs. Two types of monitoring
are supported: total and local memory bandwidth monitoring. To use it,
CMT should be enabled in hypervisor.
Signed-off-by: Chao Peng chao.p.p...@linux.intel.com
This looks good. I have one question and one small comment/idea:
[...]
diff --git a/tools/libxc/include/xenctrl.h
b/tools/libxc/include/xenctrl.h
index 09d819f..54043ee 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2688,6 +2688,8 @@ int xc_resource_op(xc_interface *xch, uint32_t
nr_ops, xc_resource_op_t *ops);
#if defined(__i386__) || defined(__x86_64__)
enum xc_psr_cmt_type {
XC_PSR_CMT_L3_OCCUPANCY,
+XC_PSR_CMT_TOTAL_MEM_BANDWIDTH,
+XC_PSR_CMT_LOCAL_MEM_BANDWIDTH,
Is bandwidth still the correct term here (and more importantly in the
libxl interface e.g. enum), given that we now do the sampling at the
application level and just expose the current count from Xen via libxl?
I feel comfortable either changing it or not. The reason to change it is
what you said here that we do return the counter value to the caller, so
a consistent name would be nice. While the reason to keep it is: the
names are listed as the monitoring event type from spec, so the caller
perhaps knows that the returned data is the sample value from event
counter register related to that type.
Anyway, if you feel it's better to change, then I will do.
What names does Intel's documentation use for these registers?
The register is IA32_QM_CTR(Monitoring Counter Register), to read the
count in this register,
I'm thinking then that COUNT is the right name, .e.g.
XC_PSR_CMT_TOTAL_MEM_COUNT (and for libxl names too). Does that sound
alright?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
On Wed, 2015-03-04 at 09:42 +, Jan Beulich wrote: On 04.03.15 at 10:35, ian.campb...@citrix.com wrote: On Wed, 2015-03-04 at 08:58 +, Jan Beulich wrote: On 03.03.15 at 11:32, jgr...@suse.com wrote: On 03/03/2015 11:27 AM, Jan Beulich wrote: On 03.03.15 at 10:29, jgr...@suse.com.non-mime.internet wrote: In order to indicate the Xen tools capability to support the virtual mapped linear p2m list instead the 3 level mfn tree add a flag to the start_info page. Signed-off-by: Juergen Gross jgr...@suse.com --- xen/include/public/xen.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 3703c39..36c6d62 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -777,6 +777,8 @@ typedef struct start_info start_info_t; #define SIF_INITDOMAIN(11) /* Is this the initial control domain? */ #define SIF_MULTIBOOT_MOD (12) /* Is mod_start a multiboot module? */ #define SIF_MOD_START_PFN (13) /* Is mod_start a PFN? */ +#define SIF_VIRT_P2M (14) /* Does Xen understand a virt. mapped P-M */ + /* making the 3 level tree obsolete? */ #define SIF_PM_MASK (0xFF8) /* reserve 1 byte for xen-pm options */ /* Is there any reason why this can't be part of the tools patch (series) actually going to make use of it? The main reason is I want to make use of it in the related kernel series first. And this requires the Xen header implementation. I was about to apply v3, but I'm still unconvinced: How would you test those kernel side changes without having anything to set the flag? It does seem odd to be committing to an ABI with no xen.git side implementation having been posted yet. Normally we ask that things go into xen.git first before any guests start using them. Your reply seems ambiguous to me: If it was sent to Jürgen (with me Cc-ed) I'd read it as supporting my earlier statement. Since, however, it was sent to me (with Jürgen Cc-ed), I could also read it as supporting the public header change alone to go in (even if in slight collision with the word implementation in there). Could you clarify? Sorry, I was in support of you (Jan) here. Sometime an ABI header change might be all which is needed before guests start using things (e.g. an io protocol change), but I think in this case we really need to at least have seen the complete solution (so any relevant Xen/tools changes) before we commit to an ABI. It _might_ be sufficient if this patch included some documentation about what this flag actually means, but best would be to see the actual tools side (or even a design, sorry if I've missed this somewhere along the line). What I don't want to happen is for me to request a change during tools review only to be told kernels in the field already do it this way. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] QEMU e820 Reservation (FW_CFG_E820_TABLE and fw_cfg etc/e820)
On Wed, 4 Mar 2015, Gordan Bobic wrote: Stefano, Many thanks for responding to this. Resplies inline below. On 2015-03-04 10:11, Stefano Stabellini wrote: On Tue, 3 Mar 2015, Gordan Bobic wrote: Hi, I've been looking into custom e820 maps for domUs again, and found that functionality to provide QEMU with hints regarding e820 mapping has been upstream since some time in 2010 (FW_CFG_E820_TABLE) with more finely grained control (usable rather than just reserved entries) upstream since 2013 (fw_cfg etc/e820). The respective patches are here: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00996.html http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00593.html What I have not been able to find is any documentation at all on how this e820 data can be given to QEMU when starting a domain. I can see from the structs in the patches how the data is packed for the relevant code to consume, but I cannot figure out what is the delivery vector for this data. How can I get QEMU to ingest the hints about any additional reserved e820 blocks? For context, I need this to work around IOMMU implementation bugs and mark areas of address space as reserved so that the guest doesn't trample over the host's PCI I/O ranges (which IOMMU should intercept, but being buggy, it doesn't). Many thanks in advance. Hello Gordan, FW_CFG_E820_TABLE is a special interface between SeaBios and QEMU but is not used on Xen. I guess it could be made to work on Xen, but I am pretty sure it doesn't at the moment. So this cannot be used to side-load an additional list of e820 reserved memory blocks at domU startup time? Nope. Enabling the usage of FW_CFG_E820_TABLE on Xen is conceivable and once done you would be able to use it, but today it would not work. I think you would probably want to look at hvmloader instead: tools/firmware/hvmloader/e820.c. Yes, this is what I was looking at last time. I was just hoping that either of the above mentioned patches could be used to adjust the e820 map in a soft way rather hard-coding any changes into hvmloader/e820.c The latter is what I did last time, but it is extremely ugly and non-generic. I see. And given the two interfaces I mentioned above it seems really wrong to be implementing a whole new method for manually loading an explicit e820 map. Is that not what the etc/e820 interface is already supposed to do? I don't follow you here: what is the etc/e820 interface? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen-scsiback: use DRV_PFX in the pr macros and DPRINTK
On 04/03/15 18:32, Tao Chen wrote:
Defined the string of {xen-pvscsi: } as DRV_PFX, then use it in the pr
sentences and DPRINTK.
Also fixed up some comments just as eliminate redundant white spaces and
format the code.
These will make the code easier to read.
I have already said you needed to use:
#define pr_fmt(fmt)
to do this.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
On 03.03.15 at 11:32, jgr...@suse.com wrote: On 03/03/2015 11:27 AM, Jan Beulich wrote: On 03.03.15 at 10:29, jgr...@suse.com.non-mime.internet wrote: In order to indicate the Xen tools capability to support the virtual mapped linear p2m list instead the 3 level mfn tree add a flag to the start_info page. Signed-off-by: Juergen Gross jgr...@suse.com --- xen/include/public/xen.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 3703c39..36c6d62 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -777,6 +777,8 @@ typedef struct start_info start_info_t; #define SIF_INITDOMAIN(11) /* Is this the initial control domain? */ #define SIF_MULTIBOOT_MOD (12) /* Is mod_start a multiboot module? */ #define SIF_MOD_START_PFN (13) /* Is mod_start a PFN? */ +#define SIF_VIRT_P2M (14) /* Does Xen understand a virt. mapped P-M */ + /* making the 3 level tree obsolete? */ #define SIF_PM_MASK (0xFF8) /* reserve 1 byte for xen-pm options */ /* Is there any reason why this can't be part of the tools patch (series) actually going to make use of it? The main reason is I want to make use of it in the related kernel series first. And this requires the Xen header implementation. I was about to apply v3, but I'm still unconvinced: How would you test those kernel side changes without having anything to set the flag? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] xen/arm: Do not allocate pte entries for MAP_SMALL_PAGES
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
On x86, for the pages mapped with PAGE_HYPERVISOR attribute
non-leaf page tables are allocated with valid pte entries.
and with MAP_SMALL_PAGES attribute only non-leaf page tables are
allocated with invalid (valid bit set to 0) pte entries.
However on arm this is not the case. On arm for the pages
mapped with PAGE_HYPERVISOR and MAP_SMALL_PAGES both
non-leaf and leaf level page table are allocated with valid bit
in pte entries.
This behaviour in arm makes common vmap code fail to
allocate memory beyond 128MB as described below.
In vmap_init, map_pages_to_xen() is called for mapping
vm_bitmap. Initially one page of vm_bitmap is allocated
and mapped using PAGE_HYPERVISOR attribute.
For the rest of vm_bitmap pages, MAP_SMALL_PAGES attribute
is used to map.
In ARM for both PAGE_HYPERVISOR and MAP_SMALL_PAGES, valid bit
is set to 1 in pte entry for these mapping.
In vma_alloc(), map_pages_to_xen() is failing for 128MB because
for this next vm_bitmap page the mapping is already set in vm_init()
with valid bit set in pte entry. So map_pages_to_xen() in
ARM returns error.
With this patch, MAP_SMALL_PAGES attribute will only allocate
non-leaf page tables only.
Here we use bit[16] in the attribute flag to know if leaf page
tables should be allocated or not.
This bit is set only for MAP_SMALL_PAGES attribute.
Signed-off-by: Vijaya Kumar Kvijaya.ku...@caviumnetworks.com
---
v2:
- Rename PTE_INVALID to PAGE_PRESENT
- Re-define PAGE_* macros with PAGE_PRESENT
- Rename parameter ai to flags
- Introduce macro to check present flag and extract attribute
index values
---
xen/arch/arm/mm.c |7 +--
xen/include/asm-arm/page.h | 25 +
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7d4ba0c..6a113aa 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -834,7 +834,7 @@ static int create_xen_entries(enum xenmap_operation op,
unsigned long virt,
unsigned long mfn,
unsigned long nr_mfns,
- unsigned int ai)
+ unsigned int flags)
{
int rc;
unsigned long addr = virt, addr_end = addr + nr_mfns * PAGE_SIZE;
@@ -865,7 +865,10 @@ static int create_xen_entries(enum xenmap_operation op,
addr, mfn);
return -EINVAL;
}
-pte = mfn_to_xen_entry(mfn, ai);
+if ( !is_pte_present(flags) )
+break;
+
+pte = mfn_to_xen_entry(mfn, get_pte_flags(flags));
pte.pt.table = 1;
write_pte(third[third_table_offset(addr)], pte);
break;
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 3e7b0ae..f743003 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -61,10 +61,27 @@
#define DEV_WCBUFFERABLE
#define DEV_CACHEDWRITEBACK
-#define PAGE_HYPERVISOR (WRITEALLOC)
-#define PAGE_HYPERVISOR_NOCACHE (DEV_SHARED)
-#define PAGE_HYPERVISOR_WC (DEV_WC)
-#define MAP_SMALL_PAGES PAGE_HYPERVISOR
+#define PAGE_PRESENT (0x1 16)
+#define PAGE_NOT_PRESENT (0x0)
+
+/* bit[16] in the below representation can be used to know if
+ * PTE entry should be added or not. This is useful
+ * when ONLY non-leaf page table entries need to allocated.
+ *
+ * bits[2:0] of be below represent correponds to AttrIndx[2:0]
+ * i.e lpae_t.pt.ai[2:4]
+ *
+ * For readability purpose MAP_SMALL_PAGES is set with PAGE_NOT_PRESENT
+ * though PAGE_NOT_PRESENT is 0.
+ */
+
+#define PAGE_HYPERVISOR (WRITEALLOC | PAGE_PRESENT)
+#define PAGE_HYPERVISOR_NOCACHE (DEV_SHARED | PAGE_PRESENT)
+#define PAGE_HYPERVISOR_WC (DEV_WC | PAGE_PRESENT)
+#define MAP_SMALL_PAGES (WRITEALLOC | PAGE_NOT_PRESENT)
+
+#define is_pte_present(x) ((x) PAGE_PRESENT)
+#define get_pte_flags(x) ((x) 0x7)
/*
* Stage 2 Memory Type.
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] credit: generalize __vcpu_has_soft_affinity()
As pointed out in the discussion of the patch at
http://lists.xenproject.org/archives/html/xen-devel/2015-02/msg03256.html
generalizing the conditions here means code elsewhere doesn't need to
take into consideration internals of how load balancing in the credit
scheduler works.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -292,11 +292,9 @@ __runq_remove(struct csched_vcpu *svc)
static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
const cpumask_t *mask)
{
-if ( cpumask_full(vc-cpu_soft_affinity)
- || !cpumask_intersects(vc-cpu_soft_affinity, mask) )
-return 0;
-
-return 1;
+return !cpumask_subset(cpu_online_map, vc-cpu_soft_affinity)
+ !cpumask_subset(vc-cpu_soft_affinity, vc-cpu_hard_affinity)
+ cpumask_intersects(vc-cpu_soft_affinity, mask);
}
/*
credit: generalize __vcpu_has_soft_affinity()
As pointed out in the discussion of the patch at
http://lists.xenproject.org/archives/html/xen-devel/2015-02/msg03256.html
generalizing the conditions here means code elsewhere doesn't need to
take into consideration internals of how load balancing in the credit
scheduler works.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -292,11 +292,9 @@ __runq_remove(struct csched_vcpu *svc)
static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
const cpumask_t *mask)
{
-if ( cpumask_full(vc-cpu_soft_affinity)
- || !cpumask_intersects(vc-cpu_soft_affinity, mask) )
-return 0;
-
-return 1;
+return !cpumask_subset(cpu_online_map, vc-cpu_soft_affinity)
+ !cpumask_subset(vc-cpu_soft_affinity, vc-cpu_hard_affinity)
+ cpumask_intersects(vc-cpu_soft_affinity, mask);
}
/*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 35810: regressions - FAIL
On Wed, 2015-03-04 at 08:17 +, Jan Beulich wrote: On 04.03.15 at 04:26, ian.jack...@eu.citrix.com wrote: flight 35810 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35810/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumpuserxen-amd64 5 xen-bootfail REGR. vs. 34629 test-amd64-amd64-libvirt 5 xen-boot fail REGR. vs. 34629 test-amd64-amd64-xl-pvh-intel 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-rhel6hvm-intel 5 xen-bootfail REGR. vs. 34629 test-amd64-i386-qemut-rhel6hvm-amd 5 xen-bootfail REGR. vs. 34629 test-amd64-i386-qemut-rhel6hvm-intel 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-qemuu-rhel6hvm-amd 5 xen-bootfail REGR. vs. 34629 test-amd64-i386-freebsd10-i386 5 xen-bootfail REGR. vs. 34629 test-amd64-i386-xl-qemut-winxpsp3 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-qemuu-winxpsp3 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-qemuu-ovmf-amd64 5 xen-boot fail REGR. vs. 34629 test-amd64-amd64-xl-winxpsp3 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 34629 test-amd64-i386-xl-winxpsp3 5 xen-boot fail REGR. vs. 34629 test-amd64-amd64-xl-qemut-winxpsp3 5 xen-bootfail REGR. vs. 34629 The several ones I looked at all have an undue delay after Starting MTA:, which I assume was related to some infrastructure issue (and hence we should disregard). Looks a lot like the old NTP issue, which was supposed to have been fixed, but perhaps our internal NTP isn't especially more reliable than the old pool.debian.org ones we were using before. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] QEMU e820 Reservation (FW_CFG_E820_TABLE and fw_cfg etc/e820)
Stefano, Many thanks for responding to this. Resplies inline below. On 2015-03-04 10:11, Stefano Stabellini wrote: On Tue, 3 Mar 2015, Gordan Bobic wrote: Hi, I've been looking into custom e820 maps for domUs again, and found that functionality to provide QEMU with hints regarding e820 mapping has been upstream since some time in 2010 (FW_CFG_E820_TABLE) with more finely grained control (usable rather than just reserved entries) upstream since 2013 (fw_cfg etc/e820). The respective patches are here: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00996.html http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00593.html What I have not been able to find is any documentation at all on how this e820 data can be given to QEMU when starting a domain. I can see from the structs in the patches how the data is packed for the relevant code to consume, but I cannot figure out what is the delivery vector for this data. How can I get QEMU to ingest the hints about any additional reserved e820 blocks? For context, I need this to work around IOMMU implementation bugs and mark areas of address space as reserved so that the guest doesn't trample over the host's PCI I/O ranges (which IOMMU should intercept, but being buggy, it doesn't). Many thanks in advance. Hello Gordan, FW_CFG_E820_TABLE is a special interface between SeaBios and QEMU but is not used on Xen. I guess it could be made to work on Xen, but I am pretty sure it doesn't at the moment. So this cannot be used to side-load an additional list of e820 reserved memory blocks at domU startup time? I think you would probably want to look at hvmloader instead: tools/firmware/hvmloader/e820.c. Yes, this is what I was looking at last time. I was just hoping that either of the above mentioned patches could be used to adjust the e820 map in a soft way rather hard-coding any changes into hvmloader/e820.c The latter is what I did last time, but it is extremely ugly and non-generic. And given the two interfaces I mentioned above it seems really wrong to be implementing a whole new method for manually loading an explicit e820 map. Is that not what the etc/e820 interface is already supposed to do? Gordan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest install
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Tuesday, February 17, 2015 6:47 PM
To: Hu, Robert
Cc: Wei Liu; Ian Jackson; xen-devel@lists.xen.org; jfeh...@suse.com;
ian.campb...@citrix.com; Pang, LongtaoX
Subject: Re: [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest
install
On Tue, Feb 17, 2015 at 10:37:39AM +, Wei Liu wrote:
On Tue, Feb 17, 2015 at 12:45:34AM +, Hu, Robert wrote:
[...]
Am I supposed to wait for Wei's patch or use my approach for a
while and revert to Wei's patch afterwards?
What patch do you expect from me?
That Ian mentioned above
'unify the d-i partman-auto/expert_recipe in Debian.pm with the one
in ts-debian-hvm-install, and make all Debian HVM installations use
LVM.'
I'm afraid I don't have time to do the refactoring and testing any
time soon.
I had a look at d-i's preseed documentation. And this is what I come
up with. Note it's untested patch, just a proof-of-concept what the
final recipe might look like.
A proper upstream patch will require factoring out the common bits
first (/boot, / and swap) and then append test case specific bits (in
this case, the EFI boot partition) later.
Wei.
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install index
449b96c..e87a2c0 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -54,6 +54,12 @@ d-i partman-auto/method string regular
d-i partman-auto/expert_recipe string \\
boot-root :: \\
+100 50 100 ext4
+ \$primary{ } \$bootable{ }
\\
+ method{ format } format{ }
\\
+ use_filesystem{ } filesystem{ ext3 }
\\
ext4
Copy and paste error, sorry.
+ mountpoint{ /boot }
\\
+ .
\\
512 50 512 vfat \\
\$primary{ } \$bootable{ } \\
And you might
want to get rid of this bootable flag.
The testing of this patch will require you to run at least
test-amd64-amd64-xl-qemuu-{debianhvm,ovmf}-amd64.
Since this is just a proof-of-concept patch, could you provide a workable one
based on latest OSSTest master branch,
and make all Debian HVM installations use LVM?
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86: introduce clear_fixmap()
... making more obvious what its so far open coded users intend.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -310,7 +310,7 @@ void free_vcpu_guest_context(struct vcpu
{
if ( !per_cpu(vgc_pages[i], cpu) )
continue;
-__set_fixmap(idx - i, 0, 0);
+clear_fixmap(idx - i);
free_domheap_page(per_cpu(vgc_pages[i], cpu));
per_cpu(vgc_pages[i], cpu) = NULL;
}
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2552,7 +2552,7 @@ void __init init_ioapic_mappings(void)
if ( bad_ioapic_register(i) )
{
-__set_fixmap(idx, 0, 0);
+clear_fixmap(idx);
continue;
}
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -541,7 +541,7 @@ static inline void __init construct_defa
static __init void efi_unmap_mpf(void)
{
if (efi_enabled)
- __set_fixmap(FIX_EFI_MPF, 0, 0);
+ clear_fixmap(FIX_EFI_MPF);
}
static struct intel_mp_floating *__initdata mpf_found;
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -112,7 +112,7 @@ static void msix_put_fixmap(struct arch_
if ( --msix-table_refcnt[i] == 0 )
{
-__set_fixmap(idx, 0, 0);
+clear_fixmap(idx);
msix_fixmap_free(idx);
msix-table_idx[i] = 0;
}
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -138,7 +138,7 @@ void __init tboot_probe(void)
TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE);
tboot_copy_memory((unsigned char *)sinit_size, sizeof(sinit_size),
TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE);
-__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0);
+clear_fixmap(FIX_TBOOT_MAP_ADDRESS);
}
/* definitions from xen/drivers/passthrough/vtd/iommu.h
@@ -477,7 +477,7 @@ int __init tboot_parse_dmar_table(acpi_t
dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length);
tboot_copy_memory(dmar_table_raw, dmar_table_length, pa);
dmar_table = (struct acpi_table_header *)dmar_table_raw;
-__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0);
+clear_fixmap(FIX_TBOOT_MAP_ADDRESS);
rc = dmar_handler(dmar_table);
xfree(dmar_table_raw);
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -78,6 +78,8 @@ extern void __set_fixmap(
#define set_fixmap_nocache(idx, phys) \
__set_fixmap(idx, (phys)PAGE_SHIFT, PAGE_HYPERVISOR_NOCACHE)
+#define clear_fixmap(idx) __set_fixmap(idx, 0, 0)
+
#define __fix_to_virt(x) (FIXADDR_TOP - ((x) PAGE_SHIFT))
#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)PAGE_MASK)) PAGE_SHIFT)
x86: introduce clear_fixmap()
... making more obvious what its so far open coded users intend.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -310,7 +310,7 @@ void free_vcpu_guest_context(struct vcpu
{
if ( !per_cpu(vgc_pages[i], cpu) )
continue;
-__set_fixmap(idx - i, 0, 0);
+clear_fixmap(idx - i);
free_domheap_page(per_cpu(vgc_pages[i], cpu));
per_cpu(vgc_pages[i], cpu) = NULL;
}
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -2552,7 +2552,7 @@ void __init init_ioapic_mappings(void)
if ( bad_ioapic_register(i) )
{
-__set_fixmap(idx, 0, 0);
+clear_fixmap(idx);
continue;
}
--- a/xen/arch/x86/mpparse.c
+++ b/xen/arch/x86/mpparse.c
@@ -541,7 +541,7 @@ static inline void __init construct_defa
static __init void efi_unmap_mpf(void)
{
if (efi_enabled)
- __set_fixmap(FIX_EFI_MPF, 0, 0);
+ clear_fixmap(FIX_EFI_MPF);
}
static struct intel_mp_floating *__initdata mpf_found;
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -112,7 +112,7 @@ static void msix_put_fixmap(struct arch_
if ( --msix-table_refcnt[i] == 0 )
{
-__set_fixmap(idx, 0, 0);
+clear_fixmap(idx);
msix_fixmap_free(idx);
msix-table_idx[i] = 0;
}
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -138,7 +138,7 @@ void __init tboot_probe(void)
TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE);
tboot_copy_memory((unsigned char *)sinit_size, sizeof(sinit_size),
TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE);
-__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0);
+clear_fixmap(FIX_TBOOT_MAP_ADDRESS);
}
/* definitions from xen/drivers/passthrough/vtd/iommu.h
@@ -477,7 +477,7 @@ int __init tboot_parse_dmar_table(acpi_t
dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length);
tboot_copy_memory(dmar_table_raw, dmar_table_length, pa);
dmar_table = (struct acpi_table_header *)dmar_table_raw;
-__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0);
+clear_fixmap(FIX_TBOOT_MAP_ADDRESS);
rc = dmar_handler(dmar_table);
xfree(dmar_table_raw);
---
Re: [Xen-devel] Crash of guest with nested vmx with Unknown nested vmexit reason 80000021.
Hi Jan, I am sorry, But had the impression you were somehow the owner of these feature. My mistake. I understand the feature is in preview, But are you feeling intense presure when I ask for some status every 2 months? :-)) BR, Jeroen Jan Beulich schreef op 27-2-2015 om 09:08: On 26.02.15 at 19:56, groen...@grosc.com wrote: Anything planned concerning this? Thanks for asking, but to be honest I don't understand why you're (not the first time iirc) pinging me rather than the VMX maintainers who had promised to do that work. All I can say is that I'm being told it's still on their todo list, but no-one has found time yet. And please remember that all of nested virt is still marked preview, i.e. not fully supported - for reasons like the bug here. Jan Jan Beulich schreef op 9-12-2014 om 10:17: On 09.12.14 at 10:09, groen...@grosc.com wrote: Did anyone find the time yet? I'm still more then willing testing any patches. Just yesterday we were told by Intel that they still can't foresee when they will find time. Jan ___ 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] [PATCH v2] xen-scsiback: use DRV_PFX in the pr macros and DPRINTK
Defined the string of {xen-pvscsi: } as DRV_PFX, then use it in the pr
sentences and DPRINTK.
Also fixed up some comments just as eliminate redundant white spaces and format
the code.
These will make the code easier to read.
Signed-off-by: Tao Chen boby.c...@huawei.com
---
drivers/xen/xen-scsiback.c | 70 --
1 file changed, 36 insertions(+), 34 deletions(-)
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 9faca6a..7cc18e9 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -69,8 +69,10 @@
#include xen/interface/grant_table.h
#include xen/interface/io/vscsiif.h
+#define DRV_PFX xen-pvscsi:
#define DPRINTK(_f, _a...) \
- pr_debug((file=%s, line=%d) _f, __FILE__ , __LINE__ , ## _a)
+ pr_debug(DRV_PFX (file=%s, line=%d) _f, \
+ __FILE__ , __LINE__ , ## _a)
#define VSCSI_VERSION v0.1
#define VSCSI_NAMELEN 32
@@ -84,7 +86,7 @@ struct ids_tuple {
struct v2p_entry {
struct ids_tuple v; /* translate from */
- struct scsiback_tpg *tpg; /* translate to */
+ struct scsiback_tpg *tpg; /* translate to */
unsigned int lun;
struct kref kref;
struct list_head l;
@@ -271,7 +273,7 @@ static void scsiback_print_status(char *sense_buffer, int
errors,
{
struct scsiback_tpg *tpg = pending_req-v2p-tpg;
- pr_err(xen-pvscsi[%s:%d] cmnd[0]=%02x - st=%02x msg=%02x host=%02x
drv=%02x\n,
+ pr_err(DRV_PFX [%s:%d] cmnd[0]=%02x - st=%02x msg=%02x host=%02x
drv=%02x\n,
tpg-tport-tport_name, pending_req-v2p-lun,
pending_req-cmnd[0], status_byte(errors), msg_byte(errors),
host_byte(errors), driver_byte(errors));
@@ -427,7 +429,7 @@ static int scsiback_gnttab_data_map_batch(struct
gnttab_map_grant_ref *map,
BUG_ON(err);
for (i = 0; i cnt; i++) {
if (unlikely(map[i].status != GNTST_okay)) {
- pr_err(xen-pvscsi: invalid buffer -- could not remap
it\n);
+ pr_err(DRV_PFX invalid buffer -- could not remap
it\n);
map[i].handle = SCSIBACK_INVALID_HANDLE;
err = -ENOMEM;
} else {
@@ -449,7 +451,7 @@ static int scsiback_gnttab_data_map_list(struct
vscsibk_pend *pending_req,
for (i = 0; i cnt; i++) {
if (get_free_page(pg + mapcount)) {
put_free_pages(pg, mapcount);
- pr_err(xen-pvscsi: no grant page\n);
+ pr_err(DRV_PFX no grant page\n);
return -ENOMEM;
}
gnttab_set_map_op(map[mapcount], vaddr_page(pg[mapcount]),
@@ -492,7 +494,7 @@ static int scsiback_gnttab_data_map(struct vscsiif_request
*ring_req,
return 0;
if (nr_segments VSCSIIF_SG_TABLESIZE) {
- DPRINTK(xen-pvscsi: invalid parameter nr_seg = %d\n,
+ DPRINTK(invalid parameter nr_seg = %d\n,
ring_req-nr_segments);
return -EINVAL;
}
@@ -516,13 +518,13 @@ static int scsiback_gnttab_data_map(struct
vscsiif_request *ring_req,
nr_segments += n_segs;
}
if (nr_segments SG_ALL) {
- DPRINTK(xen-pvscsi: invalid nr_seg = %d\n,
+ DPRINTK(invalid nr_seg = %d\n,
nr_segments);
return -EINVAL;
}
}
- /* free of (sgl) in fast_flush_area()*/
+ /* free of (sgl) in fast_flush_area() */
pending_req-sgl = kmalloc_array(nr_segments,
sizeof(struct scatterlist), GFP_KERNEL);
if (!pending_req-sgl)
@@ -679,7 +681,7 @@ static int prepare_pending_reqs(struct vscsibk_info *info,
v2p = scsiback_do_translation(info, vir);
if (!v2p) {
pending_req-v2p = NULL;
- DPRINTK(xen-pvscsi: doesn't exist.\n);
+ DPRINTK(doesn't exist.\n);
return -ENODEV;
}
pending_req-v2p = v2p;
@@ -690,14 +692,14 @@ static int prepare_pending_reqs(struct vscsibk_info *info,
(pending_req-sc_data_direction != DMA_TO_DEVICE)
(pending_req-sc_data_direction != DMA_FROM_DEVICE)
(pending_req-sc_data_direction != DMA_NONE)) {
- DPRINTK(xen-pvscsi: invalid parameter data_dir = %d\n,
+ DPRINTK(invalid parameter data_dir = %d\n,
pending_req-sc_data_direction);
return -EINVAL;
}
pending_req-cmd_len = ring_req-cmd_len;
if (pending_req-cmd_len VSCSIIF_MAX_COMMAND_SIZE) {
- DPRINTK(xen-pvscsi: invalid parameter cmd_len = %d\n,
+ DPRINTK(invalid parameter cmd_len =
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
On Wed, 2015-03-04 at 11:20 +0100, Juergen Gross wrote: On 03/04/2015 11:06 AM, Ian Campbell wrote: On Wed, 2015-03-04 at 09:42 +, Jan Beulich wrote: On 04.03.15 at 10:35, ian.campb...@citrix.com wrote: On Wed, 2015-03-04 at 08:58 +, Jan Beulich wrote: On 03.03.15 at 11:32, jgr...@suse.com wrote: On 03/03/2015 11:27 AM, Jan Beulich wrote: On 03.03.15 at 10:29, jgr...@suse.com.non-mime.internet wrote: In order to indicate the Xen tools capability to support the virtual mapped linear p2m list instead the 3 level mfn tree add a flag to the start_info page. Signed-off-by: Juergen Gross jgr...@suse.com --- xen/include/public/xen.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index 3703c39..36c6d62 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -777,6 +777,8 @@ typedef struct start_info start_info_t; #define SIF_INITDOMAIN(11) /* Is this the initial control domain? */ #define SIF_MULTIBOOT_MOD (12) /* Is mod_start a multiboot module? */ #define SIF_MOD_START_PFN (13) /* Is mod_start a PFN? */ +#define SIF_VIRT_P2M (14) /* Does Xen understand a virt. mapped P-M */ + /* making the 3 level tree obsolete? */ #define SIF_PM_MASK (0xFF8) /* reserve 1 byte for xen-pm options */ /* Is there any reason why this can't be part of the tools patch (series) actually going to make use of it? The main reason is I want to make use of it in the related kernel series first. And this requires the Xen header implementation. I was about to apply v3, but I'm still unconvinced: How would you test those kernel side changes without having anything to set the flag? It does seem odd to be committing to an ABI with no xen.git side implementation having been posted yet. Normally we ask that things go into xen.git first before any guests start using them. Your reply seems ambiguous to me: If it was sent to Jürgen (with me Cc-ed) I'd read it as supporting my earlier statement. Since, however, it was sent to me (with Jürgen Cc-ed), I could also read it as supporting the public header change alone to go in (even if in slight collision with the word implementation in there). Could you clarify? Sorry, I was in support of you (Jan) here. Sometime an ABI header change might be all which is needed before guests start using things (e.g. an io protocol change), but I think in this case we really need to at least have seen the complete solution (so any relevant Xen/tools changes) before we commit to an ABI. It _might_ be sufficient if this patch included some documentation about what this flag actually means, but best would be to see the actual tools side (or even a design, sorry if I've missed this somewhere along the line). What I don't want to happen is for me to request a change during tools review only to be told kernels in the field already do it this way. I'd like to do an appropriate change in xl, but I've been told this would make sense only for migration protocol V2. OTOH I don't want to wait for an undefined amount of time until this will be posted, so I sent the ABI change first. I could, of course, wait with the flag bit until xl is ready and post another kernel patch then. Unfortunately this would delay Linux support for automatically be able to run as a pv-domain 500GB further, so I strongly recommend accepting the interface change now. Please at least sketch out a design/description of what this flag means to the guest and/or tools and what eventual tools support you expect will be needed, and perhaps some ideas regarding what that support might look like. Without this your proposed ABI change is just a random bit in a data structure with no context. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
On 04/03/15 10:20, Juergen Gross wrote: I could, of course, wait with the flag bit until xl is ready and post another kernel patch then. Unfortunately this would delay Linux support for automatically be able to run as a pv-domain 500GB further, so I strongly recommend accepting the interface change now. I suggested before: If dom0, enable 512G. If domU, enable 512G if requested by command line option /or/ toolstack indicates that it supports the linear p2m. So this flag is only required to /automatically/ enable 512GB PV guests. You still need the manual (command line) override so this flag isn't needed until the toolstack actually supports the linear p2m, and the kernel support for this automatic enablement can be added later as well. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] QEMU e820 Reservation (FW_CFG_E820_TABLE and fw_cfg etc/e820)
On Wed, 2015-03-04 at 10:50 +, Stefano Stabellini wrote: On Wed, 4 Mar 2015, Gordan Bobic wrote: On 2015-03-04 10:33, Stefano Stabellini wrote: On Wed, 4 Mar 2015, Gordan Bobic wrote: Stefano, Many thanks for responding to this. Resplies inline below. On 2015-03-04 10:11, Stefano Stabellini wrote: On Tue, 3 Mar 2015, Gordan Bobic wrote: Hi, I've been looking into custom e820 maps for domUs again, and found that functionality to provide QEMU with hints regarding e820 mapping has been upstream since some time in 2010 (FW_CFG_E820_TABLE) with more finely grained control (usable rather than just reserved entries) upstream since 2013 (fw_cfg etc/e820). The respective patches are here: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00996.html http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00593.html What I have not been able to find is any documentation at all on how this e820 data can be given to QEMU when starting a domain. I can see from the structs in the patches how the data is packed for the relevant code to consume, but I cannot figure out what is the delivery vector for this data. How can I get QEMU to ingest the hints about any additional reserved e820 blocks? For context, I need this to work around IOMMU implementation bugs and mark areas of address space as reserved so that the guest doesn't trample over the host's PCI I/O ranges (which IOMMU should intercept, but being buggy, it doesn't). Many thanks in advance. Hello Gordan, FW_CFG_E820_TABLE is a special interface between SeaBios and QEMU but is not used on Xen. I guess it could be made to work on Xen, but I am pretty sure it doesn't at the moment. So this cannot be used to side-load an additional list of e820 reserved memory blocks at domU startup time? Nope. Enabling the usage of FW_CFG_E820_TABLE on Xen is conceivable and once done you would be able to use it, but today it would not work. I think you would probably want to look at hvmloader instead: tools/firmware/hvmloader/e820.c. Yes, this is what I was looking at last time. I was just hoping that either of the above mentioned patches could be used to adjust the e820 map in a soft way rather hard-coding any changes into hvmloader/e820.c The latter is what I did last time, but it is extremely ugly and non-generic. I see. And given the two interfaces I mentioned above it seems really wrong to be implementing a whole new method for manually loading an explicit e820 map. Is that not what the etc/e820 interface is already supposed to do? I don't follow you here: what is the etc/e820 interface? See the 2nd patch I mentioned above, which supposedly adds etc/e820 fw_cfg file (whatever that means). Ah I see. Yes, this looks pretty much like what you need. We could expose something similar from xl/libxl and make use of this QEMU functionality on Xen. We would also need to coordinate with hvmloader but it should be doable. I think going via qemu for this will turn out to be rather complex, without a wholesale reworking of how (and by whom) the guest address map is laid out. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] sched: credit2: respect per-vcpu hard affinity
On Tue, 2015-03-03 at 09:12 +, Jan Beulich wrote:
On 03.03.15 at 04:15, dario.faggi...@citrix.com wrote:
On Sun, 2015-02-08 at 17:45 -1000, Justin T. Weaver wrote:
+#define csched2_cpumask cpumask[smp_processor_id()]
+
I like the idea, but put the right side between parentheses.
Parentheses? Why? There's no operator with higher precedence
than postfix ones.
There certainly isn't. The why is my personal taste, mostly, which does
not count much, I know, so I grep-ed around the sources and found other
similar examples which have parentheses, and so I went ahead and asked.
However, I can certainly live without them. :-)
+static int get_safe_pcpu(struct csched2_vcpu *svc)
+{
I also don't like the name... __choose_cpu() maybe ?
Why is everyone liking these double underscore prefixed names so
much? They're in conflict with the library name space and hence
should be avoided. Single underscore prefixed names (and the
underscore not followed by an upper case letter) is what the
standard sets aside for file scope (i.e. static) identifiers.
Well, I'm not sure I know why, but --from a purely aesthetic point of
view-- I actually like __foo more than _foo. However, the main reason
why I'm suggesting it here, is to follow suit, since __foo is what is
always used (in sched_credit2.c, but also in most of other files AFAICT)
for similar functions.
I see the point you're making, and I can live with _choose_cpu(), but
the result would look a bit inconsistent, IMO.
Regards,
Dario
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] QEMU e820 Reservation (FW_CFG_E820_TABLE and fw_cfg etc/e820)
On Wed, 2015-03-04 at 10:38 +, Gordan Bobic wrote: I don't follow you here: what is the etc/e820 interface? See the 2nd patch I mentioned above, which supposedly adds etc/e820 fw_cfg file (whatever that means). The problem here is that hvmloader controls and can make modifications to the memory map, and therefore needs to be the entity which provides the e820 to SeaBIOS. etc/e820 comes from qemu which does not have full information. I suppose we could enable etc/e820 for those who really know what they are doing, but it seems like it would be open to abuse (and resulting bug reports to us). Xen already has XENMEM_set_memory_map and XENMEM_memory_map which the tools can use to pass a memory map to the guest (e.g. where hvmloader could retrieve it as a baseline). I think today this is only really used with pv guests using e820_host=1 option. Perhaps that could be extended to HVM guests? Or Perhaps a separate (xenstore based?) mechanism for the toolstack to blacklist memory regions in the guest so hvmloader can take those into account? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
On 03/04/2015 11:59 AM, David Vrabel wrote: On 04/03/15 10:20, Juergen Gross wrote: I could, of course, wait with the flag bit until xl is ready and post another kernel patch then. Unfortunately this would delay Linux support for automatically be able to run as a pv-domain 500GB further, so I strongly recommend accepting the interface change now. I suggested before: If dom0, enable 512G. If domU, enable 512G if requested by command line option /or/ toolstack indicates that it supports the linear p2m. So this flag is only required to /automatically/ enable 512GB PV guests. You still need the manual (command line) override so this flag isn't needed until the toolstack actually supports the linear p2m, and the kernel support for this automatic enablement can be added later as well. Correct. The question is, whether we want some kernel versions capable of running as 1TB guest requiring an additional boot parameter to do so. Avoiding this is easy, but if you don't like it, I can wait with this patch. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
At 10:52 + on 04 Mar (1425462776), Ian Campbell wrote: On Wed, 2015-03-04 at 11:20 +0100, Juergen Gross wrote: I'd like to do an appropriate change in xl, but I've been told this would make sense only for migration protocol V2. OTOH I don't want to wait for an undefined amount of time until this will be posted, so I sent the ABI change first. I could, of course, wait with the flag bit until xl is ready and post another kernel patch then. Unfortunately this would delay Linux support for automatically be able to run as a pv-domain 500GB further, so I strongly recommend accepting the interface change now. Please at least sketch out a design/description of what this flag means to the guest and/or tools and what eventual tools support you expect will be needed, and perhaps some ideas regarding what that support might look like. Without this your proposed ABI change is just a random bit in a data structure with no context. If this is just an ordering constraint between kernel and tools work, maybe we could just define the bit as reserved for now, while the dev work finishes, and give it a proper name when the toolstack bits go in. Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] credit: generalize __vcpu_has_soft_affinity()
On Wed, 2015-03-04 at 09:16 +, Jan Beulich wrote:
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -292,11 +292,9 @@ __runq_remove(struct csched_vcpu *svc)
static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
const cpumask_t *mask)
{
-if ( cpumask_full(vc-cpu_soft_affinity)
- || !cpumask_intersects(vc-cpu_soft_affinity, mask) )
-return 0;
-
-return 1;
+return !cpumask_subset(cpu_online_map, vc-cpu_soft_affinity)
This can use VCPU2ONLINE(vc). Or do you think the impact of one more if
(the ?: in cpupool_online_cpumask) would be too much?
+ !cpumask_subset(vc-cpu_soft_affinity, vc-cpu_hard_affinity)
+ cpumask_intersects(vc-cpu_soft_affinity, mask);
}
Regards,
Dario
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] QEMU e820 Reservation (FW_CFG_E820_TABLE and fw_cfg etc/e820)
On 2015-03-04 10:33, Stefano Stabellini wrote: On Wed, 4 Mar 2015, Gordan Bobic wrote: Stefano, Many thanks for responding to this. Resplies inline below. On 2015-03-04 10:11, Stefano Stabellini wrote: On Tue, 3 Mar 2015, Gordan Bobic wrote: Hi, I've been looking into custom e820 maps for domUs again, and found that functionality to provide QEMU with hints regarding e820 mapping has been upstream since some time in 2010 (FW_CFG_E820_TABLE) with more finely grained control (usable rather than just reserved entries) upstream since 2013 (fw_cfg etc/e820). The respective patches are here: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00996.html http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00593.html What I have not been able to find is any documentation at all on how this e820 data can be given to QEMU when starting a domain. I can see from the structs in the patches how the data is packed for the relevant code to consume, but I cannot figure out what is the delivery vector for this data. How can I get QEMU to ingest the hints about any additional reserved e820 blocks? For context, I need this to work around IOMMU implementation bugs and mark areas of address space as reserved so that the guest doesn't trample over the host's PCI I/O ranges (which IOMMU should intercept, but being buggy, it doesn't). Many thanks in advance. Hello Gordan, FW_CFG_E820_TABLE is a special interface between SeaBios and QEMU but is not used on Xen. I guess it could be made to work on Xen, but I am pretty sure it doesn't at the moment. So this cannot be used to side-load an additional list of e820 reserved memory blocks at domU startup time? Nope. Enabling the usage of FW_CFG_E820_TABLE on Xen is conceivable and once done you would be able to use it, but today it would not work. I think you would probably want to look at hvmloader instead: tools/firmware/hvmloader/e820.c. Yes, this is what I was looking at last time. I was just hoping that either of the above mentioned patches could be used to adjust the e820 map in a soft way rather hard-coding any changes into hvmloader/e820.c The latter is what I did last time, but it is extremely ugly and non-generic. I see. And given the two interfaces I mentioned above it seems really wrong to be implementing a whole new method for manually loading an explicit e820 map. Is that not what the etc/e820 interface is already supposed to do? I don't follow you here: what is the etc/e820 interface? See the 2nd patch I mentioned above, which supposedly adds etc/e820 fw_cfg file (whatever that means). Gordan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
On 04/03/15 11:09, Juergen Gross wrote: On 03/04/2015 11:59 AM, David Vrabel wrote: On 04/03/15 10:20, Juergen Gross wrote: I could, of course, wait with the flag bit until xl is ready and post another kernel patch then. Unfortunately this would delay Linux support for automatically be able to run as a pv-domain 500GB further, so I strongly recommend accepting the interface change now. I suggested before: If dom0, enable 512G. If domU, enable 512G if requested by command line option /or/ toolstack indicates that it supports the linear p2m. So this flag is only required to /automatically/ enable 512GB PV guests. You still need the manual (command line) override so this flag isn't needed until the toolstack actually supports the linear p2m, and the kernel support for this automatic enablement can be added later as well. Correct. The question is, whether we want some kernel versions capable of running as 1TB guest requiring an additional boot parameter to do so. Avoiding this is easy, but if you don't like it, I can wait with this patch. I think running such large PV domUs is a sufficiently rare use case that this is fine. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: Correct license header on libxl_flask.c to be LGPL
On Tue, Mar 3, 2015 at 5:02 PM, Ian Campbell ian.campb...@citrix.com wrote: libxl is intended to be an LGPL 2.1 licensed library, however this file inadvertently got given a GPL header. The following people have touched this file, although all but Machon's contributions are trivial and/or mechanical an Ack from each would be unambiguous: $ git log --format='%an %aE' tools/libxl/libxl_flask.c | sort -u Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Machon Gregory mbgr...@tycho.ncsc.mil Wei Liu l...@liuw.name Acked-by: Wei Liu l...@liuw.name ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv2 2/3] xen-netback: unref frags when handling a from-guest skb with a frag list
Every time a VIF is destroyed up to 256 pages may be leaked if packets
with more than MAX_SKB_FRAGS frags were transmitted from the guest.
Even worse, if another user of ballooned pages allocated one of these
ballooned pages it would not handle the unexpectedly 1 page count
(e.g., gntdev would deadlock when unmapping a grant because the page
count would never reach 1).
When handling a from-guest skb with a frag list, unref the frags
before releasing them so they are freed correctly when the VIF is
destroyed.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/net/xen-netback/netback.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index f7a31d2..f5560cd 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1343,7 +1343,7 @@ static int xenvif_handle_frag_list(struct xenvif_queue
*queue, struct sk_buff *s
{
unsigned int offset = skb_headlen(skb);
skb_frag_t frags[MAX_SKB_FRAGS];
- int i;
+ int i, f;
struct ubuf_info *uarg;
struct sk_buff *nskb = skb_shinfo(skb)-frag_list;
@@ -1383,6 +1383,11 @@ static int xenvif_handle_frag_list(struct xenvif_queue
*queue, struct sk_buff *s
frags[i].page_offset = 0;
skb_frag_size_set(frags[i], len);
}
+
+ /* Release all the original (foreign) frags. */
+ for (f = 0; f skb_shinfo(skb)-nr_frags; f++)
+ skb_frag_unref(skb, f);
+
/* swap out with old one */
memcpy(skb_shinfo(skb)-frags,
frags,
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv2 0/3 net] xen-netback: fix ethtool stats and memory leak
A couple of bug fixes for netback: - make ethool stats to report the correct values. - don't leak 1 MiB every time a VIF is destroyed. Changes in v2: - Split 2nd patch into leak fix and refactor patches David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv2 3/3] xen-netback: refactor xenvif_handle_frag_list()
When handling a from-guest frag list, xenvif_handle_frag_list() replaces the frags before calling the destructor to clean up the original (foreign) frags. Whilst this is safe (the destructor doesn't actually use the frags), it looks odd. Reorder the function to be less confusing. Signed-off-by: David Vrabel david.vra...@citrix.com --- drivers/net/xen-netback/netback.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index f5560cd..56c4a81 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -1384,27 +1384,24 @@ static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct sk_buff *s skb_frag_size_set(frags[i], len); } + /* Copied all the bits from the frag list -- free it. */ + skb_frag_list_init(skb); + xenvif_skb_zerocopy_prepare(queue, nskb); + kfree_skb(nskb); + /* Release all the original (foreign) frags. */ for (f = 0; f skb_shinfo(skb)-nr_frags; f++) skb_frag_unref(skb, f); - - /* swap out with old one */ - memcpy(skb_shinfo(skb)-frags, - frags, - i * sizeof(skb_frag_t)); - skb_shinfo(skb)-nr_frags = i; - skb-truesize += i * PAGE_SIZE; - - /* remove traces of mapped pages and frag_list */ - skb_frag_list_init(skb); uarg = skb_shinfo(skb)-destructor_arg; /* increase inflight counter to offset decrement in callback */ atomic_inc(queue-inflight_packets); uarg-callback(uarg, true); skb_shinfo(skb)-destructor_arg = NULL; - xenvif_skb_zerocopy_prepare(queue, nskb); - kfree_skb(nskb); + /* Fill the skb with the new (local) frags. */ + memcpy(skb_shinfo(skb)-frags, frags, i * sizeof(skb_frag_t)); + skb_shinfo(skb)-nr_frags = i; + skb-truesize += i * PAGE_SIZE; return 0; } -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv2 1/3] xen-netback: return correct ethtool stats
Use correct pointer arithmetic to get the pointer to each stat.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/net/xen-netback/interface.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index f38227a..3aa8648 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -340,12 +340,11 @@ static void xenvif_get_ethtool_stats(struct net_device
*dev,
unsigned int num_queues = vif-num_queues;
int i;
unsigned int queue_index;
- struct xenvif_stats *vif_stats;
for (i = 0; i ARRAY_SIZE(xenvif_stats); i++) {
unsigned long accum = 0;
for (queue_index = 0; queue_index num_queues; ++queue_index) {
- vif_stats = vif-queues[queue_index].stats;
+ void *vif_stats = vif-queues[queue_index].stats;
accum += *(unsigned long *)(vif_stats +
xenvif_stats[i].offset);
}
data[i] = accum;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 12/19] xen/arm: its: Add support to emulate GICR register for LPIs
On Tue, 3 Mar 2015, Stefano Stabellini wrote:
On Mon, 2 Mar 2015, vijay.kil...@gmail.com wrote:
@@ -94,19 +95,29 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu
*v, mmio_info_t *info,
switch ( gicr_reg )
{
case GICR_CTLR:
-/* We have not implemented LPI's, read zero */
-goto read_as_zero;
+/*
+ * Enable LPI's for ITS. Direct injection of LPI
+ * by writing to GICR_{SET,CLR}LPIR are not supported
+ */
Is this actually a limitation that we can have? Is there a way to
communicate to the guest OS that GICR_{SET,CLR}LPIR are not supported?
Actually the GICv3 spec says:
Note: this register is mandatory in an implementation that supports LPIs
and does not include an ITS. The register location is IMPLEMENTATION
DEFINED in an implementation that does include an ITS.
So, if we include the vITS, does this mean that we can simply make this
register disappear?
+if ( dabt.size != DABT_WORD ) goto bad_width;
+vgic_lock(v);
+*r = v-domain-arch.vgic.gicr_ctlr;
+vgic_unlock(v);
+return 1;
case GICR_IIDR:
if ( dabt.size != DABT_WORD ) goto bad_width;
*r = GICV3_GICR_IIDR_VAL;
return 1;
case GICR_TYPER:
-if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
-/* TBD: Update processor id in [23:8] when ITS support is added */
+if ( dabt.size != DABT_WORD dabt.size != DABT_DOUBLE_WORD )
+goto bad_width;
+/* XXX: Update processor id in [23:8] if GITS_TYPER: PTA is not
set */
aff = (MPIDR_AFFINITY_LEVEL(v-arch.vmpidr, 3) 56 |
MPIDR_AFFINITY_LEVEL(v-arch.vmpidr, 2) 48 |
MPIDR_AFFINITY_LEVEL(v-arch.vmpidr, 1) 40 |
MPIDR_AFFINITY_LEVEL(v-arch.vmpidr, 0) 32);
+/* Set LPI support */
+aff |= (GICR_TYPER_DISTRIBUTED_IMP | GICR_TYPER_PLPIS);
*r = aff;
return 1;
case GICR_STATUSR:
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On Wed, 2015-03-04 at 15:41 +0100, Juergen Gross wrote: On 03/04/2015 03:29 PM, Ian Campbell wrote: On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote: On 04/03/15 14:09, Juergen Gross wrote: The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? I have no idea. We (XenServer) have no use cases at all for USB device passthrough. My gut feeling is that for USB 1 and 2 the bus itself isn't fast enough that anyone would care. qdisk has acceptable for disks, so it's probably ok for usb too. While I can accept the bus speed reasoning, I doubt qdisk is copying data between user and kernel space under normal circumstances. I think disk I/Os are done using DMA to/from the user buffer directly. I thought there was at least one copy on the datapath with qdisk, wherever it is. But I don't know for sure. For usb 3 onwards, well, maybe when we care about those we'll decide that a kernel space driver is needed, but for now it seems like userspace would be ok. Do you have another feeling about the probability of a need to do usb 3? If it is already on the horizon I wouldn't want to do the user space backend now and the kernel one next year. :-) Well, what is *your* use case for USB passthru? I don't actually have one myself. I'd speculate that people are more interested in passing in low/medium/high speed devices rather than the superfast usb3 disks etc. But I have no reason to back that up. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [rumpuserxen test] 35854: regressions - FAIL
flight 35854 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35854/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866 build-amd64-rumpuserxen 6 xen-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 fe65ed93201e2e522204a065ca2b2f153b610388 baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net jobs: 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.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 375 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code
On Tue, Mar 03, 2015 at 02:31:51PM -0800, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 05:06:50PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 04:26 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 03:13:07PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 02:42 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 02:17:24PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 12:42 PM, Paul E. McKenney wrote:
}
@@ -511,7 +508,8 @@ static void xen_cpu_die(unsigned int cpu)
schedule_timeout(HZ/10);
}
- cpu_die_common(cpu);
+ (void)cpu_wait_death(cpu, 5);
+ /* FIXME: Are the below calls really safe in case of timeout? */
Not for HVM guests (PV guests will only reach this point after
target cpu has been marked as down by the hypervisor).
We need at least to have a message similar to what native_cpu_die()
prints on cpu_wait_death() failure. And I think we should not call
the two routines below (three, actually --- there is also
xen_teardown_timer() below, which is not part of the diff).
-boris
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
So something like this, then?
if (cpu_wait_death(cpu, 5)) {
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
xen_teardown_timer(cpu);
}
else
pr_err(CPU %u didn't die...\n, cpu);
Easy change for me to make if so!
Or do I need some other check for HVM-vs.-PV guests, and, if so, what
would that check be? And also if so, is it OK to online a PV guest's
CPU that timed out during its previous offline?
I believe PV VCPUs will always be CPU_DEAD by the time we get here
since we are (indirectly) waiting for this in the loop at the
beginning of xen_cpu_die():
'while (xen_pv_domain() HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu,
NULL))' will exit only after 'HYPERVISOR_vcpu_op(VCPUOP_down,
smp_processor_id()' in xen_play_dead(). Which happens after
play_dead_common() has marked the cpu as CPU_DEAD.
So no test is needed.
OK, so I have the following patch on top of my previous patch, which
I will merge if testing goes well. So if a CPU times out going offline,
the above three functions will not be called, the didn't die message
will be printed, and any future attempt to online that CPU will fail.
Is that the correct semantics?
Yes.
I am not sure whether not ever onlining the CPU is the best outcome
but then I don't think trying to online it again with all interrupts
and such still set up will work well. And it's an improvement over
what we have now anyway (with current code we may clean up things
for a non-dead cpu).
Another strategy is to key off of the return value of cpu_check_up_prepare().
If it returns -EBUSY, then the outgoing CPU finished up after the
surviving CPU timed out. The CPU trying to bring the new CPU online
could (in theory, anyway) do the xen_smp_intr_free(), xen_uninit_lock_cpu(),
and xen_teardown_timer() at that point.
And the code for this, in xen_cpu_up(), might look something like the
following:
rc = cpu_check_up_prepare(cpu);
if (rc rc != -EBUSY)
return rc;
if (rc == EBUSY) {
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
xen_teardown_timer(cpu);
}
The idea is that we detect when the CPU eventually took itself offline,
but only did so after the surviving CPU timed out. (Of course, it
would probably be best to put those three statements into a small
function that is called from both places.)
I have no idea whether this approach would really work, especially given
your earlier statement that CPU_DEAD happens early on. But in case it
is helpful or sparks some better idea.
Thanx, Paul
But I must defer to you on this sort of thing.
Thanx, Paul
Thanks.
-boris
Thanx, Paul
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index e2c7389c58c5..f2a06ff0614d 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -508,12 +508,13 @@ static void xen_cpu_die(unsigned int cpu)
schedule_timeout(HZ/10);
}
- (void)cpu_wait_death(cpu, 5);
- /* FIXME: Are the below calls really safe in case of timeout? */
-
- xen_smp_intr_free(cpu);
- xen_uninit_lock_cpu(cpu);
- xen_teardown_timer(cpu);
+ if (cpu_wait_death(cpu, 5)) {
+ xen_smp_intr_free(cpu);
+ xen_uninit_lock_cpu(cpu);
+ xen_teardown_timer(cpu);
+ } else {
+ pr_err(CPU %u didn't die...\n, cpu);
+ }
}
static void xen_play_dead(void) /* used only with HOTPLUG_CPU */
___
Re: [Xen-devel] [PATCH v2] sched: credit2: respect per-vcpu hard affinity
On 04.03.15 at 12:03, dario.faggi...@citrix.com wrote: I see the point you're making, and I can live with _choose_cpu(), but the result would look a bit inconsistent, IMO. I'm tempted to ask for a cleanup patch then. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1 1/2] xen-netback: return correct ethtool stats
Hello.
On 3/3/2015 7:26 PM, David Vrabel wrote:
Use correct pointer arithmetic to get the pointer to each stat.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/net/xen-netback/interface.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index f38227a..3aa8648 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -340,12 +340,11 @@ static void xenvif_get_ethtool_stats(struct net_device
*dev,
unsigned int num_queues = vif-num_queues;
int i;
unsigned int queue_index;
- struct xenvif_stats *vif_stats;
for (i = 0; i ARRAY_SIZE(xenvif_stats); i++) {
unsigned long accum = 0;
for (queue_index = 0; queue_index num_queues; ++queue_index) {
- vif_stats = vif-queues[queue_index].stats;
+ void *vif_stats = vif-queues[queue_index].stats;
Need empty line after declaration; checkpatch.pl should have complained here.
accum += *(unsigned long *)(vif_stats +
xenvif_stats[i].offset);
}
data[i] = accum;
WBR, Sergei
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] credit: generalize __vcpu_has_soft_affinity()
On 04.03.15 at 13:08, dario.faggi...@citrix.com wrote:
On Wed, 2015-03-04 at 09:16 +, Jan Beulich wrote:
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -292,11 +292,9 @@ __runq_remove(struct csched_vcpu *svc)
static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
const cpumask_t *mask)
{
-if ( cpumask_full(vc-cpu_soft_affinity)
- || !cpumask_intersects(vc-cpu_soft_affinity, mask) )
-return 0;
-
-return 1;
+return !cpumask_subset(cpu_online_map, vc-cpu_soft_affinity)
This can use VCPU2ONLINE(vc). Or do you think the impact of one more if
(the ?: in cpupool_online_cpumask) would be too much?
No, I think that would be fine. I simply wasn't aware of the construct.
v2 soon to come.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. I haven't worked with user space backends yet. Do you recommend a special example I should start with? Changes from the original version are: - port to upstream kernel - put all code in just one source file ?? I'm not sure that was an improvement. The resulting single file is too large IMO. OTOH this reduces overall code size: New file has 1845 lines, while old version had in sum 2243 lines with the largest file having 1217 lines. So the largest file is 50% larger, while overall size is 20% smaller. - move module to appropriate location in kernel tree drivers/xen/ is the correct location for this driver. Hmm, so you regard placement of xen-netback under drivers/net and xen-blkback under drivers/block as wrong? I've just followed these examples. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ./configure: line 7058: python-config: command not found after commit 0013245
On Wed, 2015-03-04 at 12:27 +, Julien Grall wrote: Hi Ian, On 04/03/15 09:07, Ian Campbell wrote: On Tue, 2015-03-03 at 19:41 +, Julien Grall wrote: python-dev is not installed. Although I have libpython-dev installed. And this used to work I suppose? As I said in 1425404173.25940.82.ca...@citrix.com: m4/python_devel.m4 seems to suggest it was made optional on purpose, I don't know why or which versions of Python were the first to include the tool though. So it appears to be deliberate that the Python checks do not require python-config. But the new Python vs. Fortify checks _do_ require it. So the question is: why was it optional in the first place? Then we should know if we can make it a requirement or if we need to fix the Fortify check. Aha, adding --follow to my earlier git log m4/python_devel.m4 leads me to: commit 474a0e59d821bfb49b64c3d722a000bd9b5b7599 Author: Roger Pau Monne roger@entel.upc.edu Date: Tue Apr 3 14:28:45 2012 +0100 autoconf: fix python-dev detection on old python versions Replaced the use of python-config (that is only present in Python = 2.5.x) with the distutils python module. Signed-off-by: Roger Pau Monne roger@entel.upc.edu Cc: Zhang, Yang Z yang.z.zh...@intel.com Tested-by: KUWAMURA Shin'ya k...@jp.fujitsu.com Cc: Ian Campbell ian.campb...@citrix.com Committed-by: Ian Jackson ian.jack...@eu.citrix.com So it seems like it is necessary to continue to work without python-config present. In my same earlier mail I said: Perhaps AX_CHECK_PYTHON_FORTIFY_NOOPT should be a nop unless python-config is available? Or perhaps AX_CHECK_PYTHON_DEVEL should export PYTHON_CFLAGS etc which the fortify test should look at instead of invoking python-cofnig? I think it would be acceptable in the first instance to simply only run the Fortify check if python-config is present and hope that older distros didn't have the incompatibility. If we then find such an older distro then we can look at switching to something more complex. On some distributions we may have the headers installed but not python-config (It's the case on my debian Jessie). If python-config is available on that distro then this IMHO is a build environment bug, i.e. if python-config is part of the Python version you are using then you should make it available. python-config is (according to the commit log above) optional so that people using Python = 2.4 can still build Xen. If we have a such distribution with the Fortify bug the user will get a compilation error while building python source code. A such error would not be obvious. So I think the best solution would be to parse the PYTHON_CFLAGS. Patches welcomed either way. Regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ./configure: line 7058: python-config: command not found after commit 0013245
On 04/03/15 12:35, Ian Campbell wrote: On Wed, 2015-03-04 at 12:27 +, Julien Grall wrote: Hi Ian, On 04/03/15 09:07, Ian Campbell wrote: On Tue, 2015-03-03 at 19:41 +, Julien Grall wrote: python-dev is not installed. Although I have libpython-dev installed. And this used to work I suppose? As I said in 1425404173.25940.82.ca...@citrix.com: m4/python_devel.m4 seems to suggest it was made optional on purpose, I don't know why or which versions of Python were the first to include the tool though. So it appears to be deliberate that the Python checks do not require python-config. But the new Python vs. Fortify checks _do_ require it. So the question is: why was it optional in the first place? Then we should know if we can make it a requirement or if we need to fix the Fortify check. Aha, adding --follow to my earlier git log m4/python_devel.m4 leads me to: commit 474a0e59d821bfb49b64c3d722a000bd9b5b7599 Author: Roger Pau Monne roger@entel.upc.edu Date: Tue Apr 3 14:28:45 2012 +0100 autoconf: fix python-dev detection on old python versions Replaced the use of python-config (that is only present in Python = 2.5.x) with the distutils python module. Signed-off-by: Roger Pau Monne roger@entel.upc.edu Cc: Zhang, Yang Z yang.z.zh...@intel.com Tested-by: KUWAMURA Shin'ya k...@jp.fujitsu.com Cc: Ian Campbell ian.campb...@citrix.com Committed-by: Ian Jackson ian.jack...@eu.citrix.com So it seems like it is necessary to continue to work without python-config present. In my same earlier mail I said: Perhaps AX_CHECK_PYTHON_FORTIFY_NOOPT should be a nop unless python-config is available? Or perhaps AX_CHECK_PYTHON_DEVEL should export PYTHON_CFLAGS etc which the fortify test should look at instead of invoking python-cofnig? I think it would be acceptable in the first instance to simply only run the Fortify check if python-config is present and hope that older distros didn't have the incompatibility. If we then find such an older distro then we can look at switching to something more complex. On some distributions we may have the headers installed but not python-config (It's the case on my debian Jessie). If python-config is available on that distro then this IMHO is a build environment bug, i.e. if python-config is part of the Python version you are using then you should make it available. python-config is part of python-dev package. Although I have only install libpython-dev (which contains the headers). python-config is (according to the commit log above) optional so that people using Python = 2.4 can still build Xen. Would it make sense to require python-config for (python = 2.4)? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ./configure: line 7058: python-config: command not found after commit 0013245
On Wed, 2015-03-04 at 12:47 +, Julien Grall wrote: On 04/03/15 12:35, Ian Campbell wrote: On Wed, 2015-03-04 at 12:27 +, Julien Grall wrote: Hi Ian, On 04/03/15 09:07, Ian Campbell wrote: On Tue, 2015-03-03 at 19:41 +, Julien Grall wrote: python-dev is not installed. Although I have libpython-dev installed. And this used to work I suppose? As I said in 1425404173.25940.82.ca...@citrix.com: m4/python_devel.m4 seems to suggest it was made optional on purpose, I don't know why or which versions of Python were the first to include the tool though. So it appears to be deliberate that the Python checks do not require python-config. But the new Python vs. Fortify checks _do_ require it. So the question is: why was it optional in the first place? Then we should know if we can make it a requirement or if we need to fix the Fortify check. Aha, adding --follow to my earlier git log m4/python_devel.m4 leads me to: commit 474a0e59d821bfb49b64c3d722a000bd9b5b7599 Author: Roger Pau Monne roger@entel.upc.edu Date: Tue Apr 3 14:28:45 2012 +0100 autoconf: fix python-dev detection on old python versions Replaced the use of python-config (that is only present in Python = 2.5.x) with the distutils python module. Signed-off-by: Roger Pau Monne roger@entel.upc.edu Cc: Zhang, Yang Z yang.z.zh...@intel.com Tested-by: KUWAMURA Shin'ya k...@jp.fujitsu.com Cc: Ian Campbell ian.campb...@citrix.com Committed-by: Ian Jackson ian.jack...@eu.citrix.com So it seems like it is necessary to continue to work without python-config present. In my same earlier mail I said: Perhaps AX_CHECK_PYTHON_FORTIFY_NOOPT should be a nop unless python-config is available? Or perhaps AX_CHECK_PYTHON_DEVEL should export PYTHON_CFLAGS etc which the fortify test should look at instead of invoking python-cofnig? I think it would be acceptable in the first instance to simply only run the Fortify check if python-config is present and hope that older distros didn't have the incompatibility. If we then find such an older distro then we can look at switching to something more complex. On some distributions we may have the headers installed but not python-config (It's the case on my debian Jessie). If python-config is available on that distro then this IMHO is a build environment bug, i.e. if python-config is part of the Python version you are using then you should make it available. python-config is part of python-dev package. Although I have only install libpython-dev (which contains the headers). python-config is (according to the commit log above) optional so that people using Python = 2.4 can still build Xen. Would it make sense to require python-config for (python = 2.4)? Assuming you mean 2.5 (per Roger's commit message), I think so. Roger? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] sched: credit2: respect per-vcpu hard affinity
On Wed, 2015-03-04 at 12:50 +, Jan Beulich wrote: On 04.03.15 at 12:03, dario.faggi...@citrix.com wrote: I see the point you're making, and I can live with _choose_cpu(), but the result would look a bit inconsistent, IMO. I'm tempted to ask for a cleanup patch then. Yep, and I'd be fine with that. If Justin is up for this, as a pre-patch (not part of the affinity series), fine, if not, I can do it. I've checked and sched_credit.c does both (it mostly does __foo, the only exception being _csched_cpu_pick). sched_rt.c does __foo too, should we take the chance and (in separate patches) cleanup all of these? Regards, Dario 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] ./configure: line 7058: python-config: command not found after commit 0013245
El 04/03/15 a les 14.00, Ian Campbell ha escrit: On Wed, 2015-03-04 at 12:47 +, Julien Grall wrote: On 04/03/15 12:35, Ian Campbell wrote: On Wed, 2015-03-04 at 12:27 +, Julien Grall wrote: Hi Ian, On 04/03/15 09:07, Ian Campbell wrote: On Tue, 2015-03-03 at 19:41 +, Julien Grall wrote: python-dev is not installed. Although I have libpython-dev installed. And this used to work I suppose? As I said in 1425404173.25940.82.ca...@citrix.com: m4/python_devel.m4 seems to suggest it was made optional on purpose, I don't know why or which versions of Python were the first to include the tool though. So it appears to be deliberate that the Python checks do not require python-config. But the new Python vs. Fortify checks _do_ require it. So the question is: why was it optional in the first place? Then we should know if we can make it a requirement or if we need to fix the Fortify check. Aha, adding --follow to my earlier git log m4/python_devel.m4 leads me to: commit 474a0e59d821bfb49b64c3d722a000bd9b5b7599 Author: Roger Pau Monne roger@entel.upc.edu Date: Tue Apr 3 14:28:45 2012 +0100 autoconf: fix python-dev detection on old python versions Replaced the use of python-config (that is only present in Python = 2.5.x) with the distutils python module. Signed-off-by: Roger Pau Monne roger@entel.upc.edu Cc: Zhang, Yang Z yang.z.zh...@intel.com Tested-by: KUWAMURA Shin'ya k...@jp.fujitsu.com Cc: Ian Campbell ian.campb...@citrix.com Committed-by: Ian Jackson ian.jack...@eu.citrix.com So it seems like it is necessary to continue to work without python-config present. In my same earlier mail I said: Perhaps AX_CHECK_PYTHON_FORTIFY_NOOPT should be a nop unless python-config is available? Or perhaps AX_CHECK_PYTHON_DEVEL should export PYTHON_CFLAGS etc which the fortify test should look at instead of invoking python-cofnig? I think it would be acceptable in the first instance to simply only run the Fortify check if python-config is present and hope that older distros didn't have the incompatibility. If we then find such an older distro then we can look at switching to something more complex. On some distributions we may have the headers installed but not python-config (It's the case on my debian Jessie). If python-config is available on that distro then this IMHO is a build environment bug, i.e. if python-config is part of the Python version you are using then you should make it available. python-config is part of python-dev package. Although I have only install libpython-dev (which contains the headers). python-config is (according to the commit log above) optional so that people using Python = 2.4 can still build Xen. Would it make sense to require python-config for (python = 2.4)? Assuming you mean 2.5 (per Roger's commit message), I think so. Roger? Yes, I think so, for python versions 2.4 we should require python-config. IMHO python_fortify_noopt.m4 should also be fixed to deal with older python version that don't have python-config. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 04/03/15 14:09, Juergen Gross wrote: The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? I have no idea. We (XenServer) have no use cases at all for USB device passthrough. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 04/03/15 13:31, Juergen Gross wrote: On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. I haven't worked with user space backends yet. Do you recommend a special example I should start with? Perhaps the block backend in qemu? Changes from the original version are: - port to upstream kernel - put all code in just one source file ?? I'm not sure that was an improvement. The resulting single file is too large IMO. OTOH this reduces overall code size: New file has 1845 lines, while old version had in sum 2243 lines with the largest file having 1217 lines. So the largest file is 50% larger, while overall size is 20% smaller. I think I would have preferred the original large file split up (if there's a sensible functional grouping of the resulting bits). If, after considering a userspace backend, you think that this kernel one is the way to go I'll give it another look and see if I can suggest a suitable split. - move module to appropriate location in kernel tree drivers/xen/ is the correct location for this driver. Hmm, so you regard placement of xen-netback under drivers/net and xen-blkback under drivers/block as wrong? I've just followed these examples. usbback is just a regular USB device driver and most of these don't live under drivers/usb/ but in the subsystem for the type of device they're providing (which in this case is a Xen backend, hence drivers/xen/). David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ./configure: line 7058: python-config: command not found after commit 0013245
On Wed, 2015-03-04 at 15:02 +0100, Roger Pau Monné wrote: Yes, I think so, for python versions 2.4 we should require python-config. ACK. IMHO python_fortify_noopt.m4 should also be fixed to deal with older python version that don't have python-config. That would be ideal, but unless someone shows me/us a system with Python =2.4 which suffers from this issue I'd also be inclined to accept a patch which made that check only apply iff python-config was found (assuming that would be simpler. it might actually be harder...). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 03/04/2015 02:53 PM, David Vrabel wrote: On 04/03/15 13:31, Juergen Gross wrote: On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. I haven't worked with user space backends yet. Do you recommend a special example I should start with? Perhaps the block backend in qemu? Okay, so this would be driven by qemu then? The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? Changes from the original version are: - port to upstream kernel - put all code in just one source file ?? I'm not sure that was an improvement. The resulting single file is too large IMO. OTOH this reduces overall code size: New file has 1845 lines, while old version had in sum 2243 lines with the largest file having 1217 lines. So the largest file is 50% larger, while overall size is 20% smaller. I think I would have preferred the original large file split up (if there's a sensible functional grouping of the resulting bits). If, after considering a userspace backend, you think that this kernel one is the way to go I'll give it another look and see if I can suggest a suitable split. I can split it up, if you really want. - move module to appropriate location in kernel tree drivers/xen/ is the correct location for this driver. Hmm, so you regard placement of xen-netback under drivers/net and xen-blkback under drivers/block as wrong? I've just followed these examples. usbback is just a regular USB device driver and most of these don't live under drivers/usb/ but in the subsystem for the type of device they're providing (which in this case is a Xen backend, hence drivers/xen/). Okay, I'll move it to drivers/xen. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
