Re: [Xen-devel] [PATCH v5 09/22] xen/arm: ITS: Export ITS info to Virtual ITS
On Tue, Jul 28, 2015 at 11:44 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> index aa4d3c5..e16fa03 100644
>> --- a/xen/arch/arm/gic-v3-its.c
>> +++ b/xen/arch/arm/gic-v3-its.c
>> @@ -94,6 +94,7 @@ static LIST_HEAD(its_nodes);
>> static DEFINE_SPINLOCK(its_lock);
>> static struct rdist_prop *gic_rdists;
>> static struct rb_root rb_its_dev;
>> +static struct gic_its_info its_data;
>> static DEFINE_SPINLOCK(rb_its_dev_lock);
>>
>> #define gic_data_rdist()(this_cpu(rdist))
>> @@ -942,6 +943,8 @@ static int its_probe(struct dt_device_node *node)
>> its->phys_size = its_size;
>> typer = readl_relaxed(its_base + GITS_TYPER);
>> its->ite_size = ((typer >> 4) & 0xf) + 1;
>> +its_data.eventid_bits = GITS_TYPER_IDBITS(typer);
>> +its_data.dev_bits = GITS_TYPER_DEVBITS(typer);
>>
>> its->cmd_base = xzalloc_bytes(ITS_CMD_QUEUE_SZ);
>> if ( !its->cmd_base )
>> @@ -1032,7 +1035,10 @@ int its_cpu_init(void)
>>
>> int __init its_init(struct rdist_prop *rdists)
>> {
>> +struct its_node *its;
>> +struct its_node_info *info;
>> struct dt_device_node *np = NULL;
>> +uint32_t i, nr_its = 0;
>>
>> static const struct dt_device_match its_device_ids[] __initconst =
>> {
>> @@ -1042,7 +1048,10 @@ int __init its_init(struct rdist_prop *rdists)
>>
>> for (np = dt_find_matching_node(NULL, its_device_ids); np;
>> np = dt_find_matching_node(np, its_device_ids))
>> -its_probe(np);
>> +{
>> +if ( !its_probe(np) )
>> +nr_its++;
>> +}
>> if ( list_empty(&its_nodes) )
>> {
>> @@ -1050,6 +1059,22 @@ int __init its_init(struct rdist_prop *rdists)
>> return -ENXIO;
>> }
>>
>> +info = xzalloc_array(struct its_node_info, nr_its);
>> +if ( !info )
>> +return -ENOMEM;
>> +
>> +i = 0;
>> +list_for_each_entry(its, &its_nodes, entry)
>> +{
>> + info[i].phys_base = its->phys_base;
>> + info[i].phys_size = its->phys_size;
>> + i++;
>> +}
>> +
>> +its_data.nr_its = nr_its;
>> +its_data.its_hw = info;
>> +vits_setup_hw(&its_data);
>> +
>
> The vITS will only expose 1 ITS to dom0. So there is no need to try to
> allocate memory in order to expose all the ITS.
>
> We can extend vits_setup_hw if we ever want to support more ITS in the
> future.
>
> Furthermore I'd like to see all the ITS data pass one by one rather than
> in a structure. This would help to catch error if we ever extend the
> structure.
>
> Something like:
>
> void vits_hw_setup(paddr_t its0_base, unsigned long its0_size,
>uint32_t eventID_bits, uint32_t devID_bits);
>
Passing every value as argument makes this function take too many arguments.
Validation can be done member variable to catch errors.
>> gic_rdists = rdists;
>> its_lpi_init(rdists->id_bits);
>> its_alloc_lpi_tables();
>> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
>> index dfa3435..3a003d4 100644
>> --- a/xen/arch/arm/vgic-v3-its.c
>> +++ b/xen/arch/arm/vgic-v3-its.c
>> @@ -51,6 +51,15 @@ static void dump_cmd(its_cmd_block *cmd)
>> static void dump_cmd(its_cmd_block *cmd) { do {} while ( 0 ); }
>> #endif
>>
>> +static struct {
>> +struct gic_its_info *info;
>> +} vits_hw;
>
> Please add a boolean valid in the structure. It would help to know if
> the vITS can be used or not later.
>
> Regards,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
Hi, During the hvm guest auto installation, how can I inspect its progress? Currently I encountered some problems during hvm auto-installation; after waited long time, several minutes, I vnc to it, it is black screen. I'm using debian 7.2 for guest installation. And I saw Ian C. 's patch commit c60b6d20b0fd29836a224fdaf9f0d06272144b46 Author: Ian Campbell Date: Mon Jul 6 14:45:12 2015 +0100 ts-debian-hvm-install: Arrange for installed guest to use a serial console So that the guest boot will be logged somewhere useful (the qemu-dm log). It still seems to pickup a "quiet" from somewhere, so it's not as useful as it might be, but it is an improvement. debian 7.2 shall using kernel < 3.15, not sure if this commit causes the problem I'm meeting. Anyway, I need to look into its auto-installation process. Best Regards, Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 10/22] xen/arm: ITS: Add GITS registers emulation
On Wed, Jul 29, 2015 at 12:31 AM, Julien Grall wrote:
> Hi Vijay,
>
> On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K
>>
>> Emulate GITS* registers
>>
>> Signed-off-by: Vijaya Kumar K
>> ---
>> v4: - Removed GICR register emulation
>> ---
>> xen/arch/arm/irq.c|3 +
>> xen/arch/arm/vgic-v3-its.c| 365
>> -
>> xen/include/asm-arm/gic-its.h | 15 ++
>> xen/include/asm-arm/gic.h |1 +
>> 4 files changed, 381 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>> index 1f38605..85cacb0 100644
>> --- a/xen/arch/arm/irq.c
>> +++ b/xen/arch/arm/irq.c
>> @@ -31,6 +31,9 @@
>> static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>> static DEFINE_SPINLOCK(local_irqs_type_lock);
>>
>> +/* Number of LPI supported in XEN */
>> +unsigned int num_of_lpis = 8192;
>> +
>
> It makes little sense to introduce the support of LPIs in Xen in a patch
> called "Add GITS registers emulation".
>
> This should go in a specific ITS (not vITS) patch.
>
> Furthermore, you need to explain where to the 8192 comes from...
Two reasons for setting to 8192
1) Being LPI starts from 8192 the 8192 is 13 and next if id_bits is 14
then it can hold
upto 16K. So 16K-8K = 8K
2) ThunderX requires more than 4K due to large number of PCIe devices
>
> Lastly I would rename num_of_lpis into nr_lpis.
>
>> /* Describe an IRQ assigned to a guest */
>> struct irq_guest
>> {
>> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
>> index 3a003d4..1c7d9b6 100644
>> --- a/xen/arch/arm/vgic-v3-its.c
>> +++ b/xen/arch/arm/vgic-v3-its.c
>> @@ -33,8 +33,16 @@
>> #include
>> #include
>>
>> -#define DEBUG_ITS
>> -
>> +//#define DEBUG_ITS
>> +
>
> This change should go in patch #8.
>
>> +/* GITS_PIDRn register values for ARM implementations */
>> +#define GITS_PIDR0_VAL (0x94)
>> +#define GITS_PIDR1_VAL (0xb4)
>> +#define GITS_PIDR2_VAL (0x3b)
>> +#define GITS_PIDR3_VAL (0x00)
>> +#define GITS_PIDR4_VAL (0x04)
>> +#define GITS_BASER_INIT_VAL ((1UL << GITS_BASER_TYPE_SHIFT) | \
>> + (0x7UL << GITS_BASER_ENTRY_SIZE_SHIFT))
>> #ifdef DEBUG_ITS
>> # define DPRINTK(fmt, args...) dprintk(XENLOG_DEBUG, fmt, ##args)
>> #else
>> @@ -60,6 +68,14 @@ void vits_setup_hw(struct gic_its_info *its_info)
>> vits_hw.info = its_info;
>> }
>>
>> +static inline uint32_t vits_get_max_collections(struct domain *d)
>> +{
>> +/* Collection ID is only 16 bit */
>
> 16 bit = 65536 not 256.
I will correct the comment
>
> You need to explain that the ITS is only supporting 256 collections in
> hardware and that our implementation doesn't support memory provisioning
> for collection.
>
> Furthermore if the number of collection is based on 16 bits, the
> function should return uint16_t not uint32_t.
>
>
>> +ASSERT(d->max_vcpus < 256);
>> +
>
> Please add a comment to explain why d->max_vcpus + 1 with may a
> reference to the public spec.
>
>> +return (d->max_vcpus + 1);
>> +}
>> +
>> static int vits_access_guest_table(struct domain *d, paddr_t entry, void
>> *addr,
>> uint32_t size, bool_t set)
>> {
>> @@ -502,7 +518,7 @@ static int vits_read_virt_cmd(struct vcpu *v, struct
>> vgic_its *vits,
>> return 0;
>> }
>>
>> -int vits_process_cmd(struct vcpu *v, struct vgic_its *vits)
>> +static int vits_process_cmd(struct vcpu *v, struct vgic_its *vits)
>
> Please, Move the static where the function has been defined.
>
>> {
>> its_cmd_block virt_cmd;
>>
>> @@ -527,11 +543,338 @@ err:
>> return 0;
>> }
>
> [..]
>
>> +static int vgic_v3_gits_mmio_read(struct vcpu *v, mmio_info_t *info)
>> +{
>> +struct vgic_its *vits = v->domain->arch.vgic.vits;
>> +struct hsr_dabt dabt = info->dabt;
>> +struct cpu_user_regs *regs = guest_cpu_user_regs();
>> +register_t *r = select_user_reg(regs, dabt.reg);
>> +uint64_t val = 0;
>> +uint32_t gits_reg;
>> +
>> +gits_reg = info->gpa - vits->gits_base;
>> +DPRINTK("%pv: vITS: GITS_MMIO_READ offset 0x%"PRIx32"\n", v, gits_reg);
>> +
>> +switch ( gits_reg )
>> +{
>> +case GITS_CTLR:
>> +if ( dabt.size != DABT_WORD ) goto bad_width;
>> +vits_spin_lock(vits);
>> +*r = vits->ctrl | GITS_CTLR_QUIESCENT;
>
> Why did you put GITS_CTLR_QUIESCENT?
The ITS is quiescent, has no translations in progress and has
completed all operations.
So I have set quescent by default.
[...]
>
>> +return 1;
>> +case GITS_BASER1 ... GITS_BASERN:
>> +goto read_as_zero;
>> +case GITS_PIDR0:
>> +if ( dabt.size != DABT_WORD )
>> +goto bad_width;
>> +*r = GITS_PIDR0_VAL;
>> +return 1;
>> +case GITS_PIDR1:
>> +if ( dabt.size != DABT_WORD )
>> +goto bad_width;
>> +*r = GITS_PIDR1_VAL;
>> +
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Thursday 30 July 2015 08:09 PM, Ian Campbell wrote:
On Thu, 2015-07-30 at 18:21 +0530, Manish Jaggi wrote:
On Thursday 30 July 2015 03:24 PM, Ian Campbell wrote:
On Wed, 2015-07-29 at 15:07 +0530, Manish Jaggi wrote:
On Monday 06 July 2015 03:50 PM, Ian Campbell wrote:
On Mon, 2015-07-06 at 15:36 +0530, Manish Jaggi wrote:
On Monday 06 July 2015 02:41 PM, Ian Campbell wrote:
On Sun, 2015-07-05 at 11:25 +0530, Manish Jaggi wrote:
On Monday 29 June 2015 04:01 PM, Julien Grall wrote:
Hi Manish,
On 28/06/15 19:38, Manish Jaggi wrote:
4.1 Holes in guest memory space
Holes are added in the guest memory space for mapping pci
device's BAR
regions.
These are defined in arch-arm.h
/* For 32bit */
GUEST_MMIO_HOLE0_BASE, GUEST_MMIO_HOLE0_SIZE
/* For 64bit */
GUEST_MMIO_HOLE1_BASE , GUEST_MMIO_HOLE1_SIZE
The memory layout for 32bit and 64bit are exactly the same.
Why
do you
need to differ here?
I think Ian has already replied. I will change the name of
macro
4.2 New entries in xenstore for device BARs
toolkit also updates the xenstore information for the
device
(virtualbar:physical bar).
This information is read by xenpciback and returned to
the
pcifront
driver configuration
space accesses.
Can you details what do you plan to put in xenstore and
how?
It is implementation . But I plan to put under domU / device
/
heirarchy
Actually, xenstore is an API of sorts which needs to be
maintained
going
forward (since front and backend can evolve separately, so it
does
need
some level of design and documentation.
What about the expansion ROM?
Do you want to put some restriction on not using expansion
ROM as
a
passthrough device.
"expansion ROM as a passthrough device" doesn't make sense to
me,
passthrough devices may _have_ an expansion ROM.
The expansion ROM is just another BAR. I don't know how
pcifront/back
deal with those today on PV x86, but I see no reason for ARM to
deviate.
4.3 Hypercall for bdf mapping notification to xen
---
#define PHYSDEVOP_map_sbdf 43
typedef struct {
u32 s;
u8 b;
u8 df;
u16 res;
} sbdf_t;
struct physdev_map_sbdf {
int domain_id;
sbdf_tsbdf;
sbdf_tgsbdf;
};
Each domain has a pdev list, which contains the list of
all
pci devices.
The
pdev structure already has a sbdf information. The
arch_pci_dev is
updated to
contain the gsbdf information. (gs- guest segment id)
Whenever there is trap from guest or an interrupt has to
be
injected,
the pdev
list is iterated to find the gsbdf.
Can you give more background for this section? i.e:
- Why do you need this?
- How xen will translate the gbdf to a vDeviceID?
In the context of the hypercall processing.
- Who will call this hypercall?
- Why not setting the gsbdf when the device is
assigned?
Can the maintainer of the pciback suggest an alternate.
That's not me, but I don't think this belongs here, I think it
can
be
done from the toolstack. If you think not then please explain
what
information the toolstack doesn't have in its possession which
prevents
this mapping from being done there.
The toolstack does not have the guest sbdf information. I could
only
find it in xenpciback.
Are you sure? The sbdf relates to the physical device, correct? If
so
then surely the toolstack knows it -- it's written in the config
file
and is the primary parameter to all of the related libxl
passthrough
APIs. The toolstack wouldn't be able to do anything about passing
through a given device without knowing which device it should be
passing
through.
Perhaps this info needs plumbing through to some new bit of the
toolstack, but it is surely available somewhere.
If you meant the virtual SBDF then that is in
libxl_device_pci.vdevfn.
I added prints in libxl__device_pci_add. vdevfn is always 0 so this
may
not be the right variable to use.
Can you please recheck.
Also the vdev-X entry in xenstore appears to be created from pciback
code and not from xl.
Check function xen_pcibk_publish_pci_dev.
So I have to send a hypercall from pciback only.
I don't think the necessarily follows.
You could have the tools read the vdev-X node back on plug.
I have been trying to get the flow of caller of libxl__device_pci_add
during pci device assignemnt from cfg file(cold boot).
It should be called form xl create flow. Is it called from C code or
Python code.
There is no Python code which you need to worry about involved here. You
can completely ignore tools/python.
In the first instance you need only to worry about tools/libxl/libxl* (the
toolstack library). The xl commands are in tools/libxl/xl* and calls
libxl_domain_create_new with a libxl_domain_config struct which contains
the array of pci devices to cold plug.
Hotplug starts at libxl_device_pci_add.
Most of the code for the PCI specific bits are in tools/libxl/l
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
On Fri, Jul 31, 2015 at 07:20:46AM +, Hu, Robert wrote: > Hi, > > During the hvm guest auto installation, how can I inspect its progress? > Currently I encountered some problems during hvm auto-installation; > after waited long time, several minutes, I vnc to it, it is black screen. > > I'm using debian 7.2 for guest installation. And I saw Ian C. 's patch > commit c60b6d20b0fd29836a224fdaf9f0d06272144b46 > Author: Ian Campbell > Date: Mon Jul 6 14:45:12 2015 +0100 > > ts-debian-hvm-install: Arrange for installed guest to use a serial console > > So that the guest boot will be logged somewhere useful (the qemu-dm > log). > > It still seems to pickup a "quiet" from somewhere, so it's not as > useful as it might be, but it is an improvement. > > debian 7.2 shall using kernel < 3.15, not sure if this commit causes the > problem > I'm meeting. > > Anyway, I need to look into its auto-installation process. > /var/log/xen/qemu-blah logs? Wei. > Best Regards, > Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
On Fri, 2015-07-31 at 07:20 +, Hu, Robert wrote: > Hi, > > During the hvm guest auto installation, how can I inspect its progress? It's serial console is logged to the qemu-dm log, something like /var/log/xen/qemu-dm-$guestname.log I think. > Currently I encountered some problems during hvm auto-installation; > after waited long time, several minutes, I vnc to it, it is black screen. Right, I think that's expected because the installer is running on the serial console now. Currently the qemu-dm log is a mess of ANSI escape codes. If you "cat /var/log/..." then your terminal will decode it and show the last thing on the screen (hopefully an error dialog). My series "fixes to ts-debian-hvm-install" posted to xen-devel on Monday incorporates a switch to using DEBIAN_FRONTEND=text which produces a more useful text log from the installer (the same as is used for host kernel today). > > I'm using debian 7.2 for guest installation. And I saw Ian C. 's patch > commit c60b6d20b0fd29836a224fdaf9f0d06272144b46 > Author: Ian Campbell > Date: Mon Jul 6 14:45:12 2015 +0100 > > ts-debian-hvm-install: Arrange for installed guest to use a serial > console > > So that the guest boot will be logged somewhere useful (the qemu-dm > log). > > It still seems to pickup a "quiet" from somewhere, so it's not as > useful as it might be, but it is an improvement. > > debian 7.2 shall using kernel < 3.15, Debian 7 (and all point releases) is using a 3.2 kernel. > not sure if this commit causes the problem I'm meeting. This commit will have changed where the guest console log will go but I don't expect it to have caused whatever the underlying problem you are seeing is. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 60153: regressions - FAIL
flight 60153 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/60153/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail REGR. vs. 59869 test-amd64-i386-xl-qemuu-winxpsp3 14 guest-localmigrate.2 fail REGR. vs. 59963 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59963 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59963 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass test-amd64-amd64-xl-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass version targeted for testing: xen 6040b3aeb32b4bce2d9958ecbcbd020c46c35d61 baseline version: xen 07249f4fb80b222fc05a5a1e26d23fe50655e562 Last test of basis59963 2015-07-26 15:24:42 Z4 days Testing same since60153 2015-07-30 18:40:10 Z0 days1 attempts People who touched revisions under test: Ian Campbell Ian Jackson 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-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64
Re: [Xen-devel] Xen master hangs
On Thu, 2015-07-30 at 16:32 -0500, Doug Goldstein wrote: > > I'm not sure what I can use to identify the system early on. I see the > EFI FW vendor and EFI FW revision. I'm not sure if that would be > enough. In the case of using that it would likely have to be a range > of revisions. Is DMI available this early? That's the sort of thing we quirk on today, I think (maybe an x86 person could confirm). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Friday, July 31, 2015 3:53 PM > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com > Cc: xen-devel@lists.xen.org > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of guest > auto installation > > On Fri, 2015-07-31 at 07:20 +, Hu, Robert wrote: > > Hi, > > > > During the hvm guest auto installation, how can I inspect its progress? > > It's serial console is logged to the qemu-dm log, something like > /var/log/xen/qemu-dm-$guestname.log I think. > > > Currently I encountered some problems during hvm auto-installation; > > after waited long time, several minutes, I vnc to it, it is black screen. > > Right, I think that's expected because the installer is running on the > serial console now. > > Currently the qemu-dm log is a mess of ANSI escape codes. If you "cat > /var/log/..." then your terminal will decode it and show the last thing on > the screen (hopefully an error dialog). Aha, fortunately, just found 'tail -f ...' output formatted ANSI chart; I can see its progress now. > > My series "fixes to ts-debian-hvm-install" posted to xen-devel on Monday > incorporates a switch to using DEBIAN_FRONTEND=text which produces a > more > useful text log from the installer (the same as is used for host kernel > today). > > > > > I'm using debian 7.2 for guest installation. And I saw Ian C. 's patch > > commit c60b6d20b0fd29836a224fdaf9f0d06272144b46 > > Author: Ian Campbell > > Date: Mon Jul 6 14:45:12 2015 +0100 > > > > ts-debian-hvm-install: Arrange for installed guest to use a serial > > console > > > > So that the guest boot will be logged somewhere useful (the > qemu-dm > > log). > > > > It still seems to pickup a "quiet" from somewhere, so it's not as > > useful as it might be, but it is an improvement. > > > > debian 7.2 shall using kernel < 3.15, > > Debian 7 (and all point releases) is using a 3.2 kernel. > > > not sure if this commit causes the problem I'm meeting. > > This commit will have changed where the guest console log will go but I > don't expect it to have caused whatever the underlying problem you are > seeing is. > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
> -Original Message- > From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: Friday, July 31, 2015 3:51 PM > To: Hu, Robert > Cc: Ian Campbell; ian.jack...@eu.citrix.com; wei.l...@citrix.com; > xen-devel@lists.xen.org > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of guest > auto installation > > On Fri, Jul 31, 2015 at 07:20:46AM +, Hu, Robert wrote: > > Hi, > > > > During the hvm guest auto installation, how can I inspect its progress? > > Currently I encountered some problems during hvm auto-installation; > > after waited long time, several minutes, I vnc to it, it is black screen. > > > > I'm using debian 7.2 for guest installation. And I saw Ian C. 's patch > > commit c60b6d20b0fd29836a224fdaf9f0d06272144b46 > > Author: Ian Campbell > > Date: Mon Jul 6 14:45:12 2015 +0100 > > > > ts-debian-hvm-install: Arrange for installed guest to use a serial > console > > > > So that the guest boot will be logged somewhere useful (the > qemu-dm > > log). > > > > It still seems to pickup a "quiet" from somewhere, so it's not as > > useful as it might be, but it is an improvement. > > > > debian 7.2 shall using kernel < 3.15, not sure if this commit causes the > problem > > I'm meeting. > > > > Anyway, I need to look into its auto-installation process. > > > > /var/log/xen/qemu-blah logs? Seems it works for me. Thanks Wei. > > Wei. > > > Best Regards, > > Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote: > > > Secondly, the vdev-X entry is created async by dom0 watching on > > > event. > > > So how the tools could read back and call assign device again. > > Perhaps by using a xenstore watch on that node to wait for the > > assignment > > from pciback to occur. > As per the flow in the do_pci_add function, assign_device is called > first and based on the success xenstore entry is created. > Are you suggesting to change the sequence. Perhaps that is what it would take, yes, or maybe some other refactoring (e.g. splitting assign_device into two stages) might be the answer. My current preference is for the suggestion below which is to let the toolstack pick the vdevfn and have pciback honour it. > We can discuss this more on #xenarm irc Sorry I missed your ping yesterday, I had already gone home. > > > > Or you could change things such that vdevfn is always chosen by the > > > > toolstack for ARM, not optionally like it is on x86. > > For this one, the struct libxl_device_pci has a field "vdevfn", which > > is > > supposed to allow the user to specify a specific vdevfn. I'm not sure > > how > > that happens or fits together but libxl could undertake to set that on > > ARM > > in the case where the user hasn't done so, effectively taking control > > of > > the PCI bus assignment. > > > > Ian. > > > > ___ > > 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 OSSTEST v2] standalone: Extend -h to support ident=host style specifications
Allowing for multi-host tests.
Also make reset-host reset all hosts.
Signed-off-by: Ian Campbell
---
v2: Fix regex for reset-host
Correct handling/ordering of multiple uses of -h
---
standalone | 47 ---
1 file changed, 36 insertions(+), 11 deletions(-)
diff --git a/standalone b/standalone
index e9a74c1..873616a 100755
--- a/standalone
+++ b/standalone
@@ -31,15 +31,17 @@ Operations:
* reset-host [cf] [JOB]
- Allow a job which has been run before to run on a different host
- next time. Otherwise osstest will complain if you change the host
- which a job is running on on successive runs.
+ Allow a job which has been run before to run on a different host or
+ hosts next time. Otherwise osstest will complain if you change the
+ host(s) which a job is running on on successive runs.
Options:
-c FILE, --config=FILEUse FILE as configuration file
-f FLIGHT, --flight=FLIGHTOperate on FLIGHT
--h HOST, --host=HOST Test host
+-h HOST, --host=HOST Test host, HOST can also be ident=HOST can
+ be given multiple times, not that the
+ order matters in some cases (e.g run-test)
-r, --reuse Do not wipe test host (default)
-R, --noreuse, --reinstallWipe the test host (if job or test does so)
-s, --simulate, --dry-run Dry run, printing what would be run
@@ -76,17 +78,39 @@ else
config=$HOME/.xen-osstest/config
fi
flight="standalone"
-host=
+hosts=
reuse=1 # Don't blow away machines by default
dryrun=0
lvextendmax=50 # Leave some LVM space free for running tests
nobaseline=y
+add_host() {
+local h=$1
+case $h in
+ *=*)
+ local ident=${h/=*}
+ h=${h/*=}
+ hosts="$hosts $ident=$h"
+ ;;
+ *)
+ hosts="$hosts host=$h"
+ ;;
+esac
+}
+
+export_hosts_environ() {
+for h in $hosts ; do
+ local ident=${h/=*}
+ h=${h/*=}
+ eval export OSSTEST_HOST_${ident^^}=$h
+done
+}
+
while true ; do
case "$1" in
-c|--config) config=$2; shift 2;;
-f|--flight) flight=$2; shift 2;;
- -h|--host) host=$2; shift 2;;
+ -h|--host) add_host $2; shift 2;;
-r|--reuse) reuse=1; shift 1;;
-R|--noreuse|--reinstall)reuse=0;shift 1;;
-s|--simulate|--dry-run)dryrun=1;shift 1;;
@@ -111,7 +135,7 @@ if ! ssh-add -l >/dev/null ] ; then
fi
if [ $reuse -eq 0 ]; then
-echo "WARNING: Will blow away machine..."
+echo "WARNING: Will blow away machine(s)..."
echo "Press ENTER to confirm."
read
fi
@@ -142,7 +166,7 @@ need_flight() {
fi
}
need_host() {
-if [ -z "$host" ] ; then
+if [ "x$hosts" = x ] ; then
echo "run-job: Need a host" >&2
exit 1
fi
@@ -240,7 +264,7 @@ case $op in
fi
job=$1; shift
- ./cs-adjust-flight -v $flight runvar-del $job host
+ ./cs-adjust-flight -v $flight runvar-del $job '/(?:\w+_)?host$'
;;
run-job)
@@ -253,9 +277,10 @@ case $op in
job=$1; shift
+ export_hosts_environ
+
OSSTEST_CONFIG=$config \
OSSTEST_FLIGHT=$flight \
- OSSTEST_HOST_HOST=$host \
OSSTEST_HOST_REUSE=$reuse \
OSSTEST_SIMULATE=$dryrun \
with_logging logs/$flight/$job.log ./sg-run-job $job
@@ -275,7 +300,7 @@ case $op in
OSSTEST_FLIGHT=$flight \
OSSTEST_HOST_REUSE=$reuse \
OSSTEST_JOB=$job \
- with_logging logs/$flight/$job.$ts.log ./$ts host=$host $@
+ with_logging logs/$flight/$job.$ts.log ./$ts $hosts $@
;;
*)
echo "Unknown op $op" ; exit 1 ;;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
Further more, now I see debian-hvm guest boots up. But it hangs at 'Starting MTA'. Is MTA necessary? > -Original Message- > From: Hu, Robert > Sent: Friday, July 31, 2015 4:02 PM > To: 'Ian Campbell'; ian.jack...@eu.citrix.com; wei.l...@citrix.com > Cc: xen-devel@lists.xen.org > Subject: RE: OSSTest -- debian-hvm-install, how to see the progress of guest > auto installation > > > -Original Message- > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > Sent: Friday, July 31, 2015 3:53 PM > > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com > > Cc: xen-devel@lists.xen.org > > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of > guest > > auto installation > > > > On Fri, 2015-07-31 at 07:20 +, Hu, Robert wrote: > > > Hi, > > > > > > During the hvm guest auto installation, how can I inspect its progress? > > > > It's serial console is logged to the qemu-dm log, something like > > /var/log/xen/qemu-dm-$guestname.log I think. > > > > > Currently I encountered some problems during hvm auto-installation; > > > after waited long time, several minutes, I vnc to it, it is black screen. > > > > Right, I think that's expected because the installer is running on the > > serial console now. > > > > Currently the qemu-dm log is a mess of ANSI escape codes. If you "cat > > /var/log/..." then your terminal will decode it and show the last thing on > > the screen (hopefully an error dialog). > Aha, fortunately, just found 'tail -f ...' output formatted ANSI chart; I can > see its progress now. > > > > My series "fixes to ts-debian-hvm-install" posted to xen-devel on Monday > > incorporates a switch to using DEBIAN_FRONTEND=text which produces a > > more > > useful text log from the installer (the same as is used for host kernel > > today). > > > > > > > > I'm using debian 7.2 for guest installation. And I saw Ian C. 's patch > > > commit c60b6d20b0fd29836a224fdaf9f0d06272144b46 > > > Author: Ian Campbell > > > Date: Mon Jul 6 14:45:12 2015 +0100 > > > > > > ts-debian-hvm-install: Arrange for installed guest to use a serial > > > console > > > > > > So that the guest boot will be logged somewhere useful (the > > qemu-dm > > > log). > > > > > > It still seems to pickup a "quiet" from somewhere, so it's not as > > > useful as it might be, but it is an improvement. > > > > > > debian 7.2 shall using kernel < 3.15, > > > > Debian 7 (and all point releases) is using a 3.2 kernel. > > > > > not sure if this commit causes the problem I'm meeting. > > > > This commit will have changed where the guest console log will go but I > > don't expect it to have caused whatever the underlying problem you are > > seeing is. > > > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] VT-d: add iommu=igfx option to workaround graphics issues
Tian, Kevin 於 西元2015年07月31日 09:26 寫道: From: Ting-Wei Lan [mailto:lant...@gmail.com] Sent: Sunday, July 26, 2015 12:58 AM When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake devices, It is possible to encounter graphics issues that make screen unreadable or crash the system. It was reported in freedesktop bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90037 As we still cannot find a proper fix for this problem, this patch adds iommu=igfx option to control whether Intel graphics IOMMU is enabled on these devices. Running Xen with iommu=no-igfx is similar to running Linux with intel_iommu=igfx_off, which disables IOMMU for Intel Ironlake GPU. This can be used by users to manually workaround the problem before a fix is available for i915 driver. Signed-off-by: Ting-Wei Lan --- Changed since v1: * Replace igfx_off with igfx This patch is currently only build-tested because I don't have access to the hardware that have graphics issues this week. I will test this new patch next week. docs/misc/xen-command-line.markdown | 12 +++- xen/drivers/passthrough/iommu.c | 3 +++ xen/drivers/passthrough/vtd/quirks.c | 2 +- xen/include/xen/iommu.h | 2 +- 4 files changed, 16 insertions(+), 3 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index 13f03ad..6262be6 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -793,7 +793,7 @@ debug hypervisor only). > Default: `new` unless directed-EOI is supported ### iommu -> `= List of [ | force | required | intremap | qinval | snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | workaround_bios_bug | verbose | debug ]` +> `= List of [ | force | required | intremap | qinval | snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | workaround_bios_bug | igfx | verbose | debug ]` > Sub-options: @@ -867,6 +867,16 @@ debug hypervisor only). >> ignored (normally IOMMU setup fails if any of the devices listed by a DRHD >> entry aren't PCI discoverable). +> `igfx` (VT-d) + +> Default: `true` + +>> Enable IOMMU for Intel Calpella/Ironlake devices. This option does not +>> affect grahpics IOMMU on other devices. The intended usage of this option +>> is `no-igfx`, which is silimar to Linux `intel_iommu=igfx_off` option used +>> to workaround graphics issues. If adding `no-igfx` fixes anything, you +>> should file a bug reporting the problem. + For above description let's make it general, i.e Enable IOMMU for Intel Processor Graphics devices. You can list Calpella/Ironlake as the example, but not the only target. :-) no-igfx only works with Calpella/Ironlake because is_igd_vt_enabled_quirk() contains this code: if ( !IS_ILK(ioh_id) ) return 1; The newly added variable iommu_igfx only changes the return value of is_igd_vt_enabled_quirk() when IS_ILK(ioh_id) is true. I don't know whether we will need no-igfx on other Intel graphics devices because I don't many devices to test and I don't have other devices that have this problem. Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 4.6 release bug lists
> -Original Message- > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > boun...@lists.xen.org] On Behalf Of Wei Liu > Sent: 30 July 2015 16:50 > To: Roger Pau Monne > Cc: ta...@tklengyel.com; Wei Liu; Ian Campbell; > rcojoc...@bitdefender.com; Stefano Stabellini; Andrew Cooper; Dario > Faggioli; Ian Jackson; Tim (Xen.org); Jan Beulich; xen- > de...@lists.xenproject.org; Yang Hongyang > Subject: Re: [Xen-devel] 4.6 release bug lists > > On Thu, Jul 30, 2015 at 05:10:10PM +0200, Roger Pau Monné wrote: > > El 30/07/15 a les 17.04, Wei Liu ha escrit: > > > Hi all > > > > > > Here are some bugs that I'm aware of. The name after a item is the > > > person who is working on it. > > > > > > # Blockers > > > > > > 1. Toolstack record breaks migration v2 (Andrew Cooper) > > > 2. Block hotplug scripts invoked multiple times (Roger Pau Monne) > > > > This "issue" is due to stale udev rules from previous installations. A > > clean install or a update from a packaged Xen from a distro should work > > fine. We could consider installing an empty udev rules file to replace > > the previous one, but IMHO this is kind of crappy. > > > > Then Konrad was also seeing timeout errors from hotplug scripts > > execution, and we are still looking into the cause of this. > > > > > > > > # Non-blockers > > > > > > 1. QEMU block script doesn't work (George Dunlap) > > > > > > If you think I miss other bugs (very likely because I haven't gone > > > through my xen-devel archive), please reply to this email. > > > > I'm quite sure this should be a blocker: > > > > http://marc.info/?l=xen-devel&m=143816508010982 > > > > Yes, that is pretty bad. It should be a blocker. > > I'm going to put your name and Paul's in that item. > I will be looking at this today. I don't have a repro yet though. Paul > Wei. > > > Roger. > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 0/4] x86: modify_ldt improvement, test, and config option
Hey Boris, On Thu, Jul 30, 2015 at 01:18:20PM -0400, Boris Ostrovsky wrote: > >>Only V5, no extra changes. > >Including running the ldt_gdt test? > > Yes, except that 32-on-64 doesn't work, but that's not Xen-specific. so which tests are you running exactly and where can I get them? Andy's repo? Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
On Fri, 2015-07-31 at 08:29 +, Hu, Robert wrote: Please can you not top post. > Further more, now I see debian-hvm guest boots up. But it hangs at > 'Starting MTA'. > Is MTA necessary? Not really, but it's part of the standard Debian installation. If it is hanging then that usually indicates something is wrong with networking, either connectivity or DNS etc. Removing the MTA would simply be working around that underlying issue IOW patches to remove the MTA would likely not be accepted. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Friday, July 31, 2015 4:46 PM > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com > Cc: xen-devel@lists.xen.org > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of guest > auto installation > > On Fri, 2015-07-31 at 08:29 +, Hu, Robert wrote: > > Please can you not top post. > > > Further more, now I see debian-hvm guest boots up. But it hangs at > > 'Starting MTA'. > > Is MTA necessary? > > Not really, but it's part of the standard Debian installation. > > If it is hanging then that usually indicates something is wrong with > networking, either connectivity or DNS etc. Removing the MTA would simply > be working around that underlying issue Do you know how to disable it? seems it is not a service? > > IOW patches to remove the MTA would likely not be accepted. I see. Thanks for remind. > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 60149: regressions - FAIL
On Fri, 2015-07-31 at 07:40 +0100, Ian Campbell wrote: > On Fri, 2015-07-31 at 05:01 +, osstest service owner wrote: > > flight 60149 osstest real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/60149/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > build-i386-libvirt5 libvirt-build fail REGR. > > vs. 60083 > > build-amd64-libvirt 5 libvirt-build fail REGR. > > vs. 60083 > > build-armhf-libvirt 5 libvirt-build fail REGR. > > vs. 60083 > > Pretest contains the libvirt testing from Wei (ccd) > > One of the libvirt self tests failed: > TEST: virshtest > 40 > 52 FAIL > FAIL: virshtest > [...] > === > 1 of 114 tests failed > (1 test was not run) > Please report to libvir-l...@redhat.com > === > > Which isn't a lot to go on, aside frmo fixing this issue do we need to > gather more logs? Shall we drop "ts-libvirt-build: run libvirt test suite" from pretest for the time being? It seems a bit orthogonal to the rest of the series anyway. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 60149: regressions - FAIL
On Fri, Jul 31, 2015 at 09:49:30AM +0100, Ian Campbell wrote: > On Fri, 2015-07-31 at 07:40 +0100, Ian Campbell wrote: > > On Fri, 2015-07-31 at 05:01 +, osstest service owner wrote: > > > flight 60149 osstest real [real] > > > http://logs.test-lab.xenproject.org/osstest/logs/60149/ > > > > > > Regressions :-( > > > > > > Tests which did not succeed and are blocking, > > > including tests which could not be run: > > > build-i386-libvirt5 libvirt-build fail REGR. > > > vs. 60083 > > > build-amd64-libvirt 5 libvirt-build fail REGR. > > > vs. 60083 > > > build-armhf-libvirt 5 libvirt-build fail REGR. > > > vs. 60083 > > > > Pretest contains the libvirt testing from Wei (ccd) > > > > One of the libvirt self tests failed: > > TEST: virshtest > > 40 > > 52 FAIL > > FAIL: virshtest > > [...] > > === > > 1 of 114 tests failed > > (1 test was not run) > > Please report to libvir-l...@redhat.com > > === > > > > Which isn't a lot to go on, aside frmo fixing this issue do we need to > > gather more logs? > > Shall we drop "ts-libvirt-build: run libvirt test suite" from pretest for > the time being? It seems a bit orthogonal to the rest of the series anyway. > Yes, that's fine. Wei. > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
On Fri, 2015-07-31 at 08:47 +, Hu, Robert wrote: > > > > -Original Message- > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > Sent: Friday, July 31, 2015 4:46 PM > > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com > > Cc: xen-devel@lists.xen.org > > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of > > guest > > auto installation > > > > On Fri, 2015-07-31 at 08:29 +, Hu, Robert wrote: > > > > Please can you not top post. > > > > > Further more, now I see debian-hvm guest boots up. But it hangs at > > > 'Starting MTA'. > > > Is MTA necessary? > > > > Not really, but it's part of the standard Debian installation. > > > > If it is hanging then that usually indicates something is wrong with > > networking, either connectivity or DNS etc. Removing the MTA would > > simply > > be working around that underlying issue > Do you know how to disable it? seems it is not a service? I don't know how to turn off the MTA during install, and like I said that is not the approach you should be taking to resolve this issue. Instead you should fix whatever it is that is broken about the network in your test case. > > > > IOW patches to remove the MTA would likely not be accepted. > I see. Thanks for remind. > > > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 12/22] xen/arm: ITS: Add GICR register emulation
On Thu, Jul 30, 2015 at 10:34 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>
> [..]
>
>> +static int gicv3_dist_supports_lpis(void)
>> +{
>> +return readl_relaxed(GICD + GICD_TYPER) & GICD_TYPER_LPIS_SUPPORTED;
>> +}
>> +
>> static int __cpuinit gicv3_cpu_init(void)
>> {
>> int i;
>> @@ -1274,6 +1279,11 @@ static int __init gicv3_init(void)
>>
>> spin_lock(&gicv3.lock);
>>
>> +if ( gicv3_dist_supports_lpis() )
>> +gicv3_info.lpi_supported = 1;
>> +else
>> +gicv3_info.lpi_supported = 0;
>> +
>
> You will avoid 3 lines if you do:
>
> gicv3_info.lpi_supported = !!gicv3_dist_supports_lpis();
>
This will change in patch #17 where we do check for its_probe() to
be succesful
to set gicv3_info.lpi_supported
>> gicv3_dist_init();
>> res = gicv3_cpu_init();
>> gicv3_hyp_init();
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 1757193..af8a34b 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -67,6 +67,11 @@ unsigned int gic_number_lines(void)
>> return gic_hw_ops->info->nr_lines;
>> }
>>
>> +bool_t gic_lpi_supported(void)
>> +{
>> +return gic_hw_ops->info->lpi_supported;
>> +}
>> +
>> void gic_save_state(struct vcpu *v)
>> {
>> ASSERT(!local_irq_is_enabled());
>> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
>> index 1c7d9b6..4afb62b 100644
>> --- a/xen/arch/arm/vgic-v3-its.c
>> +++ b/xen/arch/arm/vgic-v3-its.c
>
> Can you explain why the emulation of the LPI property table has to be
> done in the vITS code?
>
> Overall, there is nothing vITS specific in this code and all the
> functions you've introduced within this file are called only by the
> vgic-v3 code.
yes, it is called from vgic-v3 code because it is emulating GICR_PROP/PEND
registers.
This is emulating LPI property table. Hence all the LPI handling code is kept
in vits file.
GICR_PROP/PEND is defined only for LPI case.
>
>> @@ -28,6 +28,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -76,6 +77,34 @@ static inline uint32_t vits_get_max_collections(struct
>> domain *d)
>> return (d->max_vcpus + 1);
>> }
>>
>> +static void vits_disable_lpi(struct vcpu *v, uint32_t vlpi)
>> +{
>> +struct pending_irq *p;
>> +
>> +p = irq_to_pending(v, vlpi);
>> +clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>> +gic_remove_from_queues(v, vlpi);
>> +}
>> +
>> +static void vits_enable_lpi(struct vcpu *v, uint32_t vlpi, uint8_t priority)
>> +{
>> +struct pending_irq *p;
>> +unsigned long flags;
>> +
>> +p = irq_to_pending(v, vlpi);
>> +
>> +set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>> +
>> +spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> +
>> +/*XXX: raise on right vcpu */
>
> As said on the previous versions, I think there will be locking issue
> given that pending_irq structure is protected by the vCPU where the IRQ
> is locked.
Can you please explain in detail why there is a locking issue.
I remember this locking mechanism is coming from enable_irqs()
as we follow same infrastructure to inject/process LPIs
>
> If you think it's not the case please explain why but don't leave the
> question unanswered.
>
[...]
>>
>> +
>> +int vits_map_lpi_prop(struct domain *d)
>> +{
>> +struct vgic_its *vits = d->arch.vgic.vits;
>> +paddr_t gaddr, addr;
>> +unsigned long mfn;
>> +uint32_t lpi_size, id_bits;
>> +int i;
>> +
>> +gaddr = vits->propbase & MASK_4K;
>
> The physical address is only bits [47:12]. The uppers are either RES0 or
> used for the OuterCache.
Can you please be more explicit. What is the issue here?
>
>> +id_bits = ((vits->propbase & GICR_PROPBASER_IDBITS_MASK) + 1);
>> +
>> +if ( id_bits > d->arch.vgic.id_bits )
>> +id_bits = d->arch.vgic.id_bits;
>
> As said on v4, you are allowing the possibility to have a smaller
> property table than the effective number of LPIs.
>
> An ASSERT in vits_get_priority (patch #16) doesn't ensure the validity
> of the size of the property table provided by the guest. This will
> surely crash Xen in debug mode, and who knows what will happen in
> production mode.
lpi_size is calculated based on id_bits. If it is smaller, the lpi_size will be
smaller where only size of lpi_size is considered.
>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>> index 683e3cc..a466a8f 100644
>> --- a/xen/arch/arm/vgic-v3.c
>> +++ b/xen/arch/arm/vgic-v3.c
>> @@ -29,6 +29,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>>
>> /* GICD_PIDRn register values for ARM implementations */
>> @@ -109,29 +111,47 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu
>> *v, mmio_info_t *info,
>> struct hsr_dabt dabt = info->dabt;
>> struct cpu_user_regs *regs = guest_cpu_user_regs();
>> register_t *r = select
Re: [Xen-devel] [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
On 30/07/15 22:31, Andy Lutomirski wrote: > This is intended for x86/urgent. Sorry for taking so long, but it > seemed nice to avoid breaking Xen. Very much appreciated. Thanks! > > This fixes the "dazed and confused" issue which was exposed by the > CVE-2015-5157 fix. It's also probably a good general attack surface > reduction, and it replaces some scary code with IMO less scary code. > > Also, servers and embedded systems should probably turn off modify_ldt. > This makes that possible. > > Xen people, can you test patch 1? It works for me on my evil 32-bit > Xen virtio setup. So the LDT issue seems to have gone away, which is good. However, I did get this from my single vcpu guest test [OK]LDT entry 0 is invalid [SKIP]Cannot set affinity to CPU 1 [RUN]Test exec [3.638967] CPU 0 set the LDT [OK]LDT entry 0 has AR 0x0040FA00 and limit 0x002A [3.639380] [ cut here ] [3.639389] WARNING: CPU: 0 PID: 383 at /local/linux-mainline.git/arch/x86/include/asm/mmu_context.h:96 flush_old_exec+0x7fd/0xb70() [3.639397] DEBUG_LOCKS_WARN_ON(!irqs_disabled()) [3.639401] CPU: 0 PID: 383 Comm: ldt_gdt_32 Not tainted 4.2.0-rc4+ #21 [3.639407] c6fb9e10 c13b63ab c6fb9e40 c105f299 c149476c [3.639417] c6fb9e6c 017f c148d5ac 0060 c11463dd c11463dd c750aa00 c765e280 [3.639426] c765fb80 c6fb9e58 c105f333 0009 c6fb9e50 c149476c c6fb9e6c c6fb9e9c [3.639436] Call Trace: [3.639442] [] dump_stack+0x48/0x60 [3.639447] [] warn_slowpath_common+0x89/0xc0 [3.639451] [] ? flush_old_exec+0x7fd/0xb70 [3.639456] [] ? flush_old_exec+0x7fd/0xb70 [3.639460] [] warn_slowpath_fmt+0x33/0x40 [3.639464] [] flush_old_exec+0x7fd/0xb70 [3.639470] [] load_elf_binary+0x2b4/0x1060 [3.639475] [] ? lock_release+0x27e/0x4e0 [3.639480] [] ? lock_acquire+0xc1/0x240 [3.639484] [] search_binary_handler+0x4e/0xd0 [3.639489] [] do_execveat_common+0x62c/0x910 [3.639493] [] ? do_execveat_common+0x57d/0x910 [3.639498] [] do_execve+0x24/0x30 [3.639502] [] SyS_execve+0x28/0x40 [3.639507] [] syscall_call+0x7/0x7 [3.639511] ---[ end trace 95a382309b1f72bd ]--- [OK]LDT entry 0 has AR 0x0040FA00 and limit 0x002A [OK]Child succeeded [3.639897] CPU 0 cleared the LDT And this from a two-vcpu test: [RUN]Cross-CPU LDT invalidation [5.260315] CPU 1 set the LDT [5.260324] CPU 0 set the LDT [5.268245] CPU 0 cleared the LDT [5.268261] [ cut here ] [5.268263] CPU 1 cleared the LDT [5.268272] WARNING: CPU: 0 PID: 389 at /local/linux-mainline.git/kernel/locking/lockdep.c:2639 trace_hardirqs_off_caller+0xa9/0xb0() [5.268280] DEBUG_LOCKS_WARN_ON(!irqs_disabled()) [5.268285] CPU: 0 PID: 389 Comm: ldt_gdt_32 Not tainted 4.2.0-rc4+ #21 [5.268291] c6863f38 c13b63ab c6863f68 c105f299 c149476c [5.268301] c6863f94 0185 c1499b9c 0a4f c109f8b9 c109f8b9 c13be3a7 2000 [5.268311] c101b470 c6863f80 c105f333 0009 c6863f78 c149476c c6863f94 c6863f9c [5.268320] Call Trace: [5.268326] [] dump_stack+0x48/0x60 [5.268331] [] warn_slowpath_common+0x89/0xc0 [5.268336] [] ? trace_hardirqs_off_caller+0xa9/0xb0 [5.268340] [] ? trace_hardirqs_off_caller+0xa9/0xb0 [5.268346] [] ? error_code+0x5b/0x64 [5.268352] [] ? do_device_not_available+0x50/0x50 [5.268357] [] warn_slowpath_fmt+0x33/0x40 [5.268361] [] trace_hardirqs_off_caller+0xa9/0xb0 [5.268367] [] trace_hardirqs_off_thunk+0xc/0x10 [5.268371] [] ? error_code+0x5b/0x64 [5.268376] [] ? xen_build_mfn_list_list+0x2a0/0x300 [5.268381] [] ? do_device_not_available+0x50/0x50 [5.268386] ---[ end trace da759e1fe4c971e6 ]--- [5.268434] CPU 1 set the LDT [5.268441] CPU 0 set the LDT [5.268537] CPU 0 cleared the LDT [5.268543] CPU 1 cleared the LDT [5.268629] CPU 1 set the LDT [5.268634] CPU 0 set the LDT [5.268726] CPU 0 cleared the LDT [5.268732] CPU 1 cleared the LDT [5.268818] CPU 1 set the LDT [5.268823] CPU 0 set the LDT [5.268916] CPU 0 cleared the LDT [5.268922] CPU 1 cleared the LDT [5.341360] CPU 1 set the LDT [5.341369] CPU 0 set the LDT [5.341528] CPU 0 cleared the LDT [5.341538] CPU 1 cleared the LDT [OK]All 5 iterations succeeded I am going to try some 64bit tests now. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] build: use correct qemu path in systemd service file and init script
On Thu, Jul 30, 2015 at 10:44:12AM -0500, Doug Goldstein wrote: > On Thu, Jul 30, 2015 at 6:35 AM, Ian Campbell wrote: > > On Thu, 2015-07-30 at 12:23 +0100, Anthony PERARD wrote: > >> On Thu, Jul 30, 2015 at 11:24:47AM +0100, Ian Campbell wrote: > >> > On Thu, 2015-07-30 at 14:51 +0800, Ting-Wei Lan wrote: > >> > > When --with-system-qemu is used, it is possible that we cannot find > >> > > qemu-system-i386 in LIBEXEC_BIN, which can cause error in xencommons > >> > > init script and xen-qemu-dom0-disk-backend.service systemd service. > >> > > > >> > > Signed-off-by: Ting-Wei Lan > >> > > >> > Personally I would have omitted the distinction between @qemu_xen_path@ > >> > and > >> > @qemu_xen_systemd@ and just put the env invocation in the service file > >> > as > >> > "/usr/bin/env @qemu_xen_path@" but I suppose that is just bike > >> > shedding, > >> > so: > >> > > >> > Acked-by: Ian Campbell > >> > > >> > Wei Lui, what do you think about this for 4.6? It fixes a real issue > >> > where > >> > --with-system-qemu is used without an explicit path, which is supposed > >> > to > >> > search for "qemu" in $PATH but fails to do so for the initscripts and > >> > unit > >> > files, where it uses the old hardcoded default value instead, which > >> > probably doesn't exist if you are using this option (and if it did > >> > isn't > >> > the thing the user asked for). > >> > > >> > The fix looks pretty straight forward to me. > >> > > >> > Mostly unrelated, is "qemu" a sensible default here? No binary package > >> > on > >> > Debian actually provides a "qemu" binary, they are all qemu-system-foo > >> > or > >> > variants. I'm not sure if that's just a Debian packaging issue though. > >> > I've > >> > added the Qemu-xen maintainers for input... > >> > >> QEMU does not build a binary called 'qemu', so this would be package > >> specific. So I think a default should be either 'qemu-system-i386' or > >> fail if no path is provided. > > > > Thanks. I think we should take Ting-Wei's patch as is for 4.6 and fixup the > > default to be qemu-system-i386 in 4.7. > > > > Ian. > > > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > Ian, > > I would actually advise against using the name "qemu" because upstream > explicitly asked distros not to use that since 1.0. > > http://wiki.qemu.org/ChangeLog/1.0 > > You should always use "qemu-system-i386". > Thanks for the information. I add this to my 4.7 TODO list. Wei. > -- > Doug Goldstein ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6 v2] xl/libxl: disable PV vNUMA
On Thu, 2015-07-30 at 17:11 +0100, Wei Liu wrote: > Update xl manual and disable PV vNUMA in libxl. > > Signed-off-by: Wei Liu > --- Acked-by: Ian Campbell and applied. > > +/* PV vNUMA is not yet supported because there is an issue with > + * cpuid handling. > + */ Personally I think this is wrong and should be /* * PV vNUMA... but a) there are a bunch of similarly formatted comments in this function and b) tools/libxl/CODING_STYLE doesn't actually cover comment style. So I left it. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/4] x86/xen: Probe target addresses in set_aliased_prot before the hypercall
On 30/07/15 22:31, Andy Lutomirski wrote: > The update_va_mapping hypercall can fail if the VA isn't present in > the guest's page tables. Under certain loads, this can result in an > OOPS when the target address is in unpopulated vmap space. > > While we're at it, add comments to help explain what's going on. > > This isn't a great long-term fix. This code should probably be > changed to use something like set_memory_ro. Reviewed-by: David Vrabel Thanks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 60149: regressions - FAIL
On Fri, 2015-07-31 at 07:40 +0100, Ian Campbell wrote:
>
> > test-amd64-i386-qemut-rhel6hvm-amd 9 redhat-install fail REGR.
> > vs. 60083
>
> 2015-07-30 23:02:32 Z execution took 71 seconds[<=2x600]: timeout 630 ssh
> -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o
> ServerAliveInterval=100 -o PasswordAuthentication=no -o
> ChallengeResponseAuthentication=no -o
> UserKnownHostsFile=tmp/t.known_hosts_60149.test-amd64-i386-qemuu-rhel6hvm
> -amd root@172.16.144.35 mkdir -p /root/60149.test-amd64-i386
> -qemuu-rhel6hvm-amd.redhat-newiso
> genisoimage -R -J -T -b isolinux/isolinux.bin -c
> isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o
> /root/60149.test-amd64-i386-qemuu-rhel6hvm-amd.rhel-server-6.1-i386
> -dvd.iso /root/60149.test-amd64-i386-qemuu-rhel6hvm-amd.redhat-newiso/.
> Use of uninitialized value in pattern match (m//) at
> Osstest/TestSupport.pm line 1736.
By inspection I think this one might be:
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index a6d42bd..ceb4d0f 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1733,7 +1733,7 @@ sub more_prepareguest_hvm (;@) {
}
my $disks = join ",\t\t\n", map { "'$_'" } @disks;
-my $kernel = $ho->{Toolstack}->{Name} =~ m/xend/ ?
+my $kernel = toolstack($ho)->{Name} =~ m/xend/ ?
"kernel = 'hvmloader'" : '';
my $cfg = <{Toolstack} my
hypothesis is that on this path nothing has previously called toolstack(),
something which could well have changed over a rebase at some point. I
could imagine also that ts-{redhat,debian-hvm,windows}-install might differ
in some subtle way here.
> 2015-07-30 23:02:32 Z runvar store:
> redhat_cfgpath=/etc/xen/redhat.guest.osstest.cfg
> 2015-07-30 23:02:32 Z executing scp ... /home/logs/logs/60149/test-amd64
> -i386-qemuu-rhel6hvm-amd/pinot1--redhat.guest.osstest.cfg
> root@172.16.144.35:/etc/xen/redhat.guest.osstest.cfg
> 2015-07-30 23:02:33 Z executing ssh ... root@172.16.144.35 (echo
> xenvnc; echo xenvnc) | vncpasswd redhat.vncpw
> 2015-07-30 23:02:33 Z executing ssh ... root@172.16.144.35 readlink
> /dev/pinot1/redhat.guest.osstest-disk
> 2015-07-30 23:02:33 Z executing ssh ... root@172.16.144.35 lvdisplay -
> -colon /dev/pinot1/redhat.guest.osstest-disk
> Can't call method "create" on unblessed reference at
> Osstest/TestSupport.pm line 1436.
I can't explain this one yet.
Calling a method on an undefined value results in a different message,
"Can't call method "create" on an undefined value", so somehow
toolstack($ho) is an actual reference, but an unblessed one. I haven't
figured out how that can have happened yet.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 60149: regressions - FAIL
On Fri, 2015-07-31 at 10:47 +0100, Ian Campbell wrote:
> 2015-07-30 23:02:32 Z runvar store:
> > redhat_cfgpath=/etc/xen/redhat.guest.osstest.cfg
> > 2015-07-30 23:02:32 Z executing scp ... /home/logs/logs/60149/test
> > -amd64
> > -i386-qemuu-rhel6hvm-amd/pinot1--redhat.guest.osstest.cfg
> > root@172.16.144.35:/etc/xen/redhat.guest.osstest.cfg
> > 2015-07-30 23:02:33 Z executing ssh ... root@172.16.144.35
> > (echo
> > xenvnc; echo xenvnc) | vncpasswd redhat.vncpw
> > 2015-07-30 23:02:33 Z executing ssh ... root@172.16.144.35 readlink
> > /dev/pinot1/redhat.guest.osstest-disk
> > 2015-07-30 23:02:33 Z executing ssh ... root@172.16.144.35 lvdisplay -
> > -colon /dev/pinot1/redhat.guest.osstest-disk
> > Can't call method "create" on unblessed reference at
> > Osstest/TestSupport.pm line 1436.
>
> I can't explain this one yet.
>
> Calling a method on an undefined value results in a different message,
> "Can't call method "create" on an undefined value", so somehow
> toolstack($ho) is an actual reference, but an unblessed one. I haven't
> figured out how that can have happened yet.
$ cat t.pl
#!/usr/bin/perl -w
use strict;
my $foo = {};
my $baz = $foo->{Bar}->{Name} =~ m/123/ ? "A" : "B";
print "$baz\n";
$foo->{Bar}->create();
$ ./t.pl
Use of uninitialized value in pattern match (m//) at /home/ianc/t.pl line 7.
B
Can't call method "create" on unblessed reference at /home/ianc/t.pl line 10.
Whereas with:
my $baz = $foo->{Bar} =~ m/123/ ? "A" : "B";
the error is:
Can't call method "create" on an undefined value at /home/ianc/t.pl line 10.
IOW something about:
$foo->{Bar}->{Name} =~ m/123/ ? "A" : "B";
causes $foo->{Bar} to be initialised.
IOW I think the fix to more_prepareguest_hvm is going to fix this too.
I'll fold that in, drop the patch which does make test and force push to
osstest's pretest, then I'll kill the current flight.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 60149: regressions - FAIL
On Fri, Jul 31, 2015 at 10:47:22AM +0100, Ian Campbell wrote:
> On Fri, 2015-07-31 at 07:40 +0100, Ian Campbell wrote:
> >
> > > test-amd64-i386-qemut-rhel6hvm-amd 9 redhat-install fail REGR.
> > > vs. 60083
> >
> > 2015-07-30 23:02:32 Z execution took 71 seconds[<=2x600]: timeout 630 ssh
> > -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o
> > ServerAliveInterval=100 -o PasswordAuthentication=no -o
> > ChallengeResponseAuthentication=no -o
> > UserKnownHostsFile=tmp/t.known_hosts_60149.test-amd64-i386-qemuu-rhel6hvm
> > -amd root@172.16.144.35 mkdir -p /root/60149.test-amd64-i386
> > -qemuu-rhel6hvm-amd.redhat-newiso
> > genisoimage -R -J -T -b isolinux/isolinux.bin -c
> > isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o
> > /root/60149.test-amd64-i386-qemuu-rhel6hvm-amd.rhel-server-6.1-i386
> > -dvd.iso /root/60149.test-amd64-i386-qemuu-rhel6hvm-amd.redhat-newiso/.
> > Use of uninitialized value in pattern match (m//) at
> > Osstest/TestSupport.pm line 1736.
>
> By inspection I think this one might be:
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index a6d42bd..ceb4d0f 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -1733,7 +1733,7 @@ sub more_prepareguest_hvm (;@) {
> }
> my $disks = join ",\t\t\n", map { "'$_'" } @disks;
>
> -my $kernel = $ho->{Toolstack}->{Name} =~ m/xend/ ?
> +my $kernel = toolstack($ho)->{Name} =~ m/xend/ ?
> "kernel = 'hvmloader'" : '';
>
> my $cfg = <
> Since toolstack() is the function which initialises $ho->{Toolstack} my
> hypothesis is that on this path nothing has previously called toolstack(),
> something which could well have changed over a rebase at some point. I
> could imagine also that ts-{redhat,debian-hvm,windows}-install might differ
> in some subtle way here.
>
Good catch.
The root cause is ts-debian-hvm-install calls host_get_free_memory which
initialises toolstack in the background. It's a trick only used by
debian hvm test case.
And I think your fix is correct.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-2.4 0/3] Migration regressions with Xen.
On Thu, 30 Jul 2015, Stefano Stabellini wrote: > On Thu, 30 Jul 2015, Juan Quintela wrote: > > Anthony PERARD wrote: > > > This is a critical issue for Xen as migration either with the same version > > > of QEMU, or from a previous version of QEMU is broken. > > > > > > Any suggestion on how to move forward? > > > > Will send a pull requset tomorrow. > > > > Thinking about creating a single function that is called for all needed > > places, just to avoid this problem in the future. > > > > Hi Juan, > > thanks for looking into this! > Do you have patches already we can look at and help you test to make > sure they fix the issue? Any updates? > > > > > > > > > On Tue, Jul 28, 2015 at 04:54:42PM +0100, Anthony PERARD wrote: > > >> Hi, > > >> > > >> We've spotted several regression which prevent migration with Xen using > > >> the > > >> same version of QEMU or from a previous version of QEMU (tryied with > > >> 2.2). > > >> > > >> Regression have been introduce by at least: > > >> - df4b1024526cae3479da3492d6371fd4a7324a03 > > >> migration: create new section to store global state > > >> - 61964c23e5ddd5a33f15699e45ce126f879e3e33 > > >> migration: Add configuration section > > >> > > >> The first patch would fix the default case when we use the machine > > >> 'xenfv'. > > >> > > >> But we can also use the machine 'pc' and I don't know how to fix this > > >> case. > > >> The second and third patches are a step in the direction of fixing > > >> migration with the machine 'pc'. > > >> > > >> I have not look at save/restore for PV guest yet. > > >> > > >> Thanks, > > >> > > >> Anthony PERARD (3): > > >> migration: Fix regretion for xenfv machine. > > >> migration: Fix global state with Xen. > > >> migration: Add configuration section to vmstate with xen. > > >> > > >> hw/i386/pc_piix.c | 3 +++ > > >> include/migration/migration.h | 1 + > > >> migration/migration.c | 7 +++ > > >> migration/savevm.c| 6 ++ > > >> 4 files changed, 17 insertions(+) > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6 v2] xl/libxl: disable PV vNUMA
On Fri, 2015-07-31 at 10:29 +0100, Ian Campbell wrote: > On Thu, 2015-07-30 at 17:11 +0100, Wei Liu wrote: > > > > +/* PV vNUMA is not yet supported because there is an issue with > > + * cpuid handling. > > + */ > > Personally I think this is wrong and should be > /* > * PV vNUMA... > Me too... > but a) there are a bunch of similarly formatted comments in this function > Exactly. > and b) tools/libxl/CODING_STYLE doesn't actually cover comment style. > Should we make it do so? FWIW, I'd say we should (and can send a patch to the effect...) Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 07/22] xen/arm: ITS: Add virtual ITS driver
Hi Vijay,
On 31/07/15 07:49, Vijay Kilari wrote:
>>> +static int vits_vitt_entry(struct domain *d, uint32_t devid,
>>> + uint32_t event, struct vitt *entry, bool_t set)
>>> +{
>>> +struct vdevice_table dt_entry;
>>> +paddr_t vitt_entry;
>>> +uint64_t offset;
>>> +
>>> +BUILD_BUG_ON(sizeof(struct vitt) != 8);
>>> +
>>> +if ( vits_get_vdevice_entry(d, devid, &dt_entry) )
>>> +{
>>> +printk(XENLOG_G_ERR
>>> +"d%"PRId32": vITS: Fail to get vdevice for vdev
>>> 0x%"PRIx32"\n",
>>
>> s/vdev/vdevid/
>
> I think, to manage within 80 char, I used just "vdev"
80 character in the source file I guess? If so, you should avoid this
kind of cutting just for coding style benefits. We are not so strict on it.
>
>>
>>> +d->domain_id, devid);
>>> +return -EINVAL;
>>> +}
>>> +
>>> +/* dt_entry is validated in vits_get_vdevice_entry */
>>
>> s/is validated/has been validated/
>>
>> [..]
>>
>>> +int vits_set_vitt_entry(struct domain *d, uint32_t devid,
>>> +uint32_t event, struct vitt *entry)
>>
>> Same remark as vits_set_vdevice_entry.
>
> I have made non-static for compilation purpose. I will try to introduce
> this in the patch where it is used. But it is more logical to have this
> in this patch. Anyway I forget to make it static in later patches
Having introduce static here would have avoid forgetting the static
later... It's just a matter of how you split your series.
For instance, if you would have merge this patch with #8, making this
function non-static wouldn't have been necessary.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 60149: regressions - FAIL
On Fri, 2015-07-31 at 10:54 +0100, Ian Campbell wrote: > > I'll fold that in, drop the patch which does make test and force push to > osstest's pretest, then I'll kill the current flight. Done. The killed flight was 60184. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6 7/8] libxl/save&restore&convert: Switch to new EMULATOR_XENSTORE_DATA records
On 29/07/15 13:00, Ian Jackson wrote: > >> +rc = libxl__restore_emulator_xenstore_data( > ( in wrong place. > > But apart from that it looks fine. I am sorry, but this request is unreasonable IMO. This is a function call, not an integer assignment. Moving the bracket onto the next line is counterintuitive, and I cannot find a single style anywhere which suggests it being a rational thing to do. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-xsm
branch xen-unstable xen branch xen-unstable job test-amd64-i386-xl-xsm test guest-saverestore Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 3a9ace0147d48af49ffd34628f9510f248f2f588 Bug not present: d9c879039393bb14760966bf7076a2d40d45b124 commit 3a9ace0147d48af49ffd34628f9510f248f2f588 Author: Andrew Cooper Date: Fri Jun 12 17:21:41 2015 +0100 tools/libxc+libxl+xl: Restore v2 streams This is a complicated set of changes which must be done together for bisectability. * libxl-save-helper is updated to unconditionally use libxc migration v2. * libxl compatibility workarounds in libxc are disabled for restore operations. * libxl__stream_read_start() is logically spliced into the event location where libxl__xc_domain_restore() used to reside. * Ownership of the save_helper_state moves to stream_read_state. The parameters 'hvm', 'pae', and 'superpages' were previously superfluous, and are completely unused in migration v2. callbacks->toolstack_restore is handled via a migration v2 record now, rather than via a callback from libxc. NB: this change breaks Remus. Further untangling needs to happen before Remus will function. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson CC: Ian Campbell CC: Wei Liu --- v4: * Don't use _init() needlessly v3: * Simplify from v2. * Alter the ownership of save_helper_state v2: * Drop "legacy_width" from the IDL * Gain a LIBXL_HAVE_ to signify support of migration v2 streams For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-xsm.guest-saverestore.html Revision IDs in each graph node refer, respectively, to the Trees above. Searching for failure / basis pass: 60057 fail [host=elbling0] / 59462 [host=italia1] 59426 [host=merlot0] 59348 [host=fiano0] 59254 [host=pinot1] 59186 [host=pinot0] 59130 [host=chardonnay0] 59086 [host=rimava1] 59036 [host=italia0] 59018 [host=fiano1] 58981 ok. Failure / basis pass flights: 60057 / 58981 (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git Latest cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 7c60c2da3160766a265cb84c7411ff2c9cbd8d0b Basis pass 6aaf0da8728c55ff627619f933ed161cc89057c6 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3e2e51ecc1120bd59537ed19b6bc7066511c7e2e c4a962ec0c61aa9b860a3635c8424472e6c2cc2c c40317f11b3f05e7c06a2213560c8471081f2662 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#6aaf0da8728c55ff627619f933ed161cc89057c6-cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#3e2e51ecc1120bd59537ed19b6bc7066511c7e2e-3e2e51ecc1120bd59537ed19b6bc7066511c7e2e git://xenbits.xen.org/staging/qemu-upstream-unstable.git#c4a962ec0c61aa9b860a3635c8424472e6c2cc2c-c4a962ec0c61aa9b860a3635c8424472e6c2cc2c git://xenbits.xen.org/xen.git#c40317f11b3f05e7c06a2213560c8471081f2662-7c60c2da3160766a265cb84c7411ff2c9cbd8d0b + exec + sh -xe + cd /home/osstest/repos/linux-2.6 + git remote set-url origin git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* adhoc-revtuple-generator: tree discontiguous: linux-2.6 + exec + sh -xe + cd /home/osstest/repos/xen + git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /home/osstest/repos/xen + git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* Loaded 1002 nodes in revision graph Searching for test results: 58933 [host=huxelrebe1] 58944 [host=italia1] 59018 [host=fiano1] 58966 [host=huxel
Re: [Xen-devel] [PATCH v5 08/22] xen/arm: ITS: Add virtual ITS commands support
On 31/07/15 07:57, Vijay Kilari wrote: >>> /* >>> * Local variables: >>> * mode: C >>> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h >>> index 66be53a..cdb786c 100644 >>> --- a/xen/include/asm-arm/gic-its.h >>> +++ b/xen/include/asm-arm/gic-its.h >>> @@ -21,6 +21,8 @@ >>> #include >>> #include >>> >>> +#define MASK_4K 0xf000UL >> >> If you name the macro MASK_4K this should go in xen/sizes.h and not in >> the gic-its.h. Although on v4 [1], Ian suggested to rename into >> GITS_CBASER_PA_MASK which IHMO would be better. > > > This is used by other generic code as well in later patches. > One option is to introduce separate macro for each usage or generic name like > GITS_PA_MASK IHMO a mask per register would be better. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] Emulation issues
> -Original Message- > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > boun...@lists.xen.org] On Behalf Of Paul Durrant > Sent: 30 July 2015 14:20 > To: Andrew Cooper; Roger Pau Monne; xen-devel > Subject: Re: [Xen-devel] [BUG] Emulation issues > > > -Original Message- > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > > Sent: 30 July 2015 14:19 > > To: Paul Durrant; Roger Pau Monne; xen-devel > > Subject: Re: [BUG] Emulation issues > > > > On 30/07/15 14:12, Paul Durrant wrote: > > >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > > >> (XEN) domain_crash called from io.c:166 > > >> (XEN) d19v0 weird emulation state 1 > > >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > > >> (XEN) domain_crash called from io.c:166 > > >> (XEN) d19v0 weird emulation state 1 > > >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > > >> (XEN) domain_crash called from io.c:166 > > >> > > > Hmm. Can't understand how that's happening... handle_pio() shouldn't > be > > called unless the state is STATE_IORESP_READY and yet the inner function > is > > hitting the default case in the switch. > > > > Sounds like something is changing the state between the two checks. Is > > this shared memory writeable by qemu? > > > > No, this is the internal state. I really can't see how it's being changed. > I've tried to replicate your test on my rig (which is an old AMD box but quite a big one). Even so I only seem to get about half the VMs to start. The shutdown works fine, and I don't see any problems on the Xen console. I'm using an older build of Xen but still one with my series in. I'll try pulling up to the same commit as you and try again. Paul ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Dom0 crash with apache bench (ab)
On 31/07/15 11:24, Stefano Stabellini wrote: > This is a Linux Dom0 crash on x86 (Dell PowerEdge R320, Xeon E5-2450), > CC'ing relevant people. As you can see from the links below the crash > is: > > [ 253.619326] Call Trace: > [ 253.619330] > [ 253.619332] [] ? skb_copy_ubufs+0xa5/0x230 > [ 253.619347] [] __netif_receive_skb_core+0x6f5/0x940 > [ 253.619353] [] __netif_receive_skb+0x18/0x60 > [ 253.619360] [] netif_receive_skb_internal+0x28/0x90 > [ 253.619366] [] napi_gro_frags+0x125/0x1a0 > [ 253.619378] [] mlx4_en_process_rx_cq+0x753/0xb50 [mlx4_en] > [ 253.619387] [] mlx4_en_poll_rx_cq+0x97/0x160 [mlx4_en] What makes you think this is Xen specific? I suggest raising this the the mlx4 maintainers. David > [ 253.619393] [] net_rx_action+0x13d/0x2f0 > [ 253.619400] [] __do_softirq+0xda/0x1f0 > [ 253.619406] [] irq_exit+0x9d/0xb0 > [ 253.619412] [] xen_evtchn_do_upcall+0x35/0x50 > [ 253.619420] [] xen_do_hypervisor_callback+0x1e/0x40 > [ 253.619423] > [ 253.619426] [] ? shrink_dcache_for_umount+0x90/0x90 > [ 253.619437] [] ? d_alloc_pseudo+0x9/0x10 > [ 253.619443] [] ? sock_alloc_file+0x4d/0x120 > [ 253.619448] [] ? SYSC_accept4+0xb8/0x200 > [ 253.619454] [] ? SyS_epoll_wait+0x87/0xe0 > [ 253.619459] [] ? SyS_accept4+0x9/0x10 > [ 253.619465] [] ? system_call_fastpath+0x16/0x1b > [ 253.619469] Code: 4e 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 e8 6b fc > ff ff eb e1 90 90 90 90 90 90 90 90 90 48 89 f8 48 89 d1 48 c1 e9 03 83 > e2 07 > 48 a5 89 d1 f3 a4 c3 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c > [ 253.619513] RIP [] __memcpy+0xd/0x110 > [ 253.619520] RSP > [ 253.619524] ---[ end trace ba5d35a466b03856 ]--- > > On Tue, 28 Jul 2015, Christoffer Dall wrote: >> On Tue, Jul 28, 2015 at 4:55 PM, Ian Campbell >> wrote: >> On Tue, 2015-07-28 at 10:50 -0400, Konrad Rzeszutek Wilk wrote: >> > On Tue, Jul 28, 2015 at 03:09:31PM +0200, Christoffer Dall wrote: >> > > Hi, >> > > >> > > I've been doing some performance comparisons lately, and wanted to >> > > compare >> > > the performance overhead of using Xen with apache bench, but >> > > unfortunately >> > > the Dom0 kernel crashes when hitting it with ab from a remote >> machine. >> > > Most other workloads seem to be stable, however, I do see similar >> > > crashes >> > > if hitting Dom0 mysql with a mysql benchmark with a high level of >> > > parallelism. >> > > >> > > I use a 10G Mellanox MX354A Dual port FDR CX3 adapter for >> networking on >> > > a >> > > Dell PowerEdge R320 system with a Xeon E5-2450 and 16 GB of RAM. >> > > >> > > Interestingly, we had a similarly looking issue on arm64 recently, >> but >> > > that >> > > was fixed with an APM-soecific fix to the hypervisor, so I am >> guessing >> > > this >> > > is unrelated, see: >> > > http://lists.xenproject.org/archives/html/xen-devel/2015 >> > > -03/msg02731.html >> > > and the fix: >> > > >> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=50dcb3de603927db2fd >> > > 87ba09e29c817415aaa44 >> > > >> > > I have tried with several Linux versions, v3.13, v3.18, v4.0-rc4, >> and >> > > v4.1, >> > > same issue. I have tried with Xen 4.5-0 release, and the Ubuntu >> > > packaged >> > > Xen 4.4 release, same issue. >> > > >> > > Examples of crash: >> > > http://pastebin.ubuntu.com/11953498/ >> > > http://pastebin.ubuntu.com/11953443/ >> > >> > 4.0-rc4? >> > >> > Have you tried 4.1? >> >> According to the previous paragraph, yes he has. >> >> yes, I have. Just for clarify, I used 4.0-rc4 because that's a branch which >> contained arm64 PCI support and has >> been used for other measurements, so this was simply my 'working tree'. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 05/22] xen/arm: ITS: Port ITS driver to Xen
On Tue, Jul 28, 2015 at 10:16 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K
>>
>> The linux driver is based on 4.1 with below commit id
>>
>> 3ad2a5f57656a14d964b673a5a0e4ab0e583c870
>
> This doesn't include commit 591e5bec13f15feb13fc445b6c9c59954711c4ac
> "irqchip/gicv3-its: Fix mapping of LPIs to collections".
>
> On the version 4 of this series, Ian [1] said that it would be very nice
> to have a similar approach in Xen. I would like to see it too.
By storing col_id in msi_desc as below, I am already taking care of
the above commit
in this series
struct msi_desc {
#ifdef HAS_GICV3
unsigned int eventID;
struct its_device *dev;
u16 col_id;
#endif
};
Regards
Vijay
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Dom0 crash with apache bench (ab)
This is a Linux Dom0 crash on x86 (Dell PowerEdge R320, Xeon E5-2450), CC'ing relevant people. As you can see from the links below the crash is: [ 253.619326] Call Trace: [ 253.619330] [ 253.619332] [] ? skb_copy_ubufs+0xa5/0x230 [ 253.619347] [] __netif_receive_skb_core+0x6f5/0x940 [ 253.619353] [] __netif_receive_skb+0x18/0x60 [ 253.619360] [] netif_receive_skb_internal+0x28/0x90 [ 253.619366] [] napi_gro_frags+0x125/0x1a0 [ 253.619378] [] mlx4_en_process_rx_cq+0x753/0xb50 [mlx4_en] [ 253.619387] [] mlx4_en_poll_rx_cq+0x97/0x160 [mlx4_en] [ 253.619393] [] net_rx_action+0x13d/0x2f0 [ 253.619400] [] __do_softirq+0xda/0x1f0 [ 253.619406] [] irq_exit+0x9d/0xb0 [ 253.619412] [] xen_evtchn_do_upcall+0x35/0x50 [ 253.619420] [] xen_do_hypervisor_callback+0x1e/0x40 [ 253.619423] [ 253.619426] [] ? shrink_dcache_for_umount+0x90/0x90 [ 253.619437] [] ? d_alloc_pseudo+0x9/0x10 [ 253.619443] [] ? sock_alloc_file+0x4d/0x120 [ 253.619448] [] ? SYSC_accept4+0xb8/0x200 [ 253.619454] [] ? SyS_epoll_wait+0x87/0xe0 [ 253.619459] [] ? SyS_accept4+0x9/0x10 [ 253.619465] [] ? system_call_fastpath+0x16/0x1b [ 253.619469] Code: 4e 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 e8 6b fc ff ff eb e1 90 90 90 90 90 90 90 90 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c [ 253.619513] RIP [] __memcpy+0xd/0x110 [ 253.619520] RSP [ 253.619524] ---[ end trace ba5d35a466b03856 ]--- On Tue, 28 Jul 2015, Christoffer Dall wrote: > On Tue, Jul 28, 2015 at 4:55 PM, Ian Campbell wrote: > On Tue, 2015-07-28 at 10:50 -0400, Konrad Rzeszutek Wilk wrote: > > On Tue, Jul 28, 2015 at 03:09:31PM +0200, Christoffer Dall wrote: > > > Hi, > > > > > > I've been doing some performance comparisons lately, and wanted to > > > compare > > > the performance overhead of using Xen with apache bench, but > > > unfortunately > > > the Dom0 kernel crashes when hitting it with ab from a remote > machine. > > > Most other workloads seem to be stable, however, I do see similar > > > crashes > > > if hitting Dom0 mysql with a mysql benchmark with a high level of > > > parallelism. > > > > > > I use a 10G Mellanox MX354A Dual port FDR CX3 adapter for > networking on > > > a > > > Dell PowerEdge R320 system with a Xeon E5-2450 and 16 GB of RAM. > > > > > > Interestingly, we had a similarly looking issue on arm64 recently, > but > > > that > > > was fixed with an APM-soecific fix to the hypervisor, so I am > guessing > > > this > > > is unrelated, see: > > > http://lists.xenproject.org/archives/html/xen-devel/2015 > > > -03/msg02731.html > > > and the fix: > > > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=50dcb3de603927db2fd > > > 87ba09e29c817415aaa44 > > > > > > I have tried with several Linux versions, v3.13, v3.18, v4.0-rc4, > and > > > v4.1, > > > same issue. I have tried with Xen 4.5-0 release, and the Ubuntu > > > packaged > > > Xen 4.4 release, same issue. > > > > > > Examples of crash: > > > http://pastebin.ubuntu.com/11953498/ > > > http://pastebin.ubuntu.com/11953443/ > > > > 4.0-rc4? > > > > Have you tried 4.1? > > According to the previous paragraph, yes he has. > > yes, I have. Just for clarify, I used 4.0-rc4 because that's a branch which > contained arm64 PCI support and has > been used for other measurements, so this was simply my 'working tree'. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 10/22] xen/arm: ITS: Add GITS registers emulation
Hi Vijay,
On 31/07/15 08:25, Vijay Kilari wrote:
> On Wed, Jul 29, 2015 at 12:31 AM, Julien Grall
> wrote:
>> Hi Vijay,
>>
>> On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
>>> From: Vijaya Kumar K
>>>
>>> Emulate GITS* registers
>>>
>>> Signed-off-by: Vijaya Kumar K
>>> ---
>>> v4: - Removed GICR register emulation
>>> ---
>>> xen/arch/arm/irq.c|3 +
>>> xen/arch/arm/vgic-v3-its.c| 365
>>> -
>>> xen/include/asm-arm/gic-its.h | 15 ++
>>> xen/include/asm-arm/gic.h |1 +
>>> 4 files changed, 381 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>>> index 1f38605..85cacb0 100644
>>> --- a/xen/arch/arm/irq.c
>>> +++ b/xen/arch/arm/irq.c
>>> @@ -31,6 +31,9 @@
>>> static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>>> static DEFINE_SPINLOCK(local_irqs_type_lock);
>>>
>>> +/* Number of LPI supported in XEN */
>>> +unsigned int num_of_lpis = 8192;
>>> +
>>
>> It makes little sense to introduce the support of LPIs in Xen in a patch
>> called "Add GITS registers emulation".
>>
>> This should go in a specific ITS (not vITS) patch.
>>
>> Furthermore, you need to explain where to the 8192 comes from...
>
> Two reasons for setting to 8192
>
> 1) Being LPI starts from 8192 the 8192 is 13 and next if id_bits is 14
> then it can hold
> upto 16K. So 16K-8K = 8K
This is a valid reason. Please add it in the code.
[..]
>>> +static int vgic_v3_gits_mmio_read(struct vcpu *v, mmio_info_t *info)
>>> +{
>>> +struct vgic_its *vits = v->domain->arch.vgic.vits;
>>> +struct hsr_dabt dabt = info->dabt;
>>> +struct cpu_user_regs *regs = guest_cpu_user_regs();
>>> +register_t *r = select_user_reg(regs, dabt.reg);
>>> +uint64_t val = 0;
>>> +uint32_t gits_reg;
>>> +
>>> +gits_reg = info->gpa - vits->gits_base;
>>> +DPRINTK("%pv: vITS: GITS_MMIO_READ offset 0x%"PRIx32"\n", v, gits_reg);
>>> +
>>> +switch ( gits_reg )
>>> +{
>>> +case GITS_CTLR:
>>> +if ( dabt.size != DABT_WORD ) goto bad_width;
>>> +vits_spin_lock(vits);
>>> +*r = vits->ctrl | GITS_CTLR_QUIESCENT;
>>
>> Why did you put GITS_CTLR_QUIESCENT?
>
> The ITS is quiescent, has no translations in progress and has
> completed all operations.
> So I have set quescent by default.
This needs to be explained in the code.
[..]
>>> + * Mask those fields while emulating GITS_BASER reg.
>>> + */
>>
>> As said on v4,
>>
>> Other fields are (or could be RO) in GITS_BASER:
>> - Indirect: we only support flat table
> By default it is 0. So support flat table. Do you want it explicitly
>specify Indirect?
It's not what I said ... Your implementation in the VITS *only* supports
flat-table (i.e Single Level). You are currently allowing the guest to
set this bit to 1 which means that it may use Two Level.
This won't work with your implementation. So this field *should* be RAZ/WI.
>
>> - Page_Size: it's fine to only support 4KB granularity. It also
>> means less code.
> Page_size is set by guest. this is not RO
Please read the spec (8.19.1 in ARM IHI 0069A): "If the GIC
implementation supports only a single, fixed page size, this field might
be RO."
If you look closely to the Linux code, if it can't set the Page size it
will retry with a small granularity.
Implementing it as RO would have been fine and save a bit of checking.
Anyway, as said this was only a suggestion.
[..]
>>> int vits_domain_init(struct domain *d)
>>> {
>>> struct vgic_its *vits;
>>> int i;
>>>
>>> +if ( is_hardware_domain(d) )
>>> +d->arch.vgic.nr_lpis = num_of_lpis;
>>> +else
>>> +d->arch.vgic.nr_lpis = NR_LPIS;
>>
>> NR_LPIS is defined in patch #14. And the name seems to be wrong.
>>
>> Anyway, I don't understand why you are trying to initialize vITS on
>> guest. We agree that it should only be used on DOM0 for now until we
>> effectively need it for the guest.
>>
>> Furthermore, it miss at least the toolstack in order to get the part
>> guest ready.
>>
>> So please ensure that the vITS is not initialized for the guest.
>
> In patch#18, this function is called only for DOM0
So why do try to half support vITS for guest? As said, there is lots of
things missing to get the support done for guest (toolstack, ITS
mapping,...).
Please drop all the references to the guest in vits_domain_init and add
an ASSERT to check that vits_init_domain is not called for guest.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Fri, 2015-07-31 at 09:05 +0100, Ian Campbell wrote: > On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote: > > > > Secondly, the vdev-X entry is created async by dom0 watching on > > > > event. Stefano points out that there are, confusingly, two nodes in xenstore relating to the virtual-SBDF. vdev-X is written by pciback and is read by pcifront, it is effectively there to communicate the vSBDF to the guest. vdevfn-X is written by the toolstack (libxl_create_pci_backend_device) to tell the backend (pciback, or qemu in x86/HVM configurations using old qemu) the vSBDF to be associated with the device. It looks like vdevfn-X is not actually currently supported by pciback in Linux (seemingly only the x86/HVM qemu backend consumes it). I think we should add that support to pciback for consistency with the qemu based backend used by x86/HVM guests. The names are a certainly a bit confusing. We could add a new key with a better name to communicate the vSBDF from toolstack->backend, but itseems to me to be that would just adding even more confusion, so I recommend we don't do that. Once pciback supports vdevfn then libxl will be able to choose the PCI bus layout for ARM guests in the case where the use has not requested an explicit vdevfn for the device. Does that make sense? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 07/22] xen/arm: ITS: Add virtual ITS driver
On Fri, 2015-07-31 at 11:14 +0100, Julien Grall wrote:
> Hi Vijay,
>
> On 31/07/15 07:49, Vijay Kilari wrote:
> > > > +static int vits_vitt_entry(struct domain *d, uint32_t devid,
> > > > + uint32_t event, struct vitt *entry,
> > > > bool_t set)
> > > > +{
> > > > +struct vdevice_table dt_entry;
> > > > +paddr_t vitt_entry;
> > > > +uint64_t offset;
> > > > +
> > > > +BUILD_BUG_ON(sizeof(struct vitt) != 8);
> > > > +
> > > > +if ( vits_get_vdevice_entry(d, devid, &dt_entry) )
> > > > +{
> > > > +printk(XENLOG_G_ERR
> > > > +"d%"PRId32": vITS: Fail to get vdevice for vdev
> > > > 0x%"PRIx32"\n",
> > >
> > > s/vdev/vdevid/
> >
> > I think, to manage within 80 char, I used just "vdev"
>
> 80 character in the source file I guess? If so, you should avoid this
> kind of cutting just for coding style benefits. We are not so strict on
> it.
It's also acceptable to indent string constants by less than what would be
expected to avoid this, e.g.
printk(XENLOG_G_ERR
d%"PRId32": vITS: Fail to get vdevice for vdevid 0x%"PRIx32"\n",
(also, s/Fail/Failed/ or perhaps "Unable").
Also, I don't think PRId32 is what we should use for d->domain_id. The
actual type is uint16_t, which would suggest PRIu16 (or maybe PRId16) is
formally correct but in actuality we normally use %u or %d in this case (%u
is probably more correct, although it appears to be in the minority).
> > > > +d->domain_id, devid);
> > > > +return -EINVAL;
> > > > +}
> > > > +
> > > > +/* dt_entry is validated in vits_get_vdevice_entry */
> > >
> > > s/is validated/has been validated/
> > >
> > > [..]
> > >
> > > > +int vits_set_vitt_entry(struct domain *d, uint32_t devid,
> > > > +uint32_t event, struct vitt *entry)
> > >
> > > Same remark as vits_set_vdevice_entry.
> >
> > I have made non-static for compilation purpose. I will try to introduce
> > this in the patch where it is used. But it is more logical to have this
> > in this patch. Anyway I forget to make it static in later patches
>
> Having introduce static here would have avoid forgetting the static
> later... It's just a matter of how you split your series.
>
> For instance, if you would have merge this patch with #8, making this
> function non-static wouldn't have been necessary.
I've also suggest elsewhere not adding these new files to the build until
later in the series, such that the user of this function is already added
by the time the file starts to get compiled.
That approach is usually acceptable when introducing a large new file which
isn't used until towards the end of the series.
Of course you need to avoid calling any functions in that file until after
you add it to the build, which introduces a different constraint on the
series ordering, so it's not always possible to make use of this approach.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] VM Migration on a NUMA server?
Hi all, I'm sorry for taking your time and I'd like to make an enquery about the status of VM migration support on a NUMA server. Currently It looks like when a vm is migrated only its vcpus are moved to the other node but not its memory. So, is anyone trying to fix that issue? If I want to do it myself, it seems like two major problems are ahead of me: 1) How to specify the target node for memory migration? I'll be grateful if anyone can give me some hints. 2) Memory Migration. Looks like it can be done by leveraging the existing migration related functions on Xen. I don't have much practical experience on NUMA machines. And I'll be appreciated for any reply & help. Thanks, Kenneth ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-sid test] 37766: tolerable FAIL
flight 37766 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/37766/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-amd64-amd64-sid-netboot-pvgrub 10 guest-start fail never pass test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail never pass jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-sid-netboot-pvgrubfail test-amd64-i386-i386-sid-netboot-pvgrub pass test-amd64-i386-amd64-sid-netboot-pygrub pass test-armhf-armhf-armhf-sid-netboot-pygrubfail test-amd64-amd64-i386-sid-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/8] arm/xen: Remove helpers which are PV specific
On Tue, 28 Jul 2015, Julien Grall wrote:
> ARM guests are assimilated to HVM guest on ARM. The current
> implementation is assuming a 1:1 mapping which is only true for DOM0 and
> may not be at all in the future.
>
> Furthermore, all the helpers but arbitrary_virt_to_machine are used in
> x86 specific code (or only compiled for).
>
> The helper arbitrary_virt_to_machine is only used in PV specific code.
> Therefore we should never call the function.
>
> Add a BUG() in this helper and drop all the others.
>
> Signed-off-by: Julien Grall
> Cc: Stefano Stabellini
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> arch/arm/include/asm/xen/page.h | 16 ++--
> 1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 1bee8ca..c2e9dcd 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -54,26 +54,14 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
>
> #define mfn_to_local_pfn(mfn) mfn_to_pfn(mfn)
>
> -static inline xmaddr_t phys_to_machine(xpaddr_t phys)
> -{
> - unsigned offset = phys.paddr & ~PAGE_MASK;
> - return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
> -}
> -
> -static inline xpaddr_t machine_to_phys(xmaddr_t machine)
> -{
> - unsigned offset = machine.maddr & ~PAGE_MASK;
> - return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
> -}
> /* VIRT <-> MACHINE conversion */
> -#define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v
> #define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
> #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
>
> +/* Only used in PV code. However ARM guest is always assimilated as HVM. */
^ "However" doesn't make sense here from an
english grammer point of view.
Aside from this:
Acked-by: Stefano Stabellini
> static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
> {
> - /* TODO: assuming it is mapped in the kernel 1:1 */
> - return virt_to_machine(vaddr);
> + BUG();
> }
>
> /* TODO: this shouldn't be here but it is because the frontend drivers
> --
> 2.1.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv1] arm: reduce power use by contented spin locks with WFE/SEV
Instead of cpu_relax() while spinning and observing the ticket head,
introduce spin_relax() which executes a WFE instruction. After the
ticket head is changed call spin_signal() to execute an SVE
instruction to wake any spinners.
This should improve power consumption when locks are contented and
spinning.
Signed-off-by: David Vrabel
---
I've not tested this but it looks straight-forward...
---
xen/common/spinlock.c | 5 +++--
xen/include/asm-arm/spinlock.h | 3 ++-
xen/include/asm-x86/spinlock.h | 3 +++
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 29149d1..fc3e8e7 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -141,7 +141,7 @@ void _spin_lock(spinlock_t *lock)
while ( tickets.tail != observe_head(&lock->tickets) )
{
LOCK_PROFILE_BLOCK;
-cpu_relax();
+spin_relax();
}
LOCK_PROFILE_GOT;
preempt_disable();
@@ -170,6 +170,7 @@ void _spin_unlock(spinlock_t *lock)
preempt_enable();
LOCK_PROFILE_REL;
add_sized(&lock->tickets.head, 1);
+spin_signal();
}
void _spin_unlock_irq(spinlock_t *lock)
@@ -228,7 +229,7 @@ void _spin_barrier(spinlock_t *lock)
if ( sample.head != sample.tail )
{
while ( observe_head(&lock->tickets) == sample.head )
-cpu_relax();
+spin_relax();
#ifdef LOCK_PROFILE
if ( lock->profile )
{
diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
index 81955d1..311764b 100644
--- a/xen/include/asm-arm/spinlock.h
+++ b/xen/include/asm-arm/spinlock.h
@@ -1,6 +1,7 @@
#ifndef __ASM_SPINLOCK_H
#define __ASM_SPINLOCK_H
-/* Nothing ARM specific. */
+#define spin_relax() asm volatile("wfe" ::: "memory");
+#define spin_signal() asm volatile("sev" ::: "memory");
#endif /* __ASM_SPINLOCK_H */
diff --git a/xen/include/asm-x86/spinlock.h b/xen/include/asm-x86/spinlock.h
index 7d69e75..0c04a4e 100644
--- a/xen/include/asm-x86/spinlock.h
+++ b/xen/include/asm-x86/spinlock.h
@@ -4,4 +4,7 @@
#define _raw_read_unlock(l) \
asm volatile ( "lock; dec%z0 %0" : "+m" ((l)->lock) :: "memory" )
+#define spin_relax() cpu_relax()
+#define spin_signal()
+
#endif /* __ASM_SPINLOCK_H */
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1] arm: reduce power use by contented spin locks with WFE/SEV
On 31/07/15 11:45, David Vrabel wrote:
> Instead of cpu_relax() while spinning and observing the ticket head,
> introduce spin_relax() which executes a WFE instruction. After the
> ticket head is changed call spin_signal() to execute an SVE
> instruction to wake any spinners.
>
> This should improve power consumption when locks are contented and
> spinning.
>
> Signed-off-by: David Vrabel
x86 bits Reviewed-by: Andrew Cooper
> ---
> I've not tested this but it looks straight-forward...
> ---
> xen/common/spinlock.c | 5 +++--
> xen/include/asm-arm/spinlock.h | 3 ++-
> xen/include/asm-x86/spinlock.h | 3 +++
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
> index 29149d1..fc3e8e7 100644
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -141,7 +141,7 @@ void _spin_lock(spinlock_t *lock)
> while ( tickets.tail != observe_head(&lock->tickets) )
> {
> LOCK_PROFILE_BLOCK;
> -cpu_relax();
> +spin_relax();
> }
> LOCK_PROFILE_GOT;
> preempt_disable();
> @@ -170,6 +170,7 @@ void _spin_unlock(spinlock_t *lock)
> preempt_enable();
> LOCK_PROFILE_REL;
> add_sized(&lock->tickets.head, 1);
> +spin_signal();
> }
>
> void _spin_unlock_irq(spinlock_t *lock)
> @@ -228,7 +229,7 @@ void _spin_barrier(spinlock_t *lock)
> if ( sample.head != sample.tail )
> {
> while ( observe_head(&lock->tickets) == sample.head )
> -cpu_relax();
> +spin_relax();
> #ifdef LOCK_PROFILE
> if ( lock->profile )
> {
> diff --git a/xen/include/asm-arm/spinlock.h b/xen/include/asm-arm/spinlock.h
> index 81955d1..311764b 100644
> --- a/xen/include/asm-arm/spinlock.h
> +++ b/xen/include/asm-arm/spinlock.h
> @@ -1,6 +1,7 @@
> #ifndef __ASM_SPINLOCK_H
> #define __ASM_SPINLOCK_H
>
> -/* Nothing ARM specific. */
> +#define spin_relax() asm volatile("wfe" ::: "memory");
> +#define spin_signal() asm volatile("sev" ::: "memory");
>
> #endif /* __ASM_SPINLOCK_H */
> diff --git a/xen/include/asm-x86/spinlock.h b/xen/include/asm-x86/spinlock.h
> index 7d69e75..0c04a4e 100644
> --- a/xen/include/asm-x86/spinlock.h
> +++ b/xen/include/asm-x86/spinlock.h
> @@ -4,4 +4,7 @@
> #define _raw_read_unlock(l) \
> asm volatile ( "lock; dec%z0 %0" : "+m" ((l)->lock) :: "memory" )
>
> +#define spin_relax() cpu_relax()
> +#define spin_signal()
> +
> #endif /* __ASM_SPINLOCK_H */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1] arm: reduce power use by contented spin locks with WFE/SEV
On 31/07/15 11:45, David Vrabel wrote:
> Instead of cpu_relax() while spinning and observing the ticket head,
> introduce spin_relax() which executes a WFE instruction. After the
> ticket head is changed call spin_signal() to execute an SVE
> instruction to wake any spinners.
>
> This should improve power consumption when locks are contented and
> spinning.
>
> Signed-off-by: David Vrabel
> ---
> I've not tested this but it looks straight-forward...
> ---
> xen/common/spinlock.c | 5 +++--
> xen/include/asm-arm/spinlock.h | 3 ++-
> xen/include/asm-x86/spinlock.h | 3 +++
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
> index 29149d1..fc3e8e7 100644
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -141,7 +141,7 @@ void _spin_lock(spinlock_t *lock)
> while ( tickets.tail != observe_head(&lock->tickets) )
> {
> LOCK_PROFILE_BLOCK;
> -cpu_relax();
> +spin_relax();
> }
> LOCK_PROFILE_GOT;
> preempt_disable();
> @@ -170,6 +170,7 @@ void _spin_unlock(spinlock_t *lock)
> preempt_enable();
> LOCK_PROFILE_REL;
> add_sized(&lock->tickets.head, 1);
> +spin_signal();
It occurs to me that perhaps there should be a barrier between the
add_sized() and the spin_signal() so the update value is visible before
we signal (otherwise the spinner may be woken and observe the old value
and WFE again).
spin_relax() and spin_signal() might be better named arch_lock_relax()
and arch_lock_signal() to match the naming of existing arch_lock_*() hooks.
I think someone with more arm experience (and the means to test) should
take this patch on.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/8] xen: Make clear that swiotlb and biomerge are dealing with DMA address
On Tue, 28 Jul 2015, David Vrabel wrote: > On 28/07/15 16:02, Julien Grall wrote: > > > > +/* Pseudo-physical <-> DMA conversion */ > > +static inline unsigned long pfn_to_dfn(unsigned long pfn) > > Use BFN for bus frame number. This is the terminology that is used in > the (proposed) pv-iommu hypercall. Yes, certainly better than DFN. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/8] arm/xen: Remove helpers which are PV specific
On Fri, 2015-07-31 at 11:44 +0100, Stefano Stabellini wrote:
> On Tue, 28 Jul 2015, Julien Grall wrote:
> > ARM guests are assimilated to HVM guest on ARM. The current
> > implementation is assuming a 1:1 mapping which is only true for DOM0
> > and
> > may not be at all in the future.
> >
> > Furthermore, all the helpers but arbitrary_virt_to_machine are used in
> > x86 specific code (or only compiled for).
> >
> > The helper arbitrary_virt_to_machine is only used in PV specific code.
> > Therefore we should never call the function.
> >
> > Add a BUG() in this helper and drop all the others.
> >
> > Signed-off-by: Julien Grall
> > Cc: Stefano Stabellini
> > Cc: Russell King
> > Cc: linux-arm-ker...@lists.infradead.org
> > ---
> > arch/arm/include/asm/xen/page.h | 16 ++--
> > 1 file changed, 2 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/xen/page.h
> > b/arch/arm/include/asm/xen/page.h
> > index 1bee8ca..c2e9dcd 100644
> > --- a/arch/arm/include/asm/xen/page.h
> > +++ b/arch/arm/include/asm/xen/page.h
> > @@ -54,26 +54,14 @@ static inline unsigned long mfn_to_pfn(unsigned
> > long mfn)
> >
> > #define mfn_to_local_pfn(mfn) mfn_to_pfn(mfn)
> >
> > -static inline xmaddr_t phys_to_machine(xpaddr_t phys)
> > -{
> > - unsigned offset = phys.paddr & ~PAGE_MASK;
> > - return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) |
> > offset);
> > -}
> > -
> > -static inline xpaddr_t machine_to_phys(xmaddr_t machine)
> > -{
> > - unsigned offset = machine.maddr & ~PAGE_MASK;
> > - return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) |
> > offset);
> > -}
> > /* VIRT <-> MACHINE conversion */
> > -#define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v
> > #define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
> > #define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
> >
> > +/* Only used in PV code. However ARM guest is always assimilated as
> > HVM. */
>^ "However" doesn't make sense here from an
>english grammer point of view.
"English grammar" :-P
Sorry. What I really meant to say was that "assimilated" doesn't make sense
in this context either. I think maybe what was meant is "ARM guests are
always HVM".
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST] Osstest/TestSupport: Hide $ho->{Toolstack} from casual use
This should only be accessed via toolstack($ho), which is responsible
for caching the value. Rename the field to _Toolstack to deter code
from using it.
Signed-off-by: Ian Campbell
---
Osstest/TestSupport.pm | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 84e86fd..0370129 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2076,11 +2076,11 @@ sub guest_vncsnapshot_stash () {
sub toolstack ($) {
my ($ho) = @_;
-return $ho->{Toolstack} if $ho->{Toolstack};
+return $ho->{_Toolstack} if $ho->{_Toolstack};
my $tsname= $r{toolstack} || 'xend';
-$ho->{Toolstack}= get_host_method_object($ho, 'Toolstack', $tsname);
-return $ho->{Toolstack};
+$ho->{_Toolstack}= get_host_method_object($ho, 'Toolstack', $tsname);
+return $ho->{_Toolstack};
}
sub authorized_keys () {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1] arm: reduce power use by contented spin locks with WFE/SEV
Hi David,
On 31/07/15 11:52, David Vrabel wrote:
> On 31/07/15 11:45, David Vrabel wrote:
>> Instead of cpu_relax() while spinning and observing the ticket head,
>> introduce spin_relax() which executes a WFE instruction. After the
>> ticket head is changed call spin_signal() to execute an SVE
>> instruction to wake any spinners.
>>
>> This should improve power consumption when locks are contented and
>> spinning.
>>
>> Signed-off-by: David Vrabel
>> ---
>> I've not tested this but it looks straight-forward...
>> ---
>> xen/common/spinlock.c | 5 +++--
>> xen/include/asm-arm/spinlock.h | 3 ++-
>> xen/include/asm-x86/spinlock.h | 3 +++
>> 3 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
>> index 29149d1..fc3e8e7 100644
>> --- a/xen/common/spinlock.c
>> +++ b/xen/common/spinlock.c
>> @@ -141,7 +141,7 @@ void _spin_lock(spinlock_t *lock)
>> while ( tickets.tail != observe_head(&lock->tickets) )
>> {
>> LOCK_PROFILE_BLOCK;
>> -cpu_relax();
>> +spin_relax();
>> }
>> LOCK_PROFILE_GOT;
>> preempt_disable();
>> @@ -170,6 +170,7 @@ void _spin_unlock(spinlock_t *lock)
>> preempt_enable();
>> LOCK_PROFILE_REL;
>> add_sized(&lock->tickets.head, 1);
>> +spin_signal();
>
> It occurs to me that perhaps there should be a barrier between the
> add_sized() and the spin_signal() so the update value is visible before
> we signal (otherwise the spinner may be woken and observe the old value
> and WFE again).
sev is usually precede by dsb to ensure that all the instructions before
as completed before executing the sev.
> spin_relax() and spin_signal() might be better named arch_lock_relax()
> and arch_lock_signal() to match the naming of existing arch_lock_*() hooks.
>
> I think someone with more arm experience (and the means to test) should
> take this patch on.
I will give a look next week.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
On Tue, 28 Jul 2015, Julien Grall wrote:
> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
> is meant, I suspect this is because the first support for Xen was for
> PV. This brough some misimplementation of helpers on ARM and make the
> developper confused the expected behavior.
>
> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
> Although, if we look at the implementation on x86, it's returning a GFN.
>
> For clarity and avoid new confusion, replace any reference of mfn into
> gnf in any helpers used by PV drivers.
>
> Take also the opportunity to simplify simple construction such
> as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up
> will come in follow-up patches.
>
> I think it may be possible to do further clean up in the x86 code to
> ensure that helpers returning machine address (such as virt_address) is
> not used by no auto-translated guests. I will let x86 xen expert doing
> it.
>
> [1] Xen tree: e758ed14f390342513405dd766e874934573e6cb
>
> Signed-off-by: Julien Grall
Aside from the many typos
Reviewed-by: Stefano Stabellini
> arch/arm/include/asm/xen/page.h | 13 +++--
> arch/x86/include/asm/xen/page.h | 30 --
> arch/x86/xen/enlighten.c| 4 ++--
> arch/x86/xen/mmu.c | 16
> arch/x86/xen/p2m.c | 32
> arch/x86/xen/setup.c| 12 ++--
> arch/x86/xen/smp.c | 4 ++--
> arch/x86/xen/suspend.c | 8
> drivers/block/xen-blkfront.c| 6 +++---
> drivers/input/misc/xen-kbdfront.c | 4 ++--
> drivers/net/xen-netback/netback.c | 4 ++--
> drivers/net/xen-netfront.c | 8
> drivers/scsi/xen-scsifront.c| 8 +++-
> drivers/tty/hvc/hvc_xen.c | 5 +++--
> drivers/video/fbdev/xen-fbfront.c | 4 ++--
> drivers/xen/balloon.c | 2 +-
> drivers/xen/events/events_base.c| 2 +-
> drivers/xen/events/events_fifo.c| 4 ++--
> drivers/xen/gntalloc.c | 3 ++-
> drivers/xen/manage.c| 2 +-
> drivers/xen/tmem.c | 4 ++--
> drivers/xen/xenbus/xenbus_client.c | 2 +-
> drivers/xen/xenbus/xenbus_dev_backend.c | 2 +-
> drivers/xen/xenbus/xenbus_probe.c | 8 +++-
> include/xen/page.h | 4 ++--
> 25 files changed, 96 insertions(+), 95 deletions(-)
>
> diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
> index 493471f..f542f68 100644
> --- a/arch/arm/include/asm/xen/page.h
> +++ b/arch/arm/include/asm/xen/page.h
> @@ -34,14 +34,15 @@ typedef struct xpaddr {
> unsigned long __pfn_to_mfn(unsigned long pfn);
> extern struct rb_root phys_to_mach;
>
> -static inline unsigned long pfn_to_mfn(unsigned long pfn)
> +/* Pseudo-physical <-> Guest conversion */
> +static inline unsigned long pfn_to_gfn(unsigned long pfn)
> {
> return pfn;
> }
>
> -static inline unsigned long mfn_to_pfn(unsigned long mfn)
> +static inline unsigned long gfn_to_pfn(unsigned long gfn)
> {
> - return mfn;
> + return gfn;
> }
>
> /* Pseudo-physical <-> DMA conversion */
> @@ -65,9 +66,9 @@ static inline unsigned long dfn_to_pfn(unsigned long dfn)
>
> #define dfn_to_local_pfn(dfn)dfn_to_pfn(dfn)
>
> -/* VIRT <-> MACHINE conversion */
> -#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
> -#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
> +/* VIRT <-> GUEST conversion */
> +#define virt_to_gfn(v) (pfn_to_gfn(virt_to_pfn(v)))
> +#define gfn_to_virt(m) (__va(gfn_to_pfn(m) << PAGE_SHIFT))
>
> /* Only used in PV code. However ARM guest is always assimilated as HVM. */
> static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 046e91a..72d9f15 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -99,7 +99,7 @@ static inline unsigned long __pfn_to_mfn(unsigned long pfn)
> return mfn;
> }
>
> -static inline unsigned long pfn_to_mfn(unsigned long pfn)
> +static inline unsigned long pfn_to_gfn(unsigned long pfn)
> {
> unsigned long mfn;
>
> @@ -145,23 +145,23 @@ static inline unsigned long
> mfn_to_pfn_no_overrides(unsigned long mfn)
> return pfn;
> }
>
> -static inline unsigned long mfn_to_pfn(unsigned long mfn)
> +static inline unsigned long gfn_to_pfn(unsigned long gfn)
> {
> unsigned long pfn;
>
> if (xen_feature(XENFEAT_auto_translated_physmap))
> - return mfn;
> + return gfn;
>
> - pfn = mfn_to_pfn_no_overrides(mfn);
> - if (__pfn_to_mfn(pfn) != mfn)
> + pfn = mfn_to_pfn_no_overrides(gf
Re: [Xen-devel] [PATCH v5 12/22] xen/arm: ITS: Add GICR register emulation
On 31/07/15 10:08, Vijay Kilari wrote:
> On Thu, Jul 30, 2015 at 10:34 PM, Julien Grall
> wrote:
>> Hi Vijay,
>>
>> On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
>>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>>
>> [..]
>>
>>> +static int gicv3_dist_supports_lpis(void)
>>> +{
>>> +return readl_relaxed(GICD + GICD_TYPER) & GICD_TYPER_LPIS_SUPPORTED;
>>> +}
>>> +
>>> static int __cpuinit gicv3_cpu_init(void)
>>> {
>>> int i;
>>> @@ -1274,6 +1279,11 @@ static int __init gicv3_init(void)
>>>
>>> spin_lock(&gicv3.lock);
>>>
>>> +if ( gicv3_dist_supports_lpis() )
>>> +gicv3_info.lpi_supported = 1;
>>> +else
>>> +gicv3_info.lpi_supported = 0;
>>> +
>>
>> You will avoid 3 lines if you do:
>>
>> gicv3_info.lpi_supported = !!gicv3_dist_supports_lpis();
>>
>
>This will change in patch #17 where we do check for its_probe() to
> be succesful
> to set gicv3_info.lpi_supported
Then move this addition of lpi_supported in patch #17. This is not
necessary at all here. And this is quite confusing to see GIC specific
changes in vGIC code.
Overall, I think your series would benefits to be split in two parts.
First part would contains all the code for the hardware GIC/ITS driver.
The second part would be for virtual GIC/ITS changes.
>>> gicv3_dist_init();
>>> res = gicv3_cpu_init();
>>> gicv3_hyp_init();
>>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>> index 1757193..af8a34b 100644
>>> --- a/xen/arch/arm/gic.c
>>> +++ b/xen/arch/arm/gic.c
>>> @@ -67,6 +67,11 @@ unsigned int gic_number_lines(void)
>>> return gic_hw_ops->info->nr_lines;
>>> }
>>>
>>> +bool_t gic_lpi_supported(void)
>>> +{
>>> +return gic_hw_ops->info->lpi_supported;
>>> +}
>>> +
>>> void gic_save_state(struct vcpu *v)
>>> {
>>> ASSERT(!local_irq_is_enabled());
>>> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
>>> index 1c7d9b6..4afb62b 100644
>>> --- a/xen/arch/arm/vgic-v3-its.c
>>> +++ b/xen/arch/arm/vgic-v3-its.c
>>
>> Can you explain why the emulation of the LPI property table has to be
>> done in the vITS code?
>>
>> Overall, there is nothing vITS specific in this code and all the
>> functions you've introduced within this file are called only by the
>> vgic-v3 code.
>
> yes, it is called from vgic-v3 code because it is emulating GICR_PROP/PEND
> registers.
>
> This is emulating LPI property table. Hence all the LPI handling code is kept
> in vits file.
> GICR_PROP/PEND is defined only for LPI case.
You don't explain why the LPI handling code is kept in the vits file
The LPI property table can exist even without the presence of
the ITS.
There is nothing ITS specific in the emulation, and your design prove it
(you are calling all the emulation code from the vGICv3).
>>
>>> @@ -28,6 +28,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -76,6 +77,34 @@ static inline uint32_t vits_get_max_collections(struct
>>> domain *d)
>>> return (d->max_vcpus + 1);
>>> }
>>>
>>> +static void vits_disable_lpi(struct vcpu *v, uint32_t vlpi)
>>> +{
>>> +struct pending_irq *p;
>>> +
>>> +p = irq_to_pending(v, vlpi);
>>> +clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>>> +gic_remove_from_queues(v, vlpi);
>>> +}
>>> +
>>> +static void vits_enable_lpi(struct vcpu *v, uint32_t vlpi, uint8_t
>>> priority)
>>> +{
>>> +struct pending_irq *p;
>>> +unsigned long flags;
>>> +
>>> +p = irq_to_pending(v, vlpi);
>>> +
>>> +set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>>> +
>>> +spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>> +
>>> +/*XXX: raise on right vcpu */
>>
>> As said on the previous versions, I think there will be locking issue
>> given that pending_irq structure is protected by the vCPU where the IRQ
>> is locked.
>
> Can you please explain in detail why there is a locking issue.
> I remember this locking mechanism is coming from enable_irqs()
> as we follow same infrastructure to inject/process LPIs
I guess you mean vgic_enable_irqs? And no what you've implemented is
definitely not the same as vgic_enable_irqs.
vgic_enable_irqs is locking the pending_irq structure using the vgic
lock of the targeting VCPU (see v_target = ... ->get_target_cpu(...)).
Here, you are locking with the current vCPU, i.e the vCPU which wrote
into the LPI property table.
All the vGIC code is doing the same, so using the wrong locking won't
protect this structure.
>
>>
>> If you think it's not the case please explain why but don't leave the
>> question unanswered.
>>
> [...]
>>>
>>> +
>>> +int vits_map_lpi_prop(struct domain *d)
>>> +{
>>> +struct vgic_its *vits = d->arch.vgic.vits;
>>> +paddr_t gaddr, addr;
>>> +unsigned long mfn;
>>> +uint32_t lpi_size, id_bits;
>>> +int i;
>>> +
>>> +gaddr = vits->propbase & MASK_4K;
>>
>> The physical address is only bits [47:12]. The uppers are either RES0 or
>> used for the OuterCac
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Friday 31 July 2015 01:35 PM, Ian Campbell wrote: On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote: Secondly, the vdev-X entry is created async by dom0 watching on event. So how the tools could read back and call assign device again. Perhaps by using a xenstore watch on that node to wait for the assignment from pciback to occur. As per the flow in the do_pci_add function, assign_device is called first and based on the success xenstore entry is created. Are you suggesting to change the sequence. Perhaps that is what it would take, yes, or maybe some other refactoring (e.g. splitting assign_device into two stages) might be the answer. The hypercall from xenpciback (what I implemented) is actually making the assign device in 2 stages. I think the point of contention is the second stage should be from toolstack. I think calling xc_assign_device after xenstore from the watch callback is the only option. One question is how to split the code for ARM and x86 as this is the common code. Would #ifdef CONFIG_ARM64 ok with maintainers. My current preference is for the suggestion below which is to let the toolstack pick the vdevfn and have pciback honour it. That would duplicate code for dev-fn generation into toolstack from __xen_pcibk_add_pci_dev. We can discuss this more on #xenarm irc Sorry I missed your ping yesterday, I had already gone home. Or you could change things such that vdevfn is always chosen by the toolstack for ARM, not optionally like it is on x86. For this one, the struct libxl_device_pci has a field "vdevfn", which is supposed to allow the user to specify a specific vdevfn. I'm not sure how that happens or fits together but libxl could undertake to set that on ARM in the case where the user hasn't done so, effectively taking control of the PCI bus assignment. Ian. ___ 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 mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] Emulation issues
Friday, July 31, 2015, 12:22:16 PM, you wrote: >> -Original Message- >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- >> boun...@lists.xen.org] On Behalf Of Paul Durrant >> Sent: 30 July 2015 14:20 >> To: Andrew Cooper; Roger Pau Monne; xen-devel >> Subject: Re: [Xen-devel] [BUG] Emulation issues >> >> > -Original Message- >> > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> > Sent: 30 July 2015 14:19 >> > To: Paul Durrant; Roger Pau Monne; xen-devel >> > Subject: Re: [BUG] Emulation issues >> > >> > On 30/07/15 14:12, Paul Durrant wrote: >> > >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >> > >> (XEN) domain_crash called from io.c:166 >> > >> (XEN) d19v0 weird emulation state 1 >> > >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >> > >> (XEN) domain_crash called from io.c:166 >> > >> (XEN) d19v0 weird emulation state 1 >> > >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >> > >> (XEN) domain_crash called from io.c:166 >> > >> >> > > Hmm. Can't understand how that's happening... handle_pio() shouldn't >> be >> > called unless the state is STATE_IORESP_READY and yet the inner function >> is >> > hitting the default case in the switch. >> > >> > Sounds like something is changing the state between the two checks. Is >> > this shared memory writeable by qemu? >> > >> >> No, this is the internal state. I really can't see how it's being changed. >> > I've tried to replicate your test on my rig (which is an old AMD box but > quite a big one). Even so I only seem to get about half the VMs to start. The > shutdown works fine, and I don't see any problems on the Xen console. I'm > using an older build of Xen but still one with my series in. I'll try pulling > up to the same commit as you and try again. > Paul Hi Paul, >From what i recall it started around when Tiejun Chen's series went in. -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 05/22] xen/arm: ITS: Port ITS driver to Xen
On 31/07/15 11:28, Vijay Kilari wrote:
> On Tue, Jul 28, 2015 at 10:16 PM, Julien Grall
> wrote:
>> Hi Vijay,
>>
>> On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
>>> From: Vijaya Kumar K
>>>
>>> The linux driver is based on 4.1 with below commit id
>>>
>>> 3ad2a5f57656a14d964b673a5a0e4ab0e583c870
>>
>> This doesn't include commit 591e5bec13f15feb13fc445b6c9c59954711c4ac
>> "irqchip/gicv3-its: Fix mapping of LPIs to collections".
>>
>> On the version 4 of this series, Ian [1] said that it would be very nice
>> to have a similar approach in Xen. I would like to see it too.
>
> By storing col_id in msi_desc as below, I am already taking care of
> the above commit
> in this series
>
> struct msi_desc {
> #ifdef HAS_GICV3
> unsigned int eventID;
> struct its_device *dev;
> u16 col_id;
> #endif
> };
Which requires the caller of the ITS command to explicitly pass the
collection ID...
It complicates the caller for nothing and requires you to have
explicitely irqdesc helpers.
Anyway, I don't see any reason to differ from Linux and AFAICT Ian was
also in favor of using the same approach as Linux (i.e the one in the
commit "irqchip/gicv3-its: Fix mapping of LPIs to collections").
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Fri, 2015-07-31 at 16:37 +0530, Manish Jaggi wrote: > > On Friday 31 July 2015 01:35 PM, Ian Campbell wrote: > > On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote: > > > > > Secondly, the vdev-X entry is created async by dom0 watching on > > > > > event. > > > > > So how the tools could read back and call assign device again. > > > > Perhaps by using a xenstore watch on that node to wait for the > > > > assignment > > > > from pciback to occur. > > > As per the flow in the do_pci_add function, assign_device is called > > > first and based on the success xenstore entry is created. > > > Are you suggesting to change the sequence. > > Perhaps that is what it would take, yes, or maybe some other > > refactoring > > (e.g. splitting assign_device into two stages) might be the answer. > The hypercall from xenpciback (what I implemented) is actually making > the assign device in 2 stages. > I think the point of contention is the second stage should be from > toolstack. > > I think calling xc_assign_device after xenstore from the watch callback > is the only option. Only if you ignore the other option I proposed. > One question is how to split the code for ARM and x86 as this is the > common code. > Would #ifdef CONFIG_ARM64 ok with maintainers. No. arch hooks in libxl_$ARCH.c (with nop implementations where necessary) would be the way to approach this. However I still am not convinced this is the approach we should be taking. > > My current preference is for the suggestion below which is to let the > > toolstack pick the vdevfn and have pciback honour it. > That would duplicate code for dev-fn generation into toolstack from > __xen_pcibk_add_pci_dev. IMHO the toolstack is the correct place for this code, at least for ARM guests. The toolstack is, in general, responsible for all aspects of the guest layout. I don't think delegating the PCI bus parts of that to the dom0 kernel makes sense. I'd not be surprised if the same turns out to be true for x86/PVH guests too. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] Emulation issues
> -Original Message- > From: Sander Eikelenboom [mailto:li...@eikelenboom.it] > Sent: 31 July 2015 12:12 > To: Paul Durrant > Cc: Andrew Cooper; Roger Pau Monne; xen-devel > Subject: Re: [Xen-devel] [BUG] Emulation issues > > > Friday, July 31, 2015, 12:22:16 PM, you wrote: > > >> -Original Message- > >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > >> boun...@lists.xen.org] On Behalf Of Paul Durrant > >> Sent: 30 July 2015 14:20 > >> To: Andrew Cooper; Roger Pau Monne; xen-devel > >> Subject: Re: [Xen-devel] [BUG] Emulation issues > >> > >> > -Original Message- > >> > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > >> > Sent: 30 July 2015 14:19 > >> > To: Paul Durrant; Roger Pau Monne; xen-devel > >> > Subject: Re: [BUG] Emulation issues > >> > > >> > On 30/07/15 14:12, Paul Durrant wrote: > >> > >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > >> > >> (XEN) domain_crash called from io.c:166 > >> > >> (XEN) d19v0 weird emulation state 1 > >> > >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > >> > >> (XEN) domain_crash called from io.c:166 > >> > >> (XEN) d19v0 weird emulation state 1 > >> > >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > >> > >> (XEN) domain_crash called from io.c:166 > >> > >> > >> > > Hmm. Can't understand how that's happening... handle_pio() > shouldn't > >> be > >> > called unless the state is STATE_IORESP_READY and yet the inner > function > >> is > >> > hitting the default case in the switch. > >> > > >> > Sounds like something is changing the state between the two checks. Is > >> > this shared memory writeable by qemu? > >> > > >> > >> No, this is the internal state. I really can't see how it's being changed. > >> > > > I've tried to replicate your test on my rig (which is an old AMD box but > > quite > a big one). Even so I only seem to get about half the VMs to start. The > shutdown works fine, and I don't see any problems on the Xen console. I'm > using an older build of Xen but still one with my series in. I'll try pulling > up to > the same commit as you and try again. > > > Paul > > Hi Paul, > > From what i recall it started around when Tiejun Chen's series went in. > Interesting. Paul ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] Emulation issues
El 31/07/15 a les 13.11, Sander Eikelenboom ha escrit: > > Friday, July 31, 2015, 12:22:16 PM, you wrote: > >>> -Original Message- >>> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- >>> boun...@lists.xen.org] On Behalf Of Paul Durrant >>> Sent: 30 July 2015 14:20 >>> To: Andrew Cooper; Roger Pau Monne; xen-devel >>> Subject: Re: [Xen-devel] [BUG] Emulation issues >>> -Original Message- From: Andrew Cooper [mailto:andrew.coop...@citrix.com] Sent: 30 July 2015 14:19 To: Paul Durrant; Roger Pau Monne; xen-devel Subject: Re: [BUG] Emulation issues On 30/07/15 14:12, Paul Durrant wrote: >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >> (XEN) domain_crash called from io.c:166 >> (XEN) d19v0 weird emulation state 1 >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >> (XEN) domain_crash called from io.c:166 >> (XEN) d19v0 weird emulation state 1 >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >> (XEN) domain_crash called from io.c:166 >> > Hmm. Can't understand how that's happening... handle_pio() shouldn't >>> be called unless the state is STATE_IORESP_READY and yet the inner function >>> is hitting the default case in the switch. Sounds like something is changing the state between the two checks. Is this shared memory writeable by qemu? >>> >>> No, this is the internal state. I really can't see how it's being changed. >>> > >> I've tried to replicate your test on my rig (which is an old AMD box but >> quite a big one). Even so I only seem to get about half the VMs to start. >> The shutdown works fine, and I don't see any problems on the Xen console. >> I'm using an older build of Xen but still one with my series in. I'll try >> pulling up to the same commit as you and try again. > >> Paul > > Hi Paul, > >>From what i recall it started around when Tiejun Chen's series went in. FWIW I've seen this on an Intel box with a Xeon W3550. I have not tried to reproduce it on any of my other boxes, but I could give it a try if needed. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] VM Migration on a NUMA server?
Let me be more specific, such idea is for the NUMA scheduling as currently xen only migrate vcpus but leave memory at the previous node. Kun Cheng 于2015年7月31日 周五10:32写道： > Hi all, > > I'm sorry for taking your time and I'd like to make an enquery about the > status of VM migration support on a NUMA server. Currently It looks like > when a vm is migrated only its vcpus are moved to the other node but not > its memory. So, is anyone trying to fix that issue? If I want to do it > myself, it seems like two major problems are ahead of me: > > 1) How to specify the target node for memory migration? I'll be grateful > if anyone can give me some hints. > > 2) Memory Migration. Looks like it can be done by leveraging the existing > migration related functions on Xen. > > I don't have much practical experience on NUMA machines. And I'll be > appreciated for any reply & help. > > Thanks, > Kenneth > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] Emulation issues
El 31/07/15 a les 13.39, Paul Durrant ha escrit: >> -Original Message- >> From: Sander Eikelenboom [mailto:li...@eikelenboom.it] >> Sent: 31 July 2015 12:12 >> To: Paul Durrant >> Cc: Andrew Cooper; Roger Pau Monne; xen-devel >> Subject: Re: [Xen-devel] [BUG] Emulation issues >> >> >> Friday, July 31, 2015, 12:22:16 PM, you wrote: >> -Original Message- From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- boun...@lists.xen.org] On Behalf Of Paul Durrant Sent: 30 July 2015 14:20 To: Andrew Cooper; Roger Pau Monne; xen-devel Subject: Re: [Xen-devel] [BUG] Emulation issues > -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 30 July 2015 14:19 > To: Paul Durrant; Roger Pau Monne; xen-devel > Subject: Re: [BUG] Emulation issues > > On 30/07/15 14:12, Paul Durrant wrote: >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >>> (XEN) domain_crash called from io.c:166 >>> (XEN) d19v0 weird emulation state 1 >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >>> (XEN) domain_crash called from io.c:166 >>> (XEN) d19v0 weird emulation state 1 >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >>> (XEN) domain_crash called from io.c:166 >>> >> Hmm. Can't understand how that's happening... handle_pio() >> shouldn't be > called unless the state is STATE_IORESP_READY and yet the inner >> function is > hitting the default case in the switch. > > Sounds like something is changing the state between the two checks. Is > this shared memory writeable by qemu? > No, this is the internal state. I really can't see how it's being changed. >> >>> I've tried to replicate your test on my rig (which is an old AMD box but >>> quite >> a big one). Even so I only seem to get about half the VMs to start. The >> shutdown works fine, and I don't see any problems on the Xen console. I'm >> using an older build of Xen but still one with my series in. I'll try >> pulling up to >> the same commit as you and try again. >> >>> Paul >> >> Hi Paul, >> >> From what i recall it started around when Tiejun Chen's series went in. >> Since I can reproduce this at will I will attempt to perform a bisection. Maybe this can help narrow down the issue. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1] arm: reduce power use by contented spin locks with WFE/SEV
On Fri, 31 Jul 2015, Julien Grall wrote:
> Hi David,
>
> On 31/07/15 11:52, David Vrabel wrote:
> > On 31/07/15 11:45, David Vrabel wrote:
> >> Instead of cpu_relax() while spinning and observing the ticket head,
> >> introduce spin_relax() which executes a WFE instruction. After the
> >> ticket head is changed call spin_signal() to execute an SVE
> >> instruction to wake any spinners.
> >>
> >> This should improve power consumption when locks are contented and
> >> spinning.
> >>
> >> Signed-off-by: David Vrabel
> >> ---
> >> I've not tested this but it looks straight-forward...
> >> ---
> >> xen/common/spinlock.c | 5 +++--
> >> xen/include/asm-arm/spinlock.h | 3 ++-
> >> xen/include/asm-x86/spinlock.h | 3 +++
> >> 3 files changed, 8 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
> >> index 29149d1..fc3e8e7 100644
> >> --- a/xen/common/spinlock.c
> >> +++ b/xen/common/spinlock.c
> >> @@ -141,7 +141,7 @@ void _spin_lock(spinlock_t *lock)
> >> while ( tickets.tail != observe_head(&lock->tickets) )
> >> {
> >> LOCK_PROFILE_BLOCK;
> >> -cpu_relax();
> >> +spin_relax();
> >> }
> >> LOCK_PROFILE_GOT;
> >> preempt_disable();
> >> @@ -170,6 +170,7 @@ void _spin_unlock(spinlock_t *lock)
> >> preempt_enable();
> >> LOCK_PROFILE_REL;
> >> add_sized(&lock->tickets.head, 1);
> >> +spin_signal();
> >
> > It occurs to me that perhaps there should be a barrier between the
> > add_sized() and the spin_signal() so the update value is visible before
> > we signal (otherwise the spinner may be woken and observe the old value
> > and WFE again).
>
> sev is usually precede by dsb to ensure that all the instructions before
> as completed before executing the sev.
Yes, a dsb() is required. This being common code, we could use wmb().
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] Emulation issues
> -Original Message- > From: Roger Pau Monné [mailto:roger@citrix.com] > Sent: 31 July 2015 12:42 > To: Paul Durrant; Sander Eikelenboom > Cc: Andrew Cooper; xen-devel > Subject: Re: [Xen-devel] [BUG] Emulation issues > > El 31/07/15 a les 13.39, Paul Durrant ha escrit: > >> -Original Message- > >> From: Sander Eikelenboom [mailto:li...@eikelenboom.it] > >> Sent: 31 July 2015 12:12 > >> To: Paul Durrant > >> Cc: Andrew Cooper; Roger Pau Monne; xen-devel > >> Subject: Re: [Xen-devel] [BUG] Emulation issues > >> > >> > >> Friday, July 31, 2015, 12:22:16 PM, you wrote: > >> > -Original Message- > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > boun...@lists.xen.org] On Behalf Of Paul Durrant > Sent: 30 July 2015 14:20 > To: Andrew Cooper; Roger Pau Monne; xen-devel > Subject: Re: [Xen-devel] [BUG] Emulation issues > > > -Original Message- > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > > Sent: 30 July 2015 14:19 > > To: Paul Durrant; Roger Pau Monne; xen-devel > > Subject: Re: [BUG] Emulation issues > > > > On 30/07/15 14:12, Paul Durrant wrote: > >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > >>> (XEN) domain_crash called from io.c:166 > >>> (XEN) d19v0 weird emulation state 1 > >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > >>> (XEN) domain_crash called from io.c:166 > >>> (XEN) d19v0 weird emulation state 1 > >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > >>> (XEN) domain_crash called from io.c:166 > >>> > >> Hmm. Can't understand how that's happening... handle_pio() > >> shouldn't > be > > called unless the state is STATE_IORESP_READY and yet the inner > >> function > is > > hitting the default case in the switch. > > > > Sounds like something is changing the state between the two checks. > Is > > this shared memory writeable by qemu? > > > > No, this is the internal state. I really can't see how it's being > changed. > > >> > >>> I've tried to replicate your test on my rig (which is an old AMD box but > quite > >> a big one). Even so I only seem to get about half the VMs to start. The > >> shutdown works fine, and I don't see any problems on the Xen console. > I'm > >> using an older build of Xen but still one with my series in. I'll try > >> pulling up > to > >> the same commit as you and try again. > >> > >>> Paul > >> > >> Hi Paul, > >> > >> From what i recall it started around when Tiejun Chen's series went in. > >> > > Since I can reproduce this at will I will attempt to perform a > bisection. Maybe this can help narrow down the issue. > Thanks. That would be very helpful. I will continue to try to repro. Paul > Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] VM Migration on a NUMA server?
On Fri, Jul 31, 2015 at 11:41:11AM +, Kun Cheng wrote: > Let me be more specific, such idea is for the NUMA scheduling as currently > xen only migrate vcpus but leave memory at the previous node. > Xen doesn't support memory migration at the moment. However Xen scheduler won't migrate vcpus out of its NUMA node in most cases. I will let Dario (CC'ed) confirm. He might also able to give you pointers if you want to work on such feature. Wei. > Kun Cheng 于2015年7月31日 周五10:32写道： > > > Hi all, > > > > I'm sorry for taking your time and I'd like to make an enquery about the > > status of VM migration support on a NUMA server. Currently It looks like > > when a vm is migrated only its vcpus are moved to the other node but not > > its memory. So, is anyone trying to fix that issue? If I want to do it > > myself, it seems like two major problems are ahead of me: > > > > 1) How to specify the target node for memory migration? I'll be grateful > > if anyone can give me some hints. > > > > 2) Memory Migration. Looks like it can be done by leveraging the existing > > migration related functions on Xen. > > > > I don't have much practical experience on NUMA machines. And I'll be > > appreciated for any reply & help. > > > > Thanks, > > Kenneth > > > ___ > 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] [BUG] Emulation issues
> -Original Message- > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > boun...@lists.xen.org] On Behalf Of Paul Durrant > Sent: 31 July 2015 12:43 > To: Roger Pau Monne; Sander Eikelenboom > Cc: Andrew Cooper; xen-devel > Subject: Re: [Xen-devel] [BUG] Emulation issues > > > -Original Message- > > From: Roger Pau Monné [mailto:roger@citrix.com] > > Sent: 31 July 2015 12:42 > > To: Paul Durrant; Sander Eikelenboom > > Cc: Andrew Cooper; xen-devel > > Subject: Re: [Xen-devel] [BUG] Emulation issues > > > > El 31/07/15 a les 13.39, Paul Durrant ha escrit: > > >> -Original Message- > > >> From: Sander Eikelenboom [mailto:li...@eikelenboom.it] > > >> Sent: 31 July 2015 12:12 > > >> To: Paul Durrant > > >> Cc: Andrew Cooper; Roger Pau Monne; xen-devel > > >> Subject: Re: [Xen-devel] [BUG] Emulation issues > > >> > > >> > > >> Friday, July 31, 2015, 12:22:16 PM, you wrote: > > >> > > -Original Message- > > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > > boun...@lists.xen.org] On Behalf Of Paul Durrant > > Sent: 30 July 2015 14:20 > > To: Andrew Cooper; Roger Pau Monne; xen-devel > > Subject: Re: [Xen-devel] [BUG] Emulation issues > > > > > -Original Message- > > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > > > Sent: 30 July 2015 14:19 > > > To: Paul Durrant; Roger Pau Monne; xen-devel > > > Subject: Re: [BUG] Emulation issues > > > > > > On 30/07/15 14:12, Paul Durrant wrote: > > >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > > >>> (XEN) domain_crash called from io.c:166 > > >>> (XEN) d19v0 weird emulation state 1 > > >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > > >>> (XEN) domain_crash called from io.c:166 > > >>> (XEN) d19v0 weird emulation state 1 > > >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > > >>> (XEN) domain_crash called from io.c:166 > > >>> > > >> Hmm. Can't understand how that's happening... handle_pio() > > >> shouldn't > > be > > > called unless the state is STATE_IORESP_READY and yet the inner > > >> function > > is > > > hitting the default case in the switch. > > > > > > Sounds like something is changing the state between the two > checks. > > Is > > > this shared memory writeable by qemu? > > > > > > > No, this is the internal state. I really can't see how it's being > > changed. > > > > >> > > >>> I've tried to replicate your test on my rig (which is an old AMD box but > > quite > > >> a big one). Even so I only seem to get about half the VMs to start. The > > >> shutdown works fine, and I don't see any problems on the Xen console. > > I'm > > >> using an older build of Xen but still one with my series in. I'll try > > >> pulling > up > > to > > >> the same commit as you and try again. > > >> > > >>> Paul > > >> > > >> Hi Paul, > > >> > > >> From what i recall it started around when Tiejun Chen's series went in. > > >> > > > > Since I can reproduce this at will I will attempt to perform a > > bisection. Maybe this can help narrow down the issue. > > > > Thanks. That would be very helpful. I will continue to try to repro. > Still no luck with the repro but I think I might my thought experiments might have got it... If a vcpu has a request in-flight then its internal ioreq state will be IOREQ_READY and it will be waiting for wake-up. When it is woken up hvm_do_resume() will be called and it will call hvm_wait_for_io(). If the shared (with QEMU) ioreq state is still IOREQ_READY or IOREQ_INPROCESS then the vcpu will block again. If the shared state is IORESP_READY then the emulation is done and the internal state will be updated to IORESP_READY or IOREQ_NONE by hvm_io_assist() depending upon whether any completion is needed or not. *However* if the emulator (or Xen) happens to zero out the shared ioreq state before hvm_wait_for_io() is called then it will see a shared state of IOREQ_NONE so it will terminate without calling hvm_io_assist() leaving the internal ioreq state as IOREQ_READY which will then cause the domain_crash() you're seeing when re-emulation is attempted by a completion handler. So, there is an underlying problem in that a dying emulator can leave an I/O uncompleted but the code in Xen needs to cope more gracefully with that (since the vcpu will be going away anyway) and not call domain_crash(). Paul > Paul > > > Roger. > > > ___ > 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] [PATCHv1] arm: reduce power use by contented spin locks with WFE/SEV
On Fri, 2015-07-31 at 12:41 +0100, Stefano Stabellini wrote:
> On Fri, 31 Jul 2015, Julien Grall wrote:
> > Hi David,
> >
> > On 31/07/15 11:52, David Vrabel wrote:
> > > On 31/07/15 11:45, David Vrabel wrote:
> > > > Instead of cpu_relax() while spinning and observing the ticket
> > > > head,
> > > > introduce spin_relax() which executes a WFE instruction. After the
> > > > ticket head is changed call spin_signal() to execute an SVE
> > > > instruction to wake any spinners.
> > > >
> > > > This should improve power consumption when locks are contented and
> > > > spinning.
> > > >
> > > > Signed-off-by: David Vrabel
> > > > ---
> > > > I've not tested this but it looks straight-forward...
> > > > ---
> > > > xen/common/spinlock.c | 5 +++--
> > > > xen/include/asm-arm/spinlock.h | 3 ++-
> > > > xen/include/asm-x86/spinlock.h | 3 +++
> > > > 3 files changed, 8 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
> > > > index 29149d1..fc3e8e7 100644
> > > > --- a/xen/common/spinlock.c
> > > > +++ b/xen/common/spinlock.c
> > > > @@ -141,7 +141,7 @@ void _spin_lock(spinlock_t *lock)
> > > > while ( tickets.tail != observe_head(&lock->tickets) )
> > > > {
> > > > LOCK_PROFILE_BLOCK;
> > > > -cpu_relax();
> > > > +spin_relax();
> > > > }
> > > > LOCK_PROFILE_GOT;
> > > > preempt_disable();
> > > > @@ -170,6 +170,7 @@ void _spin_unlock(spinlock_t *lock)
> > > > preempt_enable();
> > > > LOCK_PROFILE_REL;
> > > > add_sized(&lock->tickets.head, 1);
> > > > +spin_signal();
> > >
> > > It occurs to me that perhaps there should be a barrier between the
> > > add_sized() and the spin_signal() so the update value is visible
> > > before
> > > we signal (otherwise the spinner may be woken and observe the old
> > > value
> > > and WFE again).
> >
> > sev is usually precede by dsb to ensure that all the instructions
> > before
> > as completed before executing the sev.
>
> Yes, a dsb() is required. This being common code, we could use wmb().
IMHO it should be in spin_{relax,signal} if it is needed.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 32/41] arm : acpi dynamically map mmio regions
Hi Shannon, On 31/07/15 02:30, Shannon Zhao wrote: > > > On 2015/7/31 2:31, Julien Grall wrote: >> On 30/07/15 19:02, Parth Dixit wrote: >>> instead of getting mmio information for individual >>> devices from dsdt, we will map all the non-ram regions described in >>> uefi. AML interpreter option was discussed earlier and it was decided >>> not to go with that approach. You can find more details in the linaro >>> xen wiki for the reasoning behind it. >> >> Which page are you talking about? I only found [1] speaking about ACPI. >> Although, there is nothing related to MMIO mapping. >> >> Anyway, it's not possible to get the list of MMIOs regions for the UEFI >> System Memory Map (see the mail you forward on the ML [2]). >> >> Although, based on the RAM region we could deduce a possible set of MMIO >> regions. > But I guess this will get the all regions except RAM region. And some of > the regions may not exist on hardware. Is it ok to map the non-exist > region to DOM0? Doesn't the map function fail? I don't see a problem for it. I'm not sure what the others think about it. The map function doesn't know if the physical region is valid or not. It's only setup the page table to allow the guest using the physical region. If DOM0 is trying to access invalid region, it will receive a data/prefetch abort. > >> It would be fine to mapped unused region in memory and we could >> take advantage of super page. >> >> While you are speaking about the wiki page. Can one of you update the >> wiki page about the boot protocol? Jan had some concerns about the >> solution you choose (see [3] to not mention the whole thread). >> > > About the XENV table, from the discussions of the thread, it seems we > reach an agreement on using hypercall to tell DOM0 the grant table info > and event channel irq. Right? People have different opinion on what should be the way to boot DOM0 with ACPI on ARM. A design document would help here to understand what are the possibilities to boot DOM0 (i.e hypercall based, XENV...) and which one would be the most suitable for ARM. > >> We need to agree on the boot protocol before going further on this series. >> >> To speed up the upstreaming process, it would be nice if you start a >> thread about the boot protocol for ACPI with relevant people in CCed. >> The main goal will be to explain why you choose this way. This will be >> the base to talk about improvement and/or answer concerns for other people. >> > > Ok, it's good to reach an agreement before action. > >> FWIW, Jan also suggested a different boot protocol based on the x86 one. >> It may be good for you to see whether it would fit ACPI on ARM. >> > > Which boot protocol? Could you point it out? Thanks. :) The way to boot DOM0 with ACPI. There is a page on the Linaro wiki [1], but the content is quite out of date now. Regards, [1] https://wiki.linaro.org/LEG/Engineering/Virtualization/ACPI_on_Xen -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1] arm: reduce power use by contented spin locks with WFE/SEV
On 31/07/15 12:41, Stefano Stabellini wrote:
> On Fri, 31 Jul 2015, Julien Grall wrote:
>> Hi David,
>>
>> On 31/07/15 11:52, David Vrabel wrote:
>>> On 31/07/15 11:45, David Vrabel wrote:
Instead of cpu_relax() while spinning and observing the ticket head,
introduce spin_relax() which executes a WFE instruction. After the
ticket head is changed call spin_signal() to execute an SVE
instruction to wake any spinners.
This should improve power consumption when locks are contented and
spinning.
Signed-off-by: David Vrabel
---
I've not tested this but it looks straight-forward...
---
xen/common/spinlock.c | 5 +++--
xen/include/asm-arm/spinlock.h | 3 ++-
xen/include/asm-x86/spinlock.h | 3 +++
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 29149d1..fc3e8e7 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -141,7 +141,7 @@ void _spin_lock(spinlock_t *lock)
while ( tickets.tail != observe_head(&lock->tickets) )
{
LOCK_PROFILE_BLOCK;
-cpu_relax();
+spin_relax();
}
LOCK_PROFILE_GOT;
preempt_disable();
@@ -170,6 +170,7 @@ void _spin_unlock(spinlock_t *lock)
preempt_enable();
LOCK_PROFILE_REL;
add_sized(&lock->tickets.head, 1);
+spin_signal();
>>>
>>> It occurs to me that perhaps there should be a barrier between the
>>> add_sized() and the spin_signal() so the update value is visible before
>>> we signal (otherwise the spinner may be woken and observe the old value
>>> and WFE again).
>>
>> sev is usually precede by dsb to ensure that all the instructions before
>> as completed before executing the sev.
>
> Yes, a dsb() is required. This being common code, we could use wmb().
You should put the barrier required for the SEV in spin_signal() so an
additional barrier is not required on other archs.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] VM Migration on a NUMA server?
On Fri, 2015-07-31 at 02:32 +, Kun Cheng wrote: > Hi all, > Hi, > > I'm sorry for taking your time and I'd like to make an enquery about > the status of VM migration support on a NUMA server. > Status is: it's not there, and won't happen soon. I've started working on it, but then got preempted by other issues, and concentrated on making Xen do the best possible _without_ moving the memory (e.g., with NUMA-aware scheduling, now achieved through per-vcpu soft affinities). Moving memory around is really really tricky. It's probably at least doable for HVM guests, while, for PV, I'm not even so sure it can be done! :-/ > Currently It looks like when a vm is migrated only its vcpus are moved > to the other node but not its memory. So, is anyone trying to fix that > issue? > What do you mean with "when a vm is migrated"? If soft affinity for a VM is specified in the config file (or afterwards, but I'd recommend to do it in the config file, if you're interested in NUMA effects), memory is allocated from the NUMA node that such affinity spans, and the Xen scheduler (provided you're using Credit1, our default scheduler), will try as hard as it can to schedule the vcpus of the vm on the pcpus of that same node (or set of nodes). If it's not possible, because all those pcpus are busy, the vcpus are allowed to run on some other pcpu, outside of the NUMA node(s) the vm has affinity with, on the basis that some execution, even with slow memory access, is better than no execution at all. If you're interested in having the vcpus of the vm _only_ running on the pcpus of the node to which the memory is attached, I'd suggest using hard affinity, instead than soft (still specifying it in the config file). Support for soft affinity in Credit2 is being worked on. For other schedulers (ARINC and RTDS), it's not that useful. > If I want to do it myself, it seems like two major problems are ahead > of me: > > 1) How to specify the target node for memory migration? I'll be > grateful if anyone can give me some hints. > Not sure I get. In my mind, if we will have this in place at some point, migration will happen, either: - automatically, upon load balancing considerations - manually, with dedicated libxl interfaces and xl command at that point, for the latter case, there will be a way of specifying a target node, and that will most likely be an integer, or a list of integers... > 2) Memory Migration. Looks like it can be done by leveraging the > existing migration related functions on Xen. > Mmmm... Maybe I see what you mean now. So, you want to perform a local migration, and use that as a way of actually moving the guest to another node, is this correct? If yes, it did work, last time I checked. If doing this like that, it's true that you don't have any way for specifying a target node. Therefore, what happens is, either: - if no soft or hard affinity is specified in the config file, the automatic NUMA placement code will run, and it most likely will choose a different node for the target vm, but not in a way that you can control easily - if any affinity is set, the vm will be re-created in the same exact node. That is why, a way to workaround this, and actually use local migration as a memory-migration mechanism, is to leverage `xl config-update'. In fact, you can do as follows: # xl create vm.cfg 'cpus_soft="node:1'" # xl config-update 'cpus_soft="node:0"' # As I said, this all worked last time I tried... Is it not working for you? Or was it something else you were after? Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] VM Migration on a NUMA server?
On Fri, 2015-07-31 at 13:10 +0100, Wei Liu wrote: > On Fri, Jul 31, 2015 at 11:41:11AM +, Kun Cheng wrote: > > Let me be more specific, such idea is for the NUMA scheduling as currently > > xen only migrate vcpus but leave memory at the previous node. > > > > Xen doesn't support memory migration at the moment. However Xen scheduler > won't migrate vcpus out of its NUMA node in most cases. > Yes, as I said in my email, if soft affinity is used (and that's the default, if anything contradicting that is specified in the confing file) the vcpus are allowed to run outside of the NUMA node where the memory has been allocated, but they'll try not to do so. > I will let Dario (CC'ed) confirm. He might also able to give you > pointers if you want to work on such feature. > Thanks for the ping on this! :-) Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On 31/07/15 4:49 pm, Ian Campbell wrote: On Fri, 2015-07-31 at 16:37 +0530, Manish Jaggi wrote: On Friday 31 July 2015 01:35 PM, Ian Campbell wrote: On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote: Secondly, the vdev-X entry is created async by dom0 watching on event. So how the tools could read back and call assign device again. Perhaps by using a xenstore watch on that node to wait for the assignment from pciback to occur. As per the flow in the do_pci_add function, assign_device is called first and based on the success xenstore entry is created. Are you suggesting to change the sequence. Perhaps that is what it would take, yes, or maybe some other refactoring (e.g. splitting assign_device into two stages) might be the answer. The hypercall from xenpciback (what I implemented) is actually making the assign device in 2 stages. I think the point of contention is the second stage should be from toolstack. I think calling xc_assign_device after xenstore from the watch callback is the only option. Only if you ignore the other option I proposed. One question is how to split the code for ARM and x86 as this is the common code. Would #ifdef CONFIG_ARM64 ok with maintainers. No. arch hooks in libxl_$ARCH.c (with nop implementations where necessary) would be the way to approach this. However I still am not convinced this is the approach we should be taking. My current preference is for the suggestion below which is to let the toolstack pick the vdevfn and have pciback honour it. That would duplicate code for dev-fn generation into toolstack from __xen_pcibk_add_pci_dev. IMHO the toolstack is the correct place for this code, at least for ARM guests. The toolstack is, in general, responsible for all aspects of the guest layout. I don't think delegating the PCI bus parts of that to the dom0 kernel makes sense. Ok, i will implement the same from pciback to toolstack. I am not sure about the complexity but will give it a try. With this xen-pciback will not create the vdev-X entry at all. I'd not be surprised if the same turns out to be true for x86/PVH guests too. Ian. ___ 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] PCI Pass-through in Xen ARM - Draft 2.
On Fri, 2015-07-31 at 18:20 +0530, Manish Jaggi wrote: > > On 31/07/15 4:49 pm, Ian Campbell wrote: > > On Fri, 2015-07-31 at 16:37 +0530, Manish Jaggi wrote: > > > On Friday 31 July 2015 01:35 PM, Ian Campbell wrote: > > > > On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote: > > > > > > > Secondly, the vdev-X entry is created async by dom0 watching > > > > > > > on > > > > > > > event. > > > > > > > So how the tools could read back and call assign device > > > > > > > again. > > > > > > Perhaps by using a xenstore watch on that node to wait for the > > > > > > assignment > > > > > > from pciback to occur. > > > > > As per the flow in the do_pci_add function, assign_device is > > > > > called > > > > > first and based on the success xenstore entry is created. > > > > > Are you suggesting to change the sequence. > > > > Perhaps that is what it would take, yes, or maybe some other > > > > refactoring > > > > (e.g. splitting assign_device into two stages) might be the answer. > > > The hypercall from xenpciback (what I implemented) is actually making > > > the assign device in 2 stages. > > > I think the point of contention is the second stage should be from > > > toolstack. > > > > > > I think calling xc_assign_device after xenstore from the watch > > > callback > > > is the only option. > > Only if you ignore the other option I proposed. > > > > > One question is how to split the code for ARM and x86 as this is the > > > common code. > > > Would #ifdef CONFIG_ARM64 ok with maintainers. > > No. arch hooks in libxl_$ARCH.c (with nop implementations where > > necessary) > > would be the way to approach this. However I still am not convinced > > this is > > the approach we should be taking. > > > > > > My current preference is for the suggestion below which is to let > > > > the > > > > toolstack pick the vdevfn and have pciback honour it. > > > That would duplicate code for dev-fn generation into toolstack from > > > __xen_pcibk_add_pci_dev. > > IMHO the toolstack is the correct place for this code, at least for ARM > > guests. The toolstack is, in general, responsible for all aspects of > > the > > guest layout. I don't think delegating the PCI bus parts of that to the > > dom0 kernel makes sense. > Ok, i will implement the same from pciback to toolstack. I am not sure > about the complexity but will give it a try. Thank you. > With this xen-pciback will not create the vdev-X entry at all. Uh, where did you get that idea? That node communicates from b.e. to f.e., surely it is still needed for that purpose? The flow seems like it should be: toolstack -> xenstore:vdevfn-X -> backend -> xenstore:vdev-X -> frontend where "backend" is codei n pciback which does something like (maybe not in one function, but logically): foo = read(vdevfn-X) if (!foo) allocate SBDF as code today, setting foo to the result write(vdev-X, foo) IOW if vdevfn-X is unset the backend does the same as today, if it is set (by the toolstack) then pciback honours it. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
Hi Manish, On 31/07/15 13:50, Manish Jaggi wrote: > Ok, i will implement the same from pciback to toolstack. I am not sure > about the complexity but will give it a try. > With this xen-pciback will not create the vdev-X entry at all. Can you send a new draft before continuing to implement PCI support in Xen? As long as we are not agree about it, you loose your time trying to implement something that can drastically change in the next revision. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Fri, 2015-07-31 at 13:59 +0100, Julien Grall wrote: > Hi Manish, > > On 31/07/15 13:50, Manish Jaggi wrote: > > Ok, i will implement the same from pciback to toolstack. I am not sure > > about the complexity but will give it a try. > > With this xen-pciback will not create the vdev-X entry at all. > > Can you send a new draft before continuing to implement PCI support in > Xen? > > As long as we are not agree about it, you loose your time trying to > implement something that can drastically change in the next revision. Very good idea, yes. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 60154: tolerable FAIL - PUSHED
flight 60154 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/60154/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 59817 test-armhf-armhf-xl-qcow2 5 xen-install fail baseline untested test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 59817 test-armhf-armhf-xl-rtds 11 guest-start fail like 59817 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59817 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59817 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 12 guest-localmigrate fail like 59904-bisect Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-xl-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass version targeted for testing: xen 598fbeb9c1bd7b32a3c435913a382911cd68319b baseline version: xen 7c60c2da3160766a265cb84c7411ff2c9cbd8d0b Last test of basis59817 2015-07-22 07:29:29 Z9 days Failing since 59833 2015-07-23 10:56:30 Z8 days6 attempts Testing same since60154 2015-07-30 18:41:04 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Andrew Cooper for the x86 bits. Chao Peng Chris (Christopher) Brand Chris Brand Daniel De Graaf Dario Faggioli Ed White George Dunlap Ian Campbell Ian Jackson Jan Beulich Jonathan Creekmore Juergen Gross Julien Grall Jun Nakajima Kevin Tian Martin Lucina Ravi Sahita Roger Pau Monné Tamas K Lengyel Tiejun Chen Ting-Wei Lan Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen
[Xen-devel] [PATCH v2] xen/events/fifo: Handle linked events when closing a port
When a channel is closed and the event is still linked into a queue,
ensure that it is unlinked before completing. If it is not unlinked and
the port is subsequently reused, events may be missed.
If the CPU to which the event channel bound is online, spin until the
event is handled by that CPU. If that CPU is offline, it can't handle
the event, so clear the event queue during the close, dropping the
events.
This fixes missing interrupts (and subsequent disk stalls) when
offlining a CPU.
Signed-off-by: Ross Lagerwall
---
drivers/xen/events/events_base.c | 10
drivers/xen/events/events_fifo.c | 45
drivers/xen/events/events_internal.h | 7 ++
3 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 96093ae..1495ecc 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -452,10 +452,12 @@ static void xen_free_irq(unsigned irq)
irq_free_desc(irq);
}
-static void xen_evtchn_close(unsigned int port)
+static void xen_evtchn_close(unsigned int port, unsigned int cpu)
{
struct evtchn_close close;
+ xen_evtchn_op_close(port, cpu);
+
close.port = port;
if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
BUG();
@@ -544,7 +546,7 @@ out:
err:
pr_err("irq%d: Failed to set port to irq mapping (%d)\n", irq, rc);
- xen_evtchn_close(evtchn);
+ xen_evtchn_close(evtchn, NR_CPUS);
return 0;
}
@@ -565,7 +567,7 @@ static void shutdown_pirq(struct irq_data *data)
return;
mask_evtchn(evtchn);
- xen_evtchn_close(evtchn);
+ xen_evtchn_close(evtchn, cpu_from_evtchn(evtchn));
xen_irq_info_cleanup(info);
}
@@ -609,7 +611,7 @@ static void __unbind_from_irq(unsigned int irq)
if (VALID_EVTCHN(evtchn)) {
unsigned int cpu = cpu_from_irq(irq);
- xen_evtchn_close(evtchn);
+ xen_evtchn_close(evtchn, cpu);
switch (type_from_irq(irq)) {
case IRQT_VIRQ:
diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index ed673e1..6df8aac 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -255,6 +255,12 @@ static void evtchn_fifo_unmask(unsigned port)
}
}
+static bool evtchn_fifo_is_linked(unsigned port)
+{
+ event_word_t *word = event_word_from_port(port);
+ return sync_test_bit(EVTCHN_FIFO_BIT(LINKED, word), BM(word));
+}
+
static uint32_t clear_linked(volatile event_word_t *word)
{
event_word_t new, old, w;
@@ -281,7 +287,8 @@ static void handle_irq_for_port(unsigned port)
static void consume_one_event(unsigned cpu,
struct evtchn_fifo_control_block *control_block,
- unsigned priority, unsigned long *ready)
+ unsigned priority, unsigned long *ready,
+ bool drop)
{
struct evtchn_fifo_queue *q = &per_cpu(cpu_queue, cpu);
uint32_t head;
@@ -313,13 +320,15 @@ static void consume_one_event(unsigned cpu,
if (head == 0)
clear_bit(priority, ready);
- if (evtchn_fifo_is_pending(port) && !evtchn_fifo_is_masked(port))
- handle_irq_for_port(port);
+ if (evtchn_fifo_is_pending(port) && !evtchn_fifo_is_masked(port)) {
+ if (likely(!drop))
+ handle_irq_for_port(port);
+ }
q->head[priority] = head;
}
-static void evtchn_fifo_handle_events(unsigned cpu)
+static void __evtchn_fifo_handle_events(unsigned cpu, bool drop)
{
struct evtchn_fifo_control_block *control_block;
unsigned long ready;
@@ -331,11 +340,16 @@ static void evtchn_fifo_handle_events(unsigned cpu)
while (ready) {
q = find_first_bit(&ready, EVTCHN_FIFO_MAX_QUEUES);
- consume_one_event(cpu, control_block, q, &ready);
+ consume_one_event(cpu, control_block, q, &ready, drop);
ready |= xchg(&control_block->ready, 0);
}
}
+static void evtchn_fifo_handle_events(unsigned cpu)
+{
+ __evtchn_fifo_handle_events(cpu, false);
+}
+
static void evtchn_fifo_resume(void)
{
unsigned cpu;
@@ -371,6 +385,26 @@ static void evtchn_fifo_resume(void)
event_array_pages = 0;
}
+static void evtchn_fifo_close(unsigned port, unsigned int cpu)
+{
+ if (cpu == NR_CPUS)
+ return;
+
+ get_online_cpus();
+ if (cpu_online(cpu)) {
+ if (WARN_ON(irqs_disabled()))
+ goto out;
+
+ while (evtchn_fifo_is_linked(port))
+ cpu_relax();
+ } else {
+ __evtchn_fifo_handle_events(cpu, true);
+ }
+
+out:
+ put_online_cpus();
+}
+
static const struct evtchn_
Re: [Xen-devel] [PATCH v5 0/4] x86: modify_ldt improvement, test, and config option
On 07/31/2015 04:43 AM, Borislav Petkov wrote: Hey Boris, On Thu, Jul 30, 2015 at 01:18:20PM -0400, Boris Ostrovsky wrote: Only V5, no extra changes. Including running the ldt_gdt test? Yes, except that 32-on-64 doesn't work, but that's not Xen-specific. so which tests are you running exactly and where can I get them? Andy's repo? tools/testing/selftests/x86/ldt_gdt.c, which is patch 3/4 in Andy's series. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
On 07/31/2015 05:10 AM, Andrew Cooper wrote: On 30/07/15 22:31, Andy Lutomirski wrote: This is intended for x86/urgent. Sorry for taking so long, but it seemed nice to avoid breaking Xen. Very much appreciated. Thanks! This fixes the "dazed and confused" issue which was exposed by the CVE-2015-5157 fix. It's also probably a good general attack surface reduction, and it replaces some scary code with IMO less scary code. Also, servers and embedded systems should probably turn off modify_ldt. This makes that possible. Xen people, can you test patch 1? It works for me on my evil 32-bit Xen virtio setup. So the LDT issue seems to have gone away, which is good. However, I did get this from my single vcpu guest test [OK]LDT entry 0 is invalid [SKIP]Cannot set affinity to CPU 1 [RUN]Test exec [3.638967] CPU 0 set the LDT [OK]LDT entry 0 has AR 0x0040FA00 and limit 0x002A [3.639380] [ cut here ] [3.639389] WARNING: CPU: 0 PID: 383 at /local/linux-mainline.git/arch/x86/include/asm/mmu_context.h:96 flush_old_exec+0x7fd/0xb70() [3.639397] DEBUG_LOCKS_WARN_ON(!irqs_disabled()) You must be running v5 (or earlier). This is fixed in v6 --- it is now 'DEBUG_LOCKS_WARN_ON(preemptible());' -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen/events/fifo: Handle linked events when closing a port
On 31/07/15 14:30, Ross Lagerwall wrote: > When a channel is closed and the event is still linked into a queue, > ensure that it is unlinked before completing. If it is not unlinked and > the port is subsequently reused, events may be missed. > > If the CPU to which the event channel bound is online, spin until the > event is handled by that CPU. If that CPU is offline, it can't handle > the event, so clear the event queue during the close, dropping the > events. > > This fixes missing interrupts (and subsequent disk stalls) when > offlining a CPU. The last paragraph should be expanded I think. How about: An event channel bound to a CPU that was offlined may still be linked on that CPU's queue. If this event channel is closed and reused, subsequent events will be lost because the event channel is never unlinked. Otherwise, Reviewed-by: David Vrabel David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 4/4] x86/ldt: Make modify_ldt optional
* Andy Lutomirski wrote: > The modify_ldt syscall exposes a large attack surface and is > unnecessary for modern userspace. Make it optional. > > Reviewed-by: Kees Cook > Signed-off-by: Andy Lutomirski > --- > arch/x86/Kconfig | 17 + > arch/x86/include/asm/mmu.h | 2 ++ > arch/x86/include/asm/mmu_context.h | 28 +--- > arch/x86/kernel/Makefile | 3 ++- > arch/x86/kernel/cpu/perf_event.c | 4 > arch/x86/kernel/process_64.c | 2 ++ > arch/x86/kernel/step.c | 2 ++ > kernel/sys_ni.c| 1 + > 8 files changed, 51 insertions(+), 8 deletions(-) btw., I fixed a (rare) build failure on MATH_EMULATION=y && !MODIFY_LDT_SYSCALL: arch/x86/math-emu/fpu_system.h:21:71: error: ‘mm_context_t’ has no member named ‘ldt’ I took the easy fix: made MATH_EMULATION depend on MODIFY_LDT_SYSCALL for now. Thanks, Ingo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [tip:x86/asm] selftests/x86, x86/ldt: Add a selftest for modify_ldt()
Commit-ID: 014dc90b66c8d0b5f5a9400440727c134ee5e5a3
Gitweb: http://git.kernel.org/tip/014dc90b66c8d0b5f5a9400440727c134ee5e5a3
Author: Andy Lutomirski
AuthorDate: Thu, 30 Jul 2015 14:31:33 -0700
Committer: Ingo Molnar
CommitDate: Fri, 31 Jul 2015 10:24:37 +0200
selftests/x86, x86/ldt: Add a selftest for modify_ldt()
This tests general modify_ldt() behavior (only writes, so far) as
well as synchronous updates via IPI. It fails on old kernels.
I called this ldt_gdt because I'll add set_thread_area() tests to
it at some point.
Signed-off-by: Andy Lutomirski
Reviewed-by: Kees Cook
Cc: Andrew Cooper
Cc: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Sasha Levin
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: secur...@kernel.org
Cc: xen-devel
Link:
http://lkml.kernel.org/r/dcfda65dad07ff5a3ea97a9172b5963bf8031b2e.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/ldt_gdt.c | 576 ++
2 files changed, 577 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/x86/Makefile
b/tools/testing/selftests/x86/Makefile
index e8df47e..b70da4a 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -4,7 +4,7 @@ include ../lib.mk
.PHONY: all all_32 all_64 warn_32bit_failure clean
-TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs
+TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs ldt_gdt
TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault
TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
diff --git a/tools/testing/selftests/x86/ldt_gdt.c
b/tools/testing/selftests/x86/ldt_gdt.c
new file mode 100644
index 000..31a3035
--- /dev/null
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -0,0 +1,576 @@
+/*
+ * ldt_gdt.c - Test cases for LDT and GDT access
+ * Copyright (c) 2015 Andrew Lutomirski
+ */
+
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define AR_ACCESSED(1<<8)
+
+#define AR_TYPE_RODATA (0 * (1<<9))
+#define AR_TYPE_RWDATA (1 * (1<<9))
+#define AR_TYPE_RODATA_EXPDOWN (2 * (1<<9))
+#define AR_TYPE_RWDATA_EXPDOWN (3 * (1<<9))
+#define AR_TYPE_XOCODE (4 * (1<<9))
+#define AR_TYPE_XRCODE (5 * (1<<9))
+#define AR_TYPE_XOCODE_CONF(6 * (1<<9))
+#define AR_TYPE_XRCODE_CONF(7 * (1<<9))
+
+#define AR_DPL3(3 * (1<<13))
+
+#define AR_S (1 << 12)
+#define AR_P (1 << 15)
+#define AR_AVL (1 << 20)
+#define AR_L (1 << 21)
+#define AR_DB (1 << 22)
+#define AR_G (1 << 23)
+
+static int nerrs;
+
+static void check_invalid_segment(uint16_t index, int ldt)
+{
+ uint32_t has_limit = 0, has_ar = 0, limit, ar;
+ uint32_t selector = (index << 3) | (ldt << 2) | 3;
+
+ asm ("lsl %[selector], %[limit]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_limit]\n\t"
+"1:"
+: [limit] "=r" (limit), [has_limit] "+rm" (has_limit)
+: [selector] "r" (selector));
+ asm ("larl %[selector], %[ar]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_ar]\n\t"
+"1:"
+: [ar] "=r" (ar), [has_ar] "+rm" (has_ar)
+: [selector] "r" (selector));
+
+ if (has_limit || has_ar) {
+ printf("[FAIL]\t%s entry %hu is valid but should be invalid\n",
+ (ldt ? "LDT" : "GDT"), index);
+ nerrs++;
+ } else {
+ printf("[OK]\t%s entry %hu is invalid\n",
+ (ldt ? "LDT" : "GDT"), index);
+ }
+}
+
+static void check_valid_segment(uint16_t index, int ldt,
+ uint32_t expected_ar, uint32_t expected_limit,
+ bool verbose)
+{
+ uint32_t has_limit = 0, has_ar = 0, limit, ar;
+ uint32_t selector = (index << 3) | (ldt << 2) | 3;
+
+ asm ("lsl %[selector], %[limit]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_limit]\n\t"
+"1:"
+: [limit] "=r" (limit), [has_limit] "+rm" (has_limit)
+: [selector] "r" (selector));
+ asm ("larl %[selector], %[ar]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_ar]\n\t"
+"1:"
+: [ar] "=r" (ar), [has_ar] "+rm" (has_ar)
+: [selector] "r" (selector));
+
+ if (!has_limit || !has_ar) {
+ printf("[FAIL]\t%s entry %hu is invalid but should be valid\n",
+ (ldt ? "LDT" : "GDT"), index);
+
[Xen-devel] [tip:x86/asm] x86/ldt: Make modify_ldt synchronous
Commit-ID: 37868fe113ff2ba814b3b4eb12df214df555f8dc
Gitweb: http://git.kernel.org/tip/37868fe113ff2ba814b3b4eb12df214df555f8dc
Author: Andy Lutomirski
AuthorDate: Thu, 30 Jul 2015 14:31:32 -0700
Committer: Ingo Molnar
CommitDate: Fri, 31 Jul 2015 10:23:23 +0200
x86/ldt: Make modify_ldt synchronous
modify_ldt() has questionable locking and does not synchronize
threads. Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.
This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.
This fixes some fallout from the CVE-2015-5157 fixes.
Signed-off-by: Andy Lutomirski
Reviewed-by: Borislav Petkov
Cc: Andrew Cooper
Cc: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Sasha Levin
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: secur...@kernel.org
Cc:
Cc: xen-devel
Link:
http://lkml.kernel.org/r/4c6978476782160600471bd865b318db34c7b628.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/desc.h| 15 ---
arch/x86/include/asm/mmu.h | 3 +-
arch/x86/include/asm/mmu_context.h | 54 +++-
arch/x86/kernel/cpu/common.c | 4 +-
arch/x86/kernel/cpu/perf_event.c | 12 +-
arch/x86/kernel/ldt.c | 262 -
arch/x86/kernel/process_64.c | 4 +-
arch/x86/kernel/step.c | 6 +-
arch/x86/power/cpu.c | 3 +-
9 files changed, 210 insertions(+), 153 deletions(-)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index a0bf89f..4e10d73 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -280,21 +280,6 @@ static inline void clear_LDT(void)
set_ldt(NULL, 0);
}
-/*
- * load one particular LDT into the current CPU
- */
-static inline void load_LDT_nolock(mm_context_t *pc)
-{
- set_ldt(pc->ldt, pc->size);
-}
-
-static inline void load_LDT(mm_context_t *pc)
-{
- preempt_disable();
- load_LDT_nolock(pc);
- preempt_enable();
-}
-
static inline unsigned long get_desc_base(const struct desc_struct *desc)
{
return (unsigned)(desc->base0 | ((desc->base1) << 16) | ((desc->base2)
<< 24));
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 09b9620..364d274 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,8 +9,7 @@
* we put the segment information here.
*/
typedef struct {
- void *ldt;
- int size;
+ struct ldt_struct *ldt;
#ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index 804a3a6..984abfe 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -34,6 +34,50 @@ static inline void load_mm_cr4(struct mm_struct *mm) {}
#endif
/*
+ * ldt_structs can be allocated, used, and freed, but they are never
+ * modified while live.
+ */
+struct ldt_struct {
+ /*
+* Xen requires page-aligned LDTs with special permissions. This is
+* needed to prevent us from installing evil descriptors such as
+* call gates. On native, we could merge the ldt_struct and LDT
+* allocations, but it's not worth trying to optimize.
+*/
+ struct desc_struct *entries;
+ int size;
+};
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+ struct ldt_struct *ldt;
+
+ /* lockless_dereference synchronizes with smp_store_release */
+ ldt = lockless_dereference(mm->context.ldt);
+
+ /*
+* Any change to mm->context.ldt is followed by an IPI to all
+* CPUs with the mm active. The LDT will not be freed until
+* after the IPI is handled by all such CPUs. This means that,
+* if the ldt_struct changes before we return, the values we see
+* will be safe, and the new values will be loaded before we run
+* any user code.
+*
+* NB: don't try to convert this to use RCU without extreme care.
+* We would still need IRQs off, because we don't want to change
+* the local LDT after an IPI loaded a newer value than the one
+* that we can see.
+*/
+
+ if (unlikely(ldt))
+ set_ldt(ldt->entries, ldt->size);
+ else
+ clear_LDT();
+
+ DEBUG_LOCKS_WARN_ON(preemptible());
+}
+
+/*
* Used for LDT copy/destruction.
*/
int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
@@ -78,12 +122,12 @@ static inline void switch_mm(struct mm_struct *prev,
struct mm_struct *next,
* was called and then modify_ldt changed
[Xen-devel] [tip:x86/asm] x86/xen: Probe target addresses in set_aliased_prot () before the hypercall
Commit-ID: aa1acff356bbedfd03b544051f5b371746735d89 Gitweb: http://git.kernel.org/tip/aa1acff356bbedfd03b544051f5b371746735d89 Author: Andy Lutomirski AuthorDate: Thu, 30 Jul 2015 14:31:31 -0700 Committer: Ingo Molnar CommitDate: Fri, 31 Jul 2015 10:23:22 +0200 x86/xen: Probe target addresses in set_aliased_prot() before the hypercall The update_va_mapping hypercall can fail if the VA isn't present in the guest's page tables. Under certain loads, this can result in an OOPS when the target address is in unpopulated vmap space. While we're at it, add comments to help explain what's going on. This isn't a great long-term fix. This code should probably be changed to use something like set_memory_ro. Signed-off-by: Andy Lutomirski Cc: Andrew Cooper Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sasha Levin Cc: Steven Rostedt Cc: Thomas Gleixner Cc: secur...@kernel.org Cc: Cc: xen-devel Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.l...@kernel.org Signed-off-by: Ingo Molnar --- arch/x86/xen/enlighten.c | 40 1 file changed, 40 insertions(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 0b95c9b..11d6fb4 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -483,6 +483,7 @@ static void set_aliased_prot(void *v, pgprot_t prot) pte_t pte; unsigned long pfn; struct page *page; + unsigned char dummy; ptep = lookup_address((unsigned long)v, &level); BUG_ON(ptep == NULL); @@ -492,6 +493,32 @@ static void set_aliased_prot(void *v, pgprot_t prot) pte = pfn_pte(pfn, prot); + /* +* Careful: update_va_mapping() will fail if the virtual address +* we're poking isn't populated in the page tables. We don't +* need to worry about the direct map (that's always in the page +* tables), but we need to be careful about vmap space. In +* particular, the top level page table can lazily propagate +* entries between processes, so if we've switched mms since we +* vmapped the target in the first place, we might not have the +* top-level page table entry populated. +* +* We disable preemption because we want the same mm active when +* we probe the target and when we issue the hypercall. We'll +* have the same nominal mm, but if we're a kernel thread, lazy +* mm dropping could change our pgd. +* +* Out of an abundance of caution, this uses __get_user() to fault +* in the target address just in case there's some obscure case +* in which the target address isn't readable. +*/ + + preempt_disable(); + + pagefault_disable();/* Avoid warnings due to being atomic. */ + __get_user(dummy, (unsigned char __user __force *)v); + pagefault_enable(); + if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0)) BUG(); @@ -503,6 +530,8 @@ static void set_aliased_prot(void *v, pgprot_t prot) BUG(); } else kmap_flush_unused(); + + preempt_enable(); } static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries) @@ -510,6 +539,17 @@ static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries) const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE; int i; + /* +* We need to mark the all aliases of the LDT pages RO. We +* don't need to call vm_flush_aliases(), though, since that's +* only responsible for flushing aliases out the TLBs, not the +* page tables, and Xen will flush the TLB for us if needed. +* +* To avoid confusing future readers: none of this is necessary +* to load the LDT. The hypervisor only checks this when the +* LDT is faulted in due to subsequent descriptor access. +*/ + for(i = 0; i < entries; i += entries_per_page) set_aliased_prot(ldt + i, PAGE_KERNEL_RO); } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 0/4] x86: modify_ldt improvement, test, and config option
On 31/07/15 14:44, Boris Ostrovsky wrote: > On 07/31/2015 05:10 AM, Andrew Cooper wrote: >> On 30/07/15 22:31, Andy Lutomirski wrote: >>> This is intended for x86/urgent. Sorry for taking so long, but it >>> seemed nice to avoid breaking Xen. >> Very much appreciated. Thanks! >> >>> This fixes the "dazed and confused" issue which was exposed by the >>> CVE-2015-5157 fix. It's also probably a good general attack surface >>> reduction, and it replaces some scary code with IMO less scary code. >>> >>> Also, servers and embedded systems should probably turn off modify_ldt. >>> This makes that possible. >>> >>> Xen people, can you test patch 1? It works for me on my evil 32-bit >>> Xen virtio setup. >> So the LDT issue seems to have gone away, which is good. >> >> However, I did get this from my single vcpu guest test >> >> [OK]LDT entry 0 is invalid >> [SKIP]Cannot set affinity to CPU 1 >> [RUN]Test exec >> [3.638967] CPU 0 set the LDT >> [OK]LDT entry 0 has AR 0x0040FA00 and limit 0x002A >> [3.639380] [ cut here ] >> [3.639389] WARNING: CPU: 0 PID: 383 at >> /local/linux-mainline.git/arch/x86/include/asm/mmu_context.h:96 >> flush_old_exec+0x7fd/0xb70() >> [3.639397] DEBUG_LOCKS_WARN_ON(!irqs_disabled()) > > You must be running v5 (or earlier). This is fixed in v6 --- it is now > 'DEBUG_LOCKS_WARN_ON(preemptible());' Hmm - I definitely have the correct code, but did a complete clean and rebuild, and the issue went away. I presume I had something stale in the build. I am still seeing [5.496264] WARNING: CPU: 0 PID: 389 at /local/linux-mainline.git/kernel/locking/lockdep.c:2639 trace_hardirqs_off_caller+0xa9/0xb0() [5.496272] DEBUG_LOCKS_WARN_ON(!irqs_disabled()) [5.496276] CPU: 0 PID: 389 Comm: ldt_gdt_32 Not tainted 4.2.0-rc4+ #21 But that looks incidental, and unrelated to these fixes. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [tip:x86/asm] x86/ldt: Make modify_ldt() optional
Commit-ID: a5b9e5a2f14f25a8dae987494d50ad3aac7366b6
Gitweb: http://git.kernel.org/tip/a5b9e5a2f14f25a8dae987494d50ad3aac7366b6
Author: Andy Lutomirski
AuthorDate: Thu, 30 Jul 2015 14:31:34 -0700
Committer: Ingo Molnar
CommitDate: Fri, 31 Jul 2015 13:30:45 +0200
x86/ldt: Make modify_ldt() optional
The modify_ldt syscall exposes a large attack surface and is
unnecessary for modern userspace. Make it optional.
Signed-off-by: Andy Lutomirski
Reviewed-by: Kees Cook
Cc: Andrew Cooper
Cc: Andy Lutomirski
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Sasha Levin
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: secur...@kernel.org
Cc: xen-devel
Link:
http://lkml.kernel.org/r/a605166a771c343fd64802dece77a903507333bd.1438291540.git.l...@kernel.org
[ Made MATH_EMULATION dependent on MODIFY_LDT_SYSCALL. ]
Signed-off-by: Ingo Molnar
---
arch/x86/Kconfig | 18 ++
arch/x86/include/asm/mmu.h | 2 ++
arch/x86/include/asm/mmu_context.h | 28 +---
arch/x86/kernel/Makefile | 3 ++-
arch/x86/kernel/cpu/perf_event.c | 4
arch/x86/kernel/process_64.c | 2 ++
arch/x86/kernel/step.c | 2 ++
kernel/sys_ni.c| 1 +
8 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e26fe7a..7986580 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1036,6 +1036,7 @@ config VM86
config X86_16BIT
bool "Enable support for 16-bit segments" if EXPERT
default y
+ depends on MODIFY_LDT_SYSCALL
---help---
This option is required by programs like Wine to run 16-bit
protected mode legacy code on x86 processors. Disabling
@@ -1530,6 +1531,7 @@ config X86_RESERVE_LOW
config MATH_EMULATION
bool
+ depends on MODIFY_LDT_SYSCALL
prompt "Math emulation" if X86_32
---help---
Linux can emulate a math coprocessor (used for floating point
@@ -2074,6 +2076,22 @@ config CMDLINE_OVERRIDE
This is used to work around broken boot loaders. This should
be set to 'N' under normal conditions.
+config MODIFY_LDT_SYSCALL
+ bool "Enable the LDT (local descriptor table)" if EXPERT
+ default y
+ ---help---
+ Linux can allow user programs to install a per-process x86
+ Local Descriptor Table (LDT) using the modify_ldt(2) system
+ call. This is required to run 16-bit or segmented code such as
+ DOSEMU or some Wine programs. It is also used by some very old
+ threading libraries.
+
+ Enabling this feature adds a small amount of overhead to
+ context switches and increases the low-level kernel attack
+ surface. Disabling it removes the modify_ldt(2) system call.
+
+ Saying 'N' here may make sense for embedded or server kernels.
+
source "kernel/livepatch/Kconfig"
endmenu
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 364d274..55234d5 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,7 +9,9 @@
* we put the segment information here.
*/
typedef struct {
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
struct ldt_struct *ldt;
+#endif
#ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index 984abfe..379cd36 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -33,6 +33,7 @@ static inline void load_mm_cr4(struct mm_struct *mm)
static inline void load_mm_cr4(struct mm_struct *mm) {}
#endif
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
/*
* ldt_structs can be allocated, used, and freed, but they are never
* modified while live.
@@ -48,8 +49,23 @@ struct ldt_struct {
int size;
};
+/*
+ * Used for LDT copy/destruction.
+ */
+int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
+void destroy_context(struct mm_struct *mm);
+#else /* CONFIG_MODIFY_LDT_SYSCALL */
+static inline int init_new_context(struct task_struct *tsk,
+ struct mm_struct *mm)
+{
+ return 0;
+}
+static inline void destroy_context(struct mm_struct *mm) {}
+#endif
+
static inline void load_mm_ldt(struct mm_struct *mm)
{
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
struct ldt_struct *ldt;
/* lockless_dereference synchronizes with smp_store_release */
@@ -73,17 +89,13 @@ static inline void load_mm_ldt(struct mm_struct *mm)
set_ldt(ldt->entries, ldt->size);
else
clear_LDT();
+#else
+ clear_LDT();
+#endif
DEBUG_LOCKS_WARN_ON(preemptible());
}
-/*
- * Used for LDT copy/destruction.
- */
-int init_new_context(struct task_struct *t
Re: [Xen-devel] Xen master hangs
On Thu, Jul 30, 2015 at 04:32:57PM -0500, Doug Goldstein wrote: > On Tue, Jul 28, 2015 at 4:22 PM, Konrad Rzeszutek Wilk > wrote: > > On Tue, Jul 28, 2015 at 11:27:57AM -0500, Doug Goldstein wrote: > >> On Tue, Jul 28, 2015 at 10:01 AM, Konrad Rzeszutek Wilk > >> wrote: > >> > On Tue, Jul 28, 2015 at 09:30:59AM -0500, Doug Goldstein wrote: > >> >> On Mon, Jul 27, 2015 at 4:11 PM, Doug Goldstein > >> >> wrote: > >> >> > On Mon, Jul 27, 2015 at 4:55 AM, Andrew Cooper > >> >> > wrote: > >> >> >> On 24/07/15 17:52, Doug Goldstein wrote: > >> >> >> > >> >> > >> >> > >> >> > > >> >> (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] > >> >> (XEN) CPU:3 > >> >> (XEN) RIP:e008:[] cea9727b > >> >> (XEN) RFLAGS: 00010286 CONTEXT: hypervisor (d0v3) > >> >> (XEN) rax: cea9727b rbx: 830216c7fe48 rcx: > >> >> 001f > >> >> (XEN) rdx: d674ded0 rsi: 00319697ec80 rdi: > >> >> 83021df64080 > >> >> (XEN) rbp: 830216c7fda8 rsp: 830216c7fd20 r8: > >> >> 830216c7fe68 > >> >> (XEN) r9: r10: r11: > >> >> db002700 > >> >> (XEN) r12: 830216c7fe68 r13: r14: > >> >> 83021df64080 > >> >> (XEN) r15: 000211c13000 cr0: 80050033 cr4: > >> >> 001526e0 > >> >> (XEN) cr3: 000216cb7000 cr2: cea9727b > >> >> (XEN) ds: es: fs: gs: ss: e010 cs: e008 > >> >> (XEN) Xen stack trace from rsp=830216c7fd20: > >> >> (XEN)d674cd77 000211c13000 81ce0a20 > >> >> 82d0802aabc4 > >> >> (XEN)83021df64080 8013 ffa1 > >> >> 000216cb7000 > >> >> (XEN)82d08023f5a1 830216c7fe48 830216c7fde8 > >> >> 00319697ec80 > >> >> (XEN)82d08023f56c 830216cc8340 0003 > >> >> 830216c7fde8 > >> >> (XEN)0206 0400 0292 > >> >> 830128e0dd80 > >> >> (XEN)830216c7ff18 81ce0a20 82d0802aabc4 > >> >> 830216c78000 > >> >> (XEN)82d080320080 830216c7fef8 82d0801673ba > >> >> 830216cc8108 > >> >> (XEN)0027b02880108237 880209de7d18 > >> >> 0002 > >> >> (XEN)830216c7fe38 82d08012ce6a 830216c7fe58 > >> >> 82d08018ad0c > >> >> (XEN)03010031 0008 > >> >> 0400 > >> >> (XEN)8802038c0c00 > >> >> > >> >> (XEN) > >> >> > >> >> (XEN) > >> >> > >> >> (XEN) 830216c7fef8 8300d65fd000 > >> >> 81ce0a20 > >> >> (XEN) 8167e290 > >> >> 880209de7da8 > >> >> (XEN)82d08023abda 810010ea 0007 > >> >> 8802038a85bc > >> >> (XEN)8802038a83dc 8802038a85be 0700 > >> >> 880209de7da8 > >> >> (XEN)8802038c0c00 0246 88020f0d77c0 > >> >> 880209de7de8 > >> >> (XEN)000175a0 0007 810010ea > >> >> > >> >> (XEN)8802038c0c00 880209de7d18 00010100 > >> >> 810010ea > >> >> (XEN) Xen call trace: > >> >> (XEN)[ ] cea9727b > >> >> (XEN)[] efi_runtime_call+0x64e/0x80a > >> >> (XEN)[] efi_runtime_call+0x619/0x80a > >> >> (XEN)[] do_platform_op+0xb76/0x1a14 > >> >> (XEN)[] _spin_lock+0x11/0x52 > >> >> (XEN)[] stime2tsc+0x78/0x82 > >> >> (XEN)[] lstar_enter+0xda/0x134 > >> >> (XEN) > >> >> (XEN) Pagetable walk from cea9727b: > >> >> (XEN) L4[0x000] = 000216cb6063 > >> >> (XEN) L3[0x003] = cfca4063 > >> >> (XEN) L2[0x075] = ce9ff063 > >> >> (XEN) L1[0x097] = 8000cea97163 000d15e5 > >> >> (XEN) > >> >> (XEN) > >> >> (XEN) Panic on CPU 3: > >> >> (XEN) FATAL PAGE FAULT > >> >> (XEN) [error_code=0011] > >> >> (XEN) Faulting linear address: cea9727b > >> >> (XEN) > >> >> (XEN) > >> >> (XEN) Reboot in five seconds... > >> > > >> > We added a bunch of overrides that may help. > >> > > >> > The address looks to be for: > >> > (XEN) 0cea97000-0ceaacfff type=4 attr=000f > >> > > >> > Which is of EfiBootServicesData > >> > > >> > Try on the Xen.efi command line to use /mapbs > >> > > >> > You may have to install first EFI Shell Manager and then from there > >> > execute the xen.efi /mapbs > >> > > >> > >> So I installed ShellBinPkg from TianoCore and got their UEFI Shell > >> 2.1. I've kicked it off with both "xen-4.6-unstable.efi /mapbs" and > >> "xe
Re: [Xen-devel] 4.6 release bug lists
On Thu, Jul 30, 2015 at 05:10:10PM +0200, Roger Pau Monné wrote: > El 30/07/15 a les 17.04, Wei Liu ha escrit: > > Hi all > > > > Here are some bugs that I'm aware of. The name after a item is the > > person who is working on it. > > > > # Blockers > > > > 1. Toolstack record breaks migration v2 (Andrew Cooper) > > 2. Block hotplug scripts invoked multiple times (Roger Pau Monne) > > This "issue" is due to stale udev rules from previous installations. A I did not have stale udev rules. I had no Xen udev rules at all. > clean install or a update from a packaged Xen from a distro should work > fine. We could consider installing an empty udev rules file to replace > the previous one, but IMHO this is kind of crappy. > > Then Konrad was also seeing timeout errors from hotplug scripts > execution, and we are still looking into the cause of this. > > > > > # Non-blockers > > > > 1. QEMU block script doesn't work (George Dunlap) > > > > If you think I miss other bugs (very likely because I haven't gone > > through my xen-devel archive), please reply to this email. > > I'm quite sure this should be a blocker: > > http://marc.info/?l=xen-devel&m=143816508010982 > > Roger. > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 32/41] arm : acpi dynamically map mmio regions
On Fri, 31 Jul 2015, Julien Grall wrote: > Hi Shannon, > > On 31/07/15 02:30, Shannon Zhao wrote: > > > > > > On 2015/7/31 2:31, Julien Grall wrote: > >> On 30/07/15 19:02, Parth Dixit wrote: > >>> instead of getting mmio information for individual > >>> devices from dsdt, we will map all the non-ram regions described in > >>> uefi. AML interpreter option was discussed earlier and it was decided > >>> not to go with that approach. You can find more details in the linaro > >>> xen wiki for the reasoning behind it. > >> > >> Which page are you talking about? I only found [1] speaking about ACPI. > >> Although, there is nothing related to MMIO mapping. > >> > >> Anyway, it's not possible to get the list of MMIOs regions for the UEFI > >> System Memory Map (see the mail you forward on the ML [2]). > >> > >> Although, based on the RAM region we could deduce a possible set of MMIO > >> regions. > > But I guess this will get the all regions except RAM region. And some of > > the regions may not exist on hardware. Is it ok to map the non-exist > > region to DOM0? Doesn't the map function fail? > > I don't see a problem for it. I'm not sure what the others think about it. > > The map function doesn't know if the physical region is valid or not. > It's only setup the page table to allow the guest using the physical region. > > If DOM0 is trying to access invalid region, it will receive a > data/prefetch abort. I don't think there is a problem with mapping inexistent memory to dom0. The only issue is that mapping very large amounts of memory to dom0 takes a lot of memory to store the pagetables themselves in Xen. If we do that we should definitely use page sizes greater than 4K: 2M or 1G. I think that starting out with simply relying on the UEFI System Memory Map would be OK, even though we know that it is not complete. I would recommend to just do that in the next version of this series and leave this problem for later. Although I think it should be solved before completing this work, I wouldn't want everything else to get stuck because of this. Maybe you could sort out the other issues while we are still discussing this one. One option going forward is to map MMIO regions in Dom0 on demand when trapping in Xen with a data abort. Specifically in xen/arch/arm/traps.c:do_trap_data_abort_guest we could check that the guest is dom0 and that the address correspond to a non-ram region not owned by Xen. If the checks succeed then we map the page in Dom0. > >> It would be fine to mapped unused region in memory and we could > >> take advantage of super page. > >> > >> While you are speaking about the wiki page. Can one of you update the > >> wiki page about the boot protocol? Jan had some concerns about the > >> solution you choose (see [3] to not mention the whole thread). > >> > > > > About the XENV table, from the discussions of the thread, it seems we > > reach an agreement on using hypercall to tell DOM0 the grant table info > > and event channel irq. Right? > > People have different opinion on what should be the way to boot DOM0 > with ACPI on ARM. A design document would help here to understand what > are the possibilities to boot DOM0 (i.e hypercall based, XENV...) and > which one would be the most suitable for ARM. As I wrote previously (http://marc.info/?i=alpine.DEB.2.02.1505291102390.8130%40kaball.uk.xensource.com), although I prefer tables, I am OK with hypercalls too, and for the sake of moving this work forward in the quickest way possible, let's just do that. This is a minor point on the grand scheme of things. I suggest you introduce two new hvm params to get the grant table address and event channel ppi, see xen/include/public/hvm/params.h. They can be retrieved using the HVMOP_get_param hypercall. Also remember that if we avoid the XENV table, then we need to set the new FADT field "Hypervisor Vendor Identity" appropriately to advertise the presence of Xen on the platform. > >> We need to agree on the boot protocol before going further on this series. > >> > >> To speed up the upstreaming process, it would be nice if you start a > >> thread about the boot protocol for ACPI with relevant people in CCed. > >> The main goal will be to explain why you choose this way. This will be > >> the base to talk about improvement and/or answer concerns for other people. > >> > > > > Ok, it's good to reach an agreement before action. > > > >> FWIW, Jan also suggested a different boot protocol based on the x86 one. > >> It may be good for you to see whether it would fit ACPI on ARM. > >> > > > > Which boot protocol? Could you point it out? Thanks. :) > > The way to boot DOM0 with ACPI. There is a page on the Linaro wiki [1], > but the content is quite out of date now. > > Regards, > > [1] https://wiki.linaro.org/LEG/Engineering/Virtualization/ACPI_on_Xen http://marc.info/?i=1431893048-5214-1-git-send-email-parth.dixit%40linaro.org is a good start, but it needs more details. Th
Re: [Xen-devel] [BUG] Emulation issues
> -Original Message- > From: Paul Durrant > Sent: 31 July 2015 13:21 > To: Paul Durrant; Roger Pau Monne; Sander Eikelenboom > Cc: Andrew Cooper; xen-devel > Subject: RE: [Xen-devel] [BUG] Emulation issues > > > -Original Message- > > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > > boun...@lists.xen.org] On Behalf Of Paul Durrant > > Sent: 31 July 2015 12:43 > > To: Roger Pau Monne; Sander Eikelenboom > > Cc: Andrew Cooper; xen-devel > > Subject: Re: [Xen-devel] [BUG] Emulation issues > > > > > -Original Message- > > > From: Roger Pau Monné [mailto:roger@citrix.com] > > > Sent: 31 July 2015 12:42 > > > To: Paul Durrant; Sander Eikelenboom > > > Cc: Andrew Cooper; xen-devel > > > Subject: Re: [Xen-devel] [BUG] Emulation issues > > > > > > El 31/07/15 a les 13.39, Paul Durrant ha escrit: > > > >> -Original Message- > > > >> From: Sander Eikelenboom [mailto:li...@eikelenboom.it] > > > >> Sent: 31 July 2015 12:12 > > > >> To: Paul Durrant > > > >> Cc: Andrew Cooper; Roger Pau Monne; xen-devel > > > >> Subject: Re: [Xen-devel] [BUG] Emulation issues > > > >> > > > >> > > > >> Friday, July 31, 2015, 12:22:16 PM, you wrote: > > > >> > > > -Original Message- > > > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > > > boun...@lists.xen.org] On Behalf Of Paul Durrant > > > Sent: 30 July 2015 14:20 > > > To: Andrew Cooper; Roger Pau Monne; xen-devel > > > Subject: Re: [Xen-devel] [BUG] Emulation issues > > > > > > > -Original Message- > > > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > > > > Sent: 30 July 2015 14:19 > > > > To: Paul Durrant; Roger Pau Monne; xen-devel > > > > Subject: Re: [BUG] Emulation issues > > > > > > > > On 30/07/15 14:12, Paul Durrant wrote: > > > >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > > > >>> (XEN) domain_crash called from io.c:166 > > > >>> (XEN) d19v0 weird emulation state 1 > > > >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > > > >>> (XEN) domain_crash called from io.c:166 > > > >>> (XEN) d19v0 weird emulation state 1 > > > >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. > > > >>> (XEN) domain_crash called from io.c:166 > > > >>> > > > >> Hmm. Can't understand how that's happening... handle_pio() > > > >> shouldn't > > > be > > > > called unless the state is STATE_IORESP_READY and yet the inner > > > >> function > > > is > > > > hitting the default case in the switch. > > > > > > > > Sounds like something is changing the state between the two > > checks. > > > Is > > > > this shared memory writeable by qemu? > > > > > > > > > > No, this is the internal state. I really can't see how it's being > changed. > > > > > > >> > > > >>> I've tried to replicate your test on my rig (which is an old AMD box > but > > > quite > > > >> a big one). Even so I only seem to get about half the VMs to start. The > > > >> shutdown works fine, and I don't see any problems on the Xen > console. > > > I'm > > > >> using an older build of Xen but still one with my series in. I'll try > > > >> pulling > > up > > > to > > > >> the same commit as you and try again. > > > >> > > > >>> Paul > > > >> > > > >> Hi Paul, > > > >> > > > >> From what i recall it started around when Tiejun Chen's series went in. > > > >> > > > > > > Since I can reproduce this at will I will attempt to perform a > > > bisection. Maybe this can help narrow down the issue. > > > > > > > Thanks. That would be very helpful. I will continue to try to repro. > > > > Still no luck with the repro but I think I might my thought experiments might > have got it... > > If a vcpu has a request in-flight then its internal ioreq state will be > IOREQ_READY and it will be waiting for wake-up. When it is woken up > hvm_do_resume() will be called and it will call hvm_wait_for_io(). If the > shared (with QEMU) ioreq state is still IOREQ_READY or IOREQ_INPROCESS > then the vcpu will block again. If the shared state is IORESP_READY then the > emulation is done and the internal state will be updated to IORESP_READY or > IOREQ_NONE by hvm_io_assist() depending upon whether any completion > is needed or not. > *However* if the emulator (or Xen) happens to zero out the shared ioreq > state before hvm_wait_for_io() is called then it will see a shared state of > IOREQ_NONE so it will terminate without calling hvm_io_assist() leaving the > internal ioreq state as IOREQ_READY which will then cause the > domain_crash() you're seeing when re-emulation is attempted by a > completion handler. > > So, there is an underlying problem in that a dying emulator can leave an I/O > uncompleted but the code in Xen needs to cope more gracefully with that > (since the vcpu will be going away anyway) and not call domain_crash(). > Can you please try this patch: diff --git a/xen/arch/x86/hvm/hvm.c b/xen/
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On Fri, Jul 31, 2015 at 11:32:19AM +0100, Ian Campbell wrote: > On Fri, 2015-07-31 at 09:05 +0100, Ian Campbell wrote: > > On Fri, 2015-07-31 at 13:16 +0530, Manish Jaggi wrote: > > > > > Secondly, the vdev-X entry is created async by dom0 watching on > > > > > event. > > Stefano points out that there are, confusingly, two nodes in xenstore > relating to the virtual-SBDF. > > vdev-X is written by pciback and is read by pcifront, it is effectively > there to communicate the vSBDF to the guest. > > vdevfn-X is written by the toolstack (libxl_create_pci_backend_device) to > tell the backend (pciback, or qemu in x86/HVM configurations using old > qemu) the vSBDF to be associated with the device. > > It looks like vdevfn-X is not actually currently supported by pciback in > Linux (seemingly only the x86/HVM qemu backend consumes it). I think we > should add that support to pciback for consistency with the qemu based > backend used by x86/HVM guests. > > The names are a certainly a bit confusing. We could add a new key with a > better name to communicate the vSBDF from toolstack->backend, but itseems > to me to be that would just adding even more confusion, so I recommend we > don't do that. > > Once pciback supports vdevfn then libxl will be able to choose the PCI bus > layout for ARM guests in the case where the use has not requested an > explicit vdevfn for the device. > > Does that make sense? Yes. > > Ian. > > > ___ > 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] PCI Pass-through in Xen ARM - Draft 2.
Hi Julien, On 31/07/15 6:29 pm, Julien Grall wrote: Hi Manish, On 31/07/15 13:50, Manish Jaggi wrote: Ok, i will implement the same from pciback to toolstack. I am not sure about the complexity but will give it a try. With this xen-pciback will not create the vdev-X entry at all. Can you send a new draft before continuing to implement PCI support in Xen? I am working on the Draft 3 and addressing comments in draft 2. I am doing a feasibility of the stuff I put in draft3. As long as we are not agree about it, I thought I was trying to discuss the same. If you have any point please raise it. you loose your time trying to implement something that can drastically change in the next revision. I am only putting the stuff in the Draft3 which *can* be implemented later. Regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On 31/07/15 15:33, Manish Jaggi wrote: > Hi Julien, > > On 31/07/15 6:29 pm, Julien Grall wrote: >> Hi Manish, >> >> On 31/07/15 13:50, Manish Jaggi wrote: >>> Ok, i will implement the same from pciback to toolstack. I am not sure >>> about the complexity but will give it a try. >>> With this xen-pciback will not create the vdev-X entry at all. >> Can you send a new draft before continuing to implement PCI support in >> Xen? > I am working on the Draft 3 and addressing comments in draft 2. I am > doing a feasibility of the stuff I put in draft3. Well, I don't think that anything we say within this thread was impossible to do. >> As long as we are not agree about it, > I thought I was trying to discuss the same. If you have any point please > raise it. What I meant is, this is a 40-messages thread with lots of discussions on it. A new draft containing a summary on what was said would benefits everyone and help us to get on a design that we think is good. >> you loose your time trying to >> implement something that can drastically change in the next revision. > I am only putting the stuff in the Draft3 which *can* be implemented later. But nothing prevent someone in the discussion on Draft3 to say this is wrong and it has to be done in a different way. Usually the time between two draft should be pretty short in order to get sane base for discussion. For now, we are talking about small portion of design and speculating/trying to remember what was agreed on other sub-thread. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Should hvm_hw_cpu's sysenter_eip always be zero after xc_domain_hvm_getcontext_partial()?
Hello, It has become apparent that after a succesful xc_domain_hvm_getcontext_partial( ..., HVM_SAVE_CODE(CPU), ...) call, the sysenter_eip member of struct hvm_hw_cpu is always zero. Looking in the code, the only two __vmwrite(GUEST_SYSENTER_EIP, ...) calls occur in xen/arch/x86/hvm/vmx/vmx.c. One is in vmx_msr_write_intercept(), but adding a printk() just after produces no output after starting and stopping a guest. The other is in vmx_vmcs_restore(), which seems to dutifully restore the never-set value of zero after a save. So this doesn't seem to be actually initialized anywhere. Could somebody please recommend the best place to initialize it, and the best value to initialize it with? Or maybe you could point out what I'm missing, if that's the case? Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On 31/07/15 8:26 pm, Julien Grall wrote: On 31/07/15 15:33, Manish Jaggi wrote: Hi Julien, On 31/07/15 6:29 pm, Julien Grall wrote: Hi Manish, On 31/07/15 13:50, Manish Jaggi wrote: Ok, i will implement the same from pciback to toolstack. I am not sure about the complexity but will give it a try. With this xen-pciback will not create the vdev-X entry at all. Can you send a new draft before continuing to implement PCI support in Xen? I am working on the Draft 3 and addressing comments in draft 2. I am doing a feasibility of the stuff I put in draft3. Well, I don't think that anything we say within this thread was impossible to do. As long as we are not agree about it, I thought I was trying to discuss the same. If you have any point please raise it. What I meant is, this is a 40-messages thread with lots of discussions on it. A new draft containing a summary on what was said would benefits everyone and help us to get on a design that we think is good. you loose your time trying to implement something that can drastically change in the next revision. I am only putting the stuff in the Draft3 which *can* be implemented later. But nothing prevent someone in the discussion on Draft3 to say this is wrong and it has to be done in a different way. Usually the time between two draft should be pretty short in order to get sane base for discussion. For now, we are talking about small portion of design and speculating/trying to remember what was agreed on other sub-thread. ok will send draft 3 with the points on this topic as under discussion. Is that fine? Regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Should hvm_hw_cpu's sysenter_eip always be zero after xc_domain_hvm_getcontext_partial()?
On 31/07/15 16:00, Razvan Cojocaru wrote: > Hello, > > It has become apparent that after a succesful > xc_domain_hvm_getcontext_partial( ..., HVM_SAVE_CODE(CPU), ...) call, > the sysenter_eip member of struct hvm_hw_cpu is always zero. How odd. > > Looking in the code, the only two __vmwrite(GUEST_SYSENTER_EIP, ...) > calls occur in xen/arch/x86/hvm/vmx/vmx.c. One is in > vmx_msr_write_intercept(), but adding a printk() just after produces no > output after starting and stopping a guest. Write interception for that MSR is disabled (if the hardware supports disabling interception) because it is not interesting. You can re-enable interception by commenting out the appropriate vmx_disable_intercept_for_msr() line in construct_vmcs() > > The other is in vmx_vmcs_restore(), which seems to dutifully restore the > never-set value of zero after a save. > > So this doesn't seem to be actually initialized anywhere. Could somebody > please recommend the best place to initialize it, and the best value to > initialize it with? Or maybe you could point out what I'm missing, if > that's the case? Are you certain that the guest is actually setting it? If the guest never sets it in the first place, 0 will be the expected value. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.
On 31/07/15 16:12, Manish Jaggi wrote: >> Usually the time between two draft should be pretty short in order to >> get sane base for discussion. For now, we are talking about small >> portion of design and speculating/trying to remember what was agreed on >> other sub-thread. > ok will send draft 3 with the points on this topic as under discussion. > Is that fine? Yes please. Thank you, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] Emulation issues
El 31/07/15 a les 16.19, Paul Durrant ha escrit: >> -Original Message- >> From: Paul Durrant >> Sent: 31 July 2015 13:21 >> To: Paul Durrant; Roger Pau Monne; Sander Eikelenboom >> Cc: Andrew Cooper; xen-devel >> Subject: RE: [Xen-devel] [BUG] Emulation issues >> >>> -Original Message- >>> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- >>> boun...@lists.xen.org] On Behalf Of Paul Durrant >>> Sent: 31 July 2015 12:43 >>> To: Roger Pau Monne; Sander Eikelenboom >>> Cc: Andrew Cooper; xen-devel >>> Subject: Re: [Xen-devel] [BUG] Emulation issues >>> -Original Message- From: Roger Pau Monné [mailto:roger@citrix.com] Sent: 31 July 2015 12:42 To: Paul Durrant; Sander Eikelenboom Cc: Andrew Cooper; xen-devel Subject: Re: [Xen-devel] [BUG] Emulation issues El 31/07/15 a les 13.39, Paul Durrant ha escrit: >> -Original Message- >> From: Sander Eikelenboom [mailto:li...@eikelenboom.it] >> Sent: 31 July 2015 12:12 >> To: Paul Durrant >> Cc: Andrew Cooper; Roger Pau Monne; xen-devel >> Subject: Re: [Xen-devel] [BUG] Emulation issues >> >> >> Friday, July 31, 2015, 12:22:16 PM, you wrote: >> -Original Message- From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- boun...@lists.xen.org] On Behalf Of Paul Durrant Sent: 30 July 2015 14:20 To: Andrew Cooper; Roger Pau Monne; xen-devel Subject: Re: [Xen-devel] [BUG] Emulation issues > -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 30 July 2015 14:19 > To: Paul Durrant; Roger Pau Monne; xen-devel > Subject: Re: [BUG] Emulation issues > > On 30/07/15 14:12, Paul Durrant wrote: >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >>> (XEN) domain_crash called from io.c:166 >>> (XEN) d19v0 weird emulation state 1 >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >>> (XEN) domain_crash called from io.c:166 >>> (XEN) d19v0 weird emulation state 1 >>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1. >>> (XEN) domain_crash called from io.c:166 >>> >> Hmm. Can't understand how that's happening... handle_pio() >> shouldn't be > called unless the state is STATE_IORESP_READY and yet the inner >> function is > hitting the default case in the switch. > > Sounds like something is changing the state between the two >>> checks. Is > this shared memory writeable by qemu? > No, this is the internal state. I really can't see how it's being >> changed. >> >>> I've tried to replicate your test on my rig (which is an old AMD box >> but quite >> a big one). Even so I only seem to get about half the VMs to start. The >> shutdown works fine, and I don't see any problems on the Xen >> console. I'm >> using an older build of Xen but still one with my series in. I'll try >> pulling >>> up to >> the same commit as you and try again. >> >>> Paul >> >> Hi Paul, >> >> From what i recall it started around when Tiejun Chen's series went in. >> Since I can reproduce this at will I will attempt to perform a bisection. Maybe this can help narrow down the issue. >>> >>> Thanks. That would be very helpful. I will continue to try to repro. >>> >> >> Still no luck with the repro but I think I might my thought experiments might >> have got it... >> >> If a vcpu has a request in-flight then its internal ioreq state will be >> IOREQ_READY and it will be waiting for wake-up. When it is woken up >> hvm_do_resume() will be called and it will call hvm_wait_for_io(). If the >> shared (with QEMU) ioreq state is still IOREQ_READY or IOREQ_INPROCESS >> then the vcpu will block again. If the shared state is IORESP_READY then the >> emulation is done and the internal state will be updated to IORESP_READY or >> IOREQ_NONE by hvm_io_assist() depending upon whether any completion >> is needed or not. >> *However* if the emulator (or Xen) happens to zero out the shared ioreq >> state before hvm_wait_for_io() is called then it will see a shared state of >> IOREQ_NONE so it will terminate without calling hvm_io_assist() leaving the >> internal ioreq state as IOREQ_READY which will then cause the >> domain_crash() you're seeing when re-emulation is attempted by a >> completion handler. >> >> So, there is an underlying problem in that a dying emulator can leave an I/O >> uncompleted but the code in Xen needs to cope more gracefully with that >> (since the vcpu will be going away anyway) and not call domain_crash(). >> > > Can you please try this patch: > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index ec1d797..197a8c4 100644 >
Re: [Xen-devel] [PATCH v2 2/3] ts-debian-hvm-install: use di_installcmdline_core
Ian Campbell writes ("[PATCH v2 2/3] ts-debian-hvm-install: use
di_installcmdline_core"):
> This is primarily to get DEBIAN_FRONTEND=test, for easier to read
> logging.
text
Aside from that,
Acked-by: Ian Jackson
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
