flight 34801 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34801/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 5 xen-boot fail REGR. vs. 34580
test-armhf-armhf-libvirt
On Fri, Feb 20, 2015 at 4:45 PM, Julien Grall wrote:
> On 20/02/15 10:44, Ian Campbell wrote:
>> On Fri, 2015-02-20 at 15:56 +0530, Vijay Kilari wrote:
>>> On Fri, Feb 20, 2015 at 3:44 PM, Ian Campbell
>>> wrote:
On Thu, 2015-02-19 at 18:01 +, Julien Grall wrote:
> Based on the disc
flight 34822 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34822/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3863 host-install(3) broken REGR. vs. 34151
test-amd64-amd64-
flight 34885 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34885/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866
build-amd64-rumpuserx
flight 34807 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34807/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 3 host-install(3)broken REGR. vs. 34190
build-amd64
flight 34747 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34747/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33686
test-amd64-i386-xl-qemuu-ovm
On 02/20/2015 10:58 AM, Julien Grall wrote:
Each class can contains 32 permisions which are encoded on a word (one
bit per permission).
Currently the awk script will generate an hexadecimal value for each
permission. This may result to generate an invalid value on some version
of awk.
For insta
>>> On 2/20/2015 at 11:10 AM, Charles Arnold wrote:
> Now that Xen uses qdisks by default and qemu does not write out
> statistics to sysfs this patch queries the QMP for disk statistics.
Forget this patch. I assumed the name of the xenstore backend device
(eg, xvda, hda, etc) would be the same n
On Thu, Feb 19, 2015 at 09:13:52AM +, Jan Beulich wrote:
> >>> On 18.02.15 at 19:15, wrote:
> > On Tue, Feb 17, 2015 at 02:14:20PM +, Andrew Cooper wrote:
> >> On 17/02/15 13:39, Jan Beulich wrote:
> >> On 17.02.15 at 14:32, wrote:
> >> >> On 17/02/15 12:36, Jan Beulich wrote:
> >> >
>
> Agree, Life would be easier if we can remove the persistent feature.
..snip..
> >>>
> >>> If Konrad/Bob agree I would like to send a patch to remove persistent
> >>> grants and then have the multiqueue series rebased on top of that.
..snip..
> >>
> >> I agree with this.
> >>
> >> I
Now that Xen uses qdisks by default and qemu does not write out
statistics to sysfs this patch queries the QMP for disk statistics.
Signed-off-by: Charles Arnold
diff --git a/tools/xenstat/libxenstat/src/xenstat_linux.c
b/tools/xenstat/libxenstat/src/xenstat_linux.c
index 7fdf70a..885d089 10064
On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
> > That's the issue we are trying to resolve, with device tree there is no
> > explicit segment ID, so we have an essentially unindexed set of PCI
> > buses in both Xen and dom0.
>
> How that? What if two bus numbers are equal? There ought to
On 20/02/15 16:56, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> Signed-off-by: Julien Grall
>
> Is this function still needed in the new model which doesn't do
> automatic mappings etc?
It's used is the pass-through DOMCTL code.
Regards,
--
Julien Grall
__
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> TODO: Update the commit message
>
> A device node is described by a path. It will be used to retrieved the
> node in the device tree and assign the related device to the domain.
>
> Only device protected by an IOMMU can be assigned to a gue
Hi Ian,
On 20/02/15 16:31, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>
>> Futhermore, a guest can crash and let the IRQ in an incorrect state (i.e has
>
> "Furthermore" (I think your finger macros have this one wrong, you might
> want to grep the series ;-))
I
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Signed-off-by: Julien Grall
> Acked-by: Stefano Stabellini
Acked-by: Ian Campbell
(although this does seem to suggest that my decision to use
subarch_do_domctl was flawed -- I should just have inlined
XEN_DOMCTL_set_address_size with a c
On 20/02/15 17:18, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>
> I've gotten as far as patch #20 but I've run out of time (and it seems
> like a good breaking point). I'll look at the last 4 next week.
Thanks for the review! I will address all the comments next
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Currently, when the device is deassigned from a domain, we directly reassign
> to DOM0.
>
> As the device may not have been correctly reset, this may lead to corruption
> or
> expose some part of DOM0 memory. Also, we may have no way to res
On 20/02/15 17:03, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>
> Subject: "release the DT devices assigned to a guest earlier"
>
>> The toolstack may not have deassign every device used by a guest.
>
> "deassigned"
>
>> Therefore we have to go through the devi
On 20/02/15 16:58, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> This new function will correctly initialize the IOMMU page table for the
>> current domain.
>>
>> Also use it in iommu_assign_dt_device even though the current IOMMU
>> implementation on ARM shares P2
Hi Ian,
On 20/02/15 16:00, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> Currently Xen only supports SPIs routing for guest, add a function
>> is_assignable_irq to check if we can assign a given IRQ to the guest.
>>
>> Secondly, make sure the vIRQ is not the great
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Futhermore, a guest can crash and let the IRQ in an incorrect state (i.e has
"Furthermore" (I think your finger macros have this one wrong, you might
want to grep the series ;-))
> +/* TODO: Handle eviction from LRs. For now, deny remo
Hi Ian,
On 20/02/15 16:07, Ian Campbell wrote:
> More importantly: We have (hopefully) guaranteed elsewhere that an PPI
> or SGI can never make it here, I take it. If that's the case then either
> the comment should say that, or more likely, the comment is redundently
> restating the assert's cond
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
I've gotten as far as patch #20 but I've run out of time (and it seems
like a good breaking point). I'll look at the last 4 next week.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lis
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Signed-off-by: Julien Grall
Is this function still needed in the new model which doesn't do
automatic mappings etc?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-d
On 20/02/15 16:08, Ian Campbell wrote:
> On Wed, 2015-01-28 at 18:26 +, Stefano Stabellini wrote:
>
>>> +int spi = irq - 32;
>>
>> unsigned int
>
> and underflow?
No because there is a check (irq < 32) before using the variable spi.
It was more convenient to initialize it directly.
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> There is no reason to use signed integer for an index.
Did you check for now pointless "if ( uthing < 0 ) which a picky
compiler might whinge about?
> Signed-off-by: Julien Grall
> Acked-by: Stefano Stabellini
Acked-by: Ian Campbell
On Thu, 2015-01-29 at 12:33 +, Stefano Stabellini wrote:
> On Thu, 29 Jan 2015, Julien Grall wrote:
> > On 29/01/15 12:17, Stefano Stabellini wrote:
> > > On Wed, 28 Jan 2015, Julien Grall wrote:
> > >> Hi Stefano,
> > >>
> > >> On 28/01/15 18:52, Stefano Stabellini wrote:
> > >>> On Tue, 13 Ja
Hi Ian,
On 20/02/15 16:23, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> Each domain may have a different number of IRQs depending on the devices
>> assigned to it.
>>
>> Rather re-using the number of IRQs used by the hardwared GIC, let the
> ^than and "ha
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
Subject: "release the DT devices assigned to a guest earlier"
> The toolstack may not have deassign every device used by a guest.
"deassigned"
> Therefore we have to go through the device list and removing them before
"and remove them"
>
On 20/02/15 15:52, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> Actually Xen is assuming that the virtual IRQ will always be the same as IRQ.
>
> s/Actually/Currently/?
Yes, I always mix both because the former is close to the french word.
>> Modify route_guest
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> This new function will correctly initialize the IOMMU page table for the
> current domain.
>
> Also use it in iommu_assign_dt_device even though the current IOMMU
> implementation on ARM shares P2M with the processor.
>
> Signed-off-by: Jul
Hi Ian,
On 20/02/15 15:38, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> When a device is marked for passthrough (via the new property
>> "xen,passthrough"),
>> dom0 must not access to the device (i.e not loading a driver), but should
>
> "must not access the de
On 20/02/15 15:42, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> @@ -919,8 +943,14 @@ static int make_timer_node(const struct domain *d, void
>> *fdt,
>> return res;
>> }
>>
>> -/* Map the device in the domain */
>> -static int map_device(struct domain *d,
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Each domain may have a different number of IRQs depending on the devices
> assigned to it.
>
> Rather re-using the number of IRQs used by the hardwared GIC, let the
^than and "hardware" (although "physical" might be better)
> toolst
On Wed, 2015-01-28 at 18:26 +, Stefano Stabellini wrote:
> > +int spi = irq - 32;
>
> unsigned int
and underflow?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 02/20/2015 11:27 AM, Jan Beulich wrote:
On 20.02.15 at 17:15, wrote:
On 02/20/2015 09:35 AM, Jan Beulich wrote:
On 16.02.15 at 23:26, wrote:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -437,6 +437,8 @@ int vcpu_initialise(struct vcpu *v)
vmce_init_vcpu(v);
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> With the addition of interrupt assignment to guest, we need to make sure
> the guest don't blow up the interrupt management in Xen.
s/don't/can't/
>
> Before associating the IRQ to a vIRQ we need to make sure:
> - the vIRQ is not alrea
>>> On 30.01.15 at 18:54, wrote:
> --- a/xen/arch/x86/shutdown.c
> +++ b/xen/arch/x86/shutdown.c
> @@ -504,7 +504,8 @@ void machine_restart(unsigned int delay_millisecs)
> tboot_shutdown(TB_SHUTDOWN_REBOOT);
> }
>
> -efi_reset_system(reboot_mode != 0);
> +if ( efi_platform
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Currently Xen only supports SPIs routing for guest, add a function
> is_assignable_irq to check if we can assign a given IRQ to the guest.
>
> Secondly, make sure the vIRQ is not the greater that the number of IRQs handle
> to the vGIC and i
On 02/20/2015 11:23 AM, Jan Beulich wrote:
On 20.02.15 at 17:04, wrote:
On 02/20/2015 08:59 AM, Jan Beulich wrote:
On 16.02.15 at 23:26, wrote:
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Actually Xen is assuming that the virtual IRQ will always be the same as IRQ.
s/Actually/Currently/?
> Modify route_guest_irq to take the virtual IRQ in parameter and let Xen
> assign a different IRQ number.
I think I must be misunderstand
>>> On 20.02.15 at 17:09, wrote:
> On 20/02/15 15:15, Ian Campbell wrote:
>> Jan, do you find any of that convincing as to the need for doing this
>> outside the the create domctl? Based on msg00522 is seems you would
>> prefer some HVM params over a new domctl?
>
> The problem with HVM params is
>>> On 20.02.15 at 16:15, wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> This is a follow-up of
> http://lists.xen.org/archives/html/xen-devel/2014-11/msg00522.html
>>
>> TODO: What about migration? For now the configuration lives in internal
>> libxl structure.
>>> On 20.02.15 at 17:15, wrote:
> On 02/20/2015 09:35 AM, Jan Beulich wrote:
> On 16.02.15 at 23:26, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -437,6 +437,8 @@ int vcpu_initialise(struct vcpu *v)
>>> vmce_init_vcpu(v);
>>> }
>>>
>>> +
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> @@ -919,8 +943,14 @@ static int make_timer_node(const struct domain *d, void
> *fdt,
> return res;
> }
>
> -/* Map the device in the domain */
> -static int map_device(struct domain *d, struct dt_device_node *dev)
> +/* For a given d
On 02/20/2015 10:03 AM, Jan Beulich wrote:
On 16.02.15 at 23:26, wrote:
+int pmu_nmi_interrupt(const struct cpu_user_regs *regs, int cpu)
static
+{
+return vpmu_do_interrupt(regs);
That function returning 1 makes do_nmi() not do _anything_ else, i.e.
ignore eventual SERR or IOCHK event
>>> On 20.02.15 at 17:04, wrote:
> On 02/20/2015 08:59 AM, Jan Beulich wrote:
> On 16.02.15 at 23:26, wrote:
>>> --- a/xen/arch/x86/hvm/svm/vpmu.c
>>> +++ b/xen/arch/x86/hvm/svm/vpmu.c
>>> @@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
>>> return 1;
>>> }
>>>
>>> On 30.01.15 at 18:54, wrote:
> We need more fine grained knowledge about EFI environment and check
> for EFI platform and EFI loader separately to properly support
> multiboot2 protocol.
... because of ... (i.e. I can't see from the description what the
separation is good for). Looking at the
On 02/20/2015 09:35 AM, Jan Beulich wrote:
On 16.02.15 at 23:26, wrote:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -437,6 +437,8 @@ int vcpu_initialise(struct vcpu *v)
vmce_init_vcpu(v);
}
+spin_lock_init(&v->arch.vpmu.vpmu_lock);
This would rather seem
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> When a device is marked for passthrough (via the new property
> "xen,passthrough"),
> dom0 must not access to the device (i.e not loading a driver), but should
"must not access the device (i.e. not load a driver)"
perhaps "should still be
Hi Ian,
On 20/02/15 15:15, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> On ARM the virtual GIC may differ between each guest (emulated GIC version,
>> number of SPIs...). Those informations are already known at the domain
>> creation
>
> "This information is al
>>> On 30.01.15 at 18:54, wrote:
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -1,6 +1,7 @@
> obj-bin-y += head.o
>
> -RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h
> $(BASEDIR)/include/xen/multiboot.h
> +RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h
> $(BAS
On 02/20/2015 08:59 AM, Jan Beulich wrote:
On 16.02.15 at 23:26, wrote:
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
return 1;
}
+static void amd_vpmu_unload(struct vpmu_struct *vpmu)
+{
On 02/20/2015 09:31 AM, Jan Beulich wrote:
On 16.02.15 at 23:26, wrote:
+long do_xenpmu_op(unsigned int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t)
arg)
+{
+int ret;
+struct xen_pmu_params pmu_params;
+
+if ( vpmu_disabled )
+return -EINVAL;
+
+ret = xsm_pmu_op(XSM_OT
On Fri, Feb 20, 2015 at 5:55 AM, David Vrabel wrote:
> On 18/02/15 10:12, Juergen Gross wrote:
>> On 02/18/2015 11:03 AM, David Vrabel wrote:
>>> On 17/02/15 07:39, Juergen Gross wrote:
If we have neither XEN_PV nor XEN_PVH set, why do we have to build
enlighten.c? It will never be
Each class can contains 32 permisions which are encoded on a word (one
bit per permission).
Currently the awk script will generate an hexadecimal value for each
permission. This may result to generate an invalid value on some version
of awk.
For instance debian jessie is using a version of mawk w
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> The check to avoid mapping disabled device in DOM0 was added in the
> anticipation
"disabled devices" and "in anticipation of device passthrough"
> of the device passthrough. But, a brand new property will be added later to
> mark
> devic
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> The structure pending_irq is initialized on the same way in 2 differents
"in the same way in 2 different places".
> place. Introduce vgic_init_pending_irq to avoid code duplication.
>
> Also move the setting of the irq field in this functi
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Flask code already provides an helper to copy a string from guest. In a later
"a helper".
> patch, the new DT hypercalls will need a similar function.
>
> To avoid code duplication, copy the flask helper (flask_copying_string) to
> common
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Currently the function to translate IRQ from the device tree is set
> unconditionally to be able to be able to retrieve serial/timer IRQ before the
> GIC has been initialized.
>
> It assumes that the xlate function won't never changed. We m
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Xen is only able to handle one GIC controller. Some platform may contain
> other interrupt controller.
"platforms" and "controllers"
> Make sure to only translate IRQ mapped into the GIC handled by Xen.
>
> Signed-off-by: Julien Grall
Ac
On Wed, 2015-01-28 at 16:09 +, Stefano Stabellini wrote:
> On Tue, 13 Jan 2015, Julien Grall wrote:
> > Currently the function to translate IRQ from the device tree is set
> > unconditionally to be able to be able to retrieve serial/timer IRQ before
> > the
> > GIC has been initialized.
> >
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> On ARM the virtual GIC may differ between each guest (emulated GIC version,
> number of SPIs...). Those informations are already known at the domain
> creation
"This information is already known at domain creation..."
> and can never chang
On 20/02/15 15:13, Manish Jaggi wrote:
>> On x86 you solve this because both Xen and dom0 can parse the same table
>> and reach the same answer, sadly DT doesn't have everything needed in
>> it.
> In fact xen and dom0 use the same device tree nodes and in the same
> order. xen creates the device tr
On 20/02/15 8:31 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 14:39 +, Jan Beulich wrote:
On 20.02.15 at 15:26, wrote:
On Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote:
Otherwise,
just sequentially assign segment numbers as you discover them or
get them reported by Dom0. You could e
The documentation around the recent 4.5 release is improving, but
there is still need for more clean-up. We still have a number of
pages which talk in terms of xend rather than libxenlight. For
example, check the TODO list (see below) for a list of pages which we
know still feature the "xm" comma
>>> On 20.02.15 at 16:01, wrote:
> On Fri, 2015-02-20 at 14:39 +, Jan Beulich wrote:
>> plus the MMCFG reporting one (PHYSDEVOP_pci_mmcfg_reserved).
>
> This looks promising, but rather under-documented.
>
> #define PHYSDEVOP_pci_mmcfg_reserved24
> struct physdev_pci_mmc
On 20/02/15 13:55, Ian Campbell wrote:
> On Fri, 2015-02-20 at 13:42 +, Julien Grall wrote:
- Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs.
This former is the field used to configure SRMS
Cc: Andreas Herrmann
Signed-off-by: Andreas Herrmann
>>> On 16.02.15 at 23:26, wrote:
> We don't need to try to destroy it since it can't be already allocated at the
> time we try to initialize it.
>
> Signed-off-by: Boris Ostrovsky
> Suggested-by: Andrew Cooper
> ---
> xen/arch/x86/hvm/vpmu.c | 6 ++
> 1 file changed, 2 insertions(+), 4 del
On Fri, Feb 20, 2015 at 3:21 PM, Balbir Singh wrote:
> [snip]
> On Fri, Feb 20, 2015 at 5:21 PM, Jan Beulich wrote:
>>> Thanks Jan! Is there a way for a memevents channel consumer to get
>>> access to the L1 (OS Page tables).
>>
>> Hardly.
>>
>>> I presume we'll need to walk the
>>> page tables,
On Fri, 2015-02-20 at 14:39 +, Jan Beulich wrote:
> >>> On 20.02.15 at 15:26, wrote:
> > On Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote:
> >> Otherwise,
> >> just sequentially assign segment numbers as you discover them or
> >> get them reported by Dom0. You could even have Dom0 tell you
>>> On 16.02.15 at 23:26, wrote:
> +int pmu_nmi_interrupt(const struct cpu_user_regs *regs, int cpu)
static
> +{
> +return vpmu_do_interrupt(regs);
That function returning 1 makes do_nmi() not do _anything_ else, i.e.
ignore eventual SERR or IOCHK events. That's not acceptable. I guess
you'
On Fri, Feb 20, 2015 at 01:34:16PM +, Julien Grall wrote:
> On 20/02/15 12:35, Ian Campbell wrote:
> > On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> >> From: Andreas Herrmann
> >>
> >> If DT information lists one stream ID twice for the master devices of
> >> an SMMU this can cause
>>> On 16.02.15 at 23:26, wrote:
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -100,65 +100,48 @@ void vpmu_lvtpc_update(uint32_t val)
> apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
> }
>
> -int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supp
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
> > Another option might be a new hypercall (assuming one doesn't already
> > exist) to register a PCI bus which would take e.g. the PCI CFG base
> > address and return a new u16 segment id to be used for all subsequent
> > PCI related calls. T
>>> On 20.02.15 at 15:26, wrote:
> On Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote:
>> Otherwise,
>> just sequentially assign segment numbers as you discover them or
>> get them reported by Dom0. You could even have Dom0 tell you
>> the segment numbers (just like we do on x86),
>
> Aha, how
>>> On 16.02.15 at 23:26, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -437,6 +437,8 @@ int vcpu_initialise(struct vcpu *v)
> vmce_init_vcpu(v);
> }
>
> +spin_lock_init(&v->arch.vpmu.vpmu_lock);
This would rather seem to belong into vpmu_initialize()
>>> On 16.02.15 at 23:26, wrote:
> +long do_xenpmu_op(unsigned int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t)
> arg)
> +{
> +int ret;
> +struct xen_pmu_params pmu_params;
> +
> +if ( vpmu_disabled )
> +return -EINVAL;
> +
> +ret = xsm_pmu_op(XSM_OTHER, current->domain, o
On Fri, 2015-02-20 at 14:15 +, Julien Grall wrote:
> On 20/02/15 14:13, Ian Campbell wrote:
> > On Fri, 2015-02-20 at 14:07 +, Julien Grall wrote:
> >> On 20/02/15 13:34, Ian Campbell wrote:
> >>> On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> @@ -2896,6 +2911,16 @@ static __
On Fri, 2015-02-20 at 14:19 +, Julien Grall wrote:
> > For v4 if you are able to shuffle some of the (almost-)acked helper
> > stuff (e.g. #6, #7, #8 here) to the front then those can likely be
> > applied straight away too.
>
> I could be able to move #6 before, but the other it would prefer
On Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote:
> >>> On 20.02.15 at 14:45, wrote:
> > (Jan, curious if you have any thoughts on this, hopefully I've left
> > sufficient context for you to get what we are on about, the gist is we
> > need some way for dom0 and Xen to agree on how a PCI segme
flight 34715 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34715/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 34629
Regressions which ar
[snip]
On Fri, Feb 20, 2015 at 5:21 PM, Jan Beulich wrote:
>> Thanks Jan! Is there a way for a memevents channel consumer to get
>> access to the L1 (OS Page tables).
>
> Hardly.
>
>> I presume we'll need to walk the
>> page tables, I suspect the current access_op is broken without it and
>> may n
Hi Ian,
On 20/02/15 14:15, Ian Campbell wrote:
> On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
>
> I've applied the first four here:
> fda2934 xen/arm: device: Rename device_type into device_class
> 100f2a6 xen/dt: Extend dt_device_match to possibly store data
> 62d4269 xen/arm: vgic: Dr
flight 34755 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34755/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 33391
Tests which did not succe
On 20/02/15 7:15 pm, Ian Campbell wrote:
(Jan, curious if you have any thoughts on this, hopefully I've left
sufficient context for you to get what we are on about, the gist is we
need some way for dom0 and Xen to agree on how a PCI segment ID maps to
an actual PCI root controller, I think on x8
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
I've applied the first four here:
fda2934 xen/arm: device: Rename device_type into device_class
100f2a6 xen/dt: Extend dt_device_match to possibly store data
62d4269 xen/arm: vgic: Drop unecessary include asm/device.h
256bdee xen/arm: gic-v2:
On 20/02/15 14:13, Ian Campbell wrote:
> On Fri, 2015-02-20 at 14:07 +, Julien Grall wrote:
>> On 20/02/15 13:34, Ian Campbell wrote:
>>> On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
@@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct
dt_device_node *dev,
On Fri, 2015-02-20 at 14:07 +, Julien Grall wrote:
> On 20/02/15 13:34, Ian Campbell wrote:
> > On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
> >> @@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct
> >> dt_device_node *dev,
> >>if ( !rc )
> >>iommu_set_op
>>> On 16.02.15 at 23:26, wrote:
> Move some VPMU initilization operations into __initcalls to avoid performing
> same tests and calculations for each vcpu.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-dev
>>> On 20.02.15 at 14:45, wrote:
> (Jan, curious if you have any thoughts on this, hopefully I've left
> sufficient context for you to get what we are on about, the gist is we
> need some way for dom0 and Xen to agree on how a PCI segment ID maps to
> an actual PCI root controller, I think on x86
On Thu, Feb 12, 2015 at 07:19:13PM +0800, Ard Biesheuvel wrote:
> While Xen on Intel uses a virtual PCI device to communicate the
> base address of the grant table, the ARM implementation uses a DT
> node, which is fundamentally incompatible with the way XenBusDxe is
> implemented, i.e., as a UEFI
On Tue, 2015-02-17 at 15:29 +, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 20/02/15 13:34, Ian Campbell wrote:
> On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
>> @@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct
>> dt_device_node *dev,
>> if ( !rc )
>> iommu_set_ops(&arm_smmu_iommu_ops);
>>
>> +/*
>> + * The last add
On Fri, 2015-02-20 at 13:53 +, Julien Grall wrote:
> On 20/02/15 13:47, Ian Campbell wrote:
> > On Fri, 2015-02-20 at 12:53 +, Julien Grall wrote:
> > The main thing I'm worried about is if the bisector is searching a range
> > which includes this change looking for some unrelated change an
On 20/02/15 14:06, Ian Campbell wrote:
> On Fri, 2015-02-20 at 13:53 +, Julien Grall wrote:
>> On 20/02/15 13:47, Ian Campbell wrote:
>>> On Fri, 2015-02-20 at 12:53 +, Julien Grall wrote:
>>> The main thing I'm worried about is if the bisector is searching a range
>>> which includes this c
On Fri, 2015-02-20 at 13:55 +, Andrew Cooper wrote:
> >
> > It's a bit of a shame that callers which don't care about specific
> > pollhup handling have to provide two practically identical handlers.
>
> Up until this patch, all users either provided no POLLHUP handler, or
> provided the same
On 20/02/15 13:29, Ian Campbell wrote:
> On Mon, 2015-02-09 at 23:40 +0800, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 06/02/2015 21:20, Stefano Stabellini wrote:
>>> On Fri, 30 Jan 2015, Julien Grall wrote:
-static int force_stage;
-module_param_named(force_stage, force_stage, int, S_IR
>>> On 16.02.15 at 23:26, wrote:
> --- a/xen/arch/x86/hvm/svm/vpmu.c
> +++ b/xen/arch/x86/hvm/svm/vpmu.c
> @@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
> return 1;
> }
>
> +static void amd_vpmu_unload(struct vpmu_struct *vpmu)
> +{
> +struct vcpu *v;
> +
> +
1 - 100 of 188 matches
Mail list logo
