>>> On 20.01.16 at 18:17, wrote:
>
> On 01/21/2016 01:07 AM, Jan Beulich wrote:
> On 20.01.16 at 16:29, wrote:
>>> On 01/20/2016 07:20 PM, Jan Beulich wrote:
To answer this I need to have my understanding of the partitioning
being done by firmware confirmed: If that's the case, th
On 01/21/2016 04:18 PM, Jan Beulich wrote:
On 20.01.16 at 18:17, wrote:
On 01/21/2016 01:07 AM, Jan Beulich wrote:
On 20.01.16 at 16:29, wrote:
On 01/20/2016 07:20 PM, Jan Beulich wrote:
To answer this I need to have my understanding of the partitioning
being done by firmware confirmed
El 20/01/16 a les 22.33, Luis R. Rodriguez ha escrit:
> On Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk
> wrote:
>>> +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn)
>>> +{
>>> + if (!fn->supp_hardware_subarch) {
>>> + pr_err("Init sequence fails to declares
>>> On 21.01.16 at 09:25, wrote:
> On 01/21/2016 04:18 PM, Jan Beulich wrote:
>> Yes. But then - other than you said above - it still looks to me as
>> if the split between PMEM and PBLK is arranged for by firmware?
>
> Yes. But OS/Hypervisor is not excepted to dynamically change its configure
>
> > +spin_lock_irqsave(&per_cpu(pi_blocked_vcpu_lock, pi_block_cpu),
> flags);
> > +
> > +/*
> > + * v->arch.hvm_vmx.pi_block_cpu == NR_CPUS here means the vCPU
> was
> > + * removed from the blocking list while we are acquiring the lock.
> > + */
> > +if ( v->arch.hvm_vmx.
Hi Jan,
On Thu, Jan 21, 2016 at 12:53:01AM -0700, Jan Beulich wrote:
On 21.01.16 at 02:29, wrote:
>> The platform device passthrough part for arm is to mapping the machine io
>> address
>> to the guest physical io address. Then guest can map the phsical io address
>> to its
>> own virtual
On 01/21/2016 04:53 PM, Jan Beulich wrote:
On 21.01.16 at 09:25, wrote:
On 01/21/2016 04:18 PM, Jan Beulich wrote:
Yes. But then - other than you said above - it still looks to me as
if the split between PMEM and PBLK is arranged for by firmware?
Yes. But OS/Hypervisor is not excepted to d
On 21/01/16 09:10, Xiao Guangrong wrote:
>
>
> On 01/21/2016 04:53 PM, Jan Beulich wrote:
> On 21.01.16 at 09:25, wrote:
>>> On 01/21/2016 04:18 PM, Jan Beulich wrote:
Yes. But then - other than you said above - it still looks to me as
if the split between PMEM and PBLK is arranged f
On Wed, 2016-01-20 at 11:16 -0700, Jim Fehlig wrote:
> Ian Campbell wrote:
> > ... and consolidate the cmdline/extra/root parsing to facilitate doing
> > so.
> >
> > The logic is the same as xl's parse_cmdline from the current xen.git
> > master
> > branch (e6f0e099d2c17de47fd86e817b1998db903cab61
On Wed, 2016-01-20 at 19:33 +0100, Roger Pau Monné wrote:
> El 20/01/16 a les 14.01, Ian Campbell ha escrit:
> > On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote:
> > > Allow enabling or disabling emulated devices from the libxl domain
> > > configuration file. For HVM guests with a device
On Thu, 2016-01-21 at 07:49 +0100, Juergen Gross wrote:
> On 21/01/16 07:31, Platform Team regression test user wrote:
> > This run is configured for baseline tests only.
> >
> > flight 38676 xen-4.5-testing real [real]
> > http://osstest.xs.citrite.net/~osstest/testlogs/logs/38676/
>
> I've seen
El 21/01/16 a les 10.39, Ian Campbell ha escrit:
> On Wed, 2016-01-20 at 19:33 +0100, Roger Pau Monné wrote:
>> El 20/01/16 a les 14.01, Ian Campbell ha escrit:
>>> On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote:
Allow enabling or disabling emulated devices from the libxl domain
On Thu, 2016-01-21 at 00:35 -0700, Jan Beulich wrote:
> > > > On 20.01.16 at 18:36, wrote:
> > (As a side --- XSA-163 says that VPMU is "unsupported security-wise".
> > Do
> > we make any distinction between a feature being generally or
> > security-wise unsupported?)
>
> Not sure; considering
On Wed, 2016-01-20 at 15:16 +, Ian Campbell wrote:
> On Wed, 2016-01-20 at 10:10 -0500, Boris Ostrovsky wrote:
> > On 01/20/2016 10:02 AM, David Vrabel wrote:
> > > On 20/01/16 14:52, Ian Campbell wrote:
> > > > On Wed, 2016-01-20 at 09:40 -0500, Boris Ostrovsky wrote:
> > > > > On 01/20/2016 0
On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote:
>
> To platform device of ARM, hypervisor is responsible for the mapping
> between machine address and guest physical address, also responsible
> for the irq mapping.
>
> But to embedded ARM SoC, the hardware clk IP is handled in Dom0.
Arguably
As suggested in a previous thread [0] this patch adds some missing calls
to libxl_dominfo_{init,dispose} when doing some of the libxl_domain_info
operations which would otherwise lead to memory leaks.
[0]
https://www.redhat.com/archives/libvir-list/2015-September/msg00519.html
Signed-off-by: Joao
On 01/21/2016 01:41 AM, Jim Fehlig wrote:
> Joao Martins wrote:
>> As suggested in a previous thread [0] this patch adds some missing calls
>> to libxl_dominfo_dispose when doing some of the libxl_domain_info
>> operations which would otherwise lead to memory leaks.
>>
>> [0]
>> https://www.redha
>>> On 21.01.16 at 09:59, wrote:
> uart2 needs clock IMX7D_UART2_ROOT_CLK from the ccm.
> passthrough uart2, hypervisor handles the reg and interrupts, that is
> because
> hypervisor handles the memory map and the interrupt controller(GIC). But
> here
> CCM is not handled by hypervisor, it is ha
>>> On 21.01.16 at 10:10, wrote:
> On 01/21/2016 04:53 PM, Jan Beulich wrote:
> On 21.01.16 at 09:25, wrote:
>>> On 01/21/2016 04:18 PM, Jan Beulich wrote:
Yes. But then - other than you said above - it still looks to me as
if the split between PMEM and PBLK is arranged for by firmw
On Thu, Jan 21, 2016 at 10:12:27AM +, Ian Campbell wrote:
[...]
> > I've asked the reporter to send logs for the 4.4 case to xen-devel.
>
> User confirmed[0] that 4.4 is actually OK.
>
> Did someone request stable backports yet, or shall I do so?
>
I vaguely remember we requested backport f
>>> On 21.01.16 at 10:29, wrote:
> On 21/01/16 09:10, Xiao Guangrong wrote:
>> I am not sure if i have understood your point. What your suggestion is
>> that
>> leave PMEM for hypervisor and all other parts (PBLK and _DSM handling) to
>> Dom0? If yes, we should:
>> a) handle hotplug in hypervisor
[RFC] VirtFS support on Xen
# Introduction
QEMU/KVM supports file system passthrough via an interface called
VirtFS [0]. VirtFS is in turn implemented with 9pfs protocol [1] and
VirtIO transport.
Xen used to have its own implementation of file system passthrough
called XenFS, but that has been i
On Thu, 2016-01-21 at 11:01 +0100, Roger Pau Monné wrote:
> El 21/01/16 a les 10.39, Ian Campbell ha escrit:
> > > If we don't have that guarantee I think this is already a bug, and we
> > > should call _setdefault before sending the domain info to the other end.
> > > In fact I have a patch that d
>>> On 21.01.16 at 10:05, wrote:
>> > +spin_lock_irqsave(&per_cpu(pi_blocked_vcpu_lock, pi_block_cpu),
>> flags);
>> > +
>> > +/*
>> > + * v->arch.hvm_vmx.pi_block_cpu == NR_CPUS here means the vCPU
>> was
>> > + * removed from the blocking list while we are acquiring the lock.
>>
On Thu, 2016-01-21 at 10:25 +, Wei Liu wrote:
> On Thu, Jan 21, 2016 at 10:12:27AM +, Ian Campbell wrote:
> [...]
> > > I've asked the reporter to send logs for the 4.4 case to xen-devel.
> >
> > User confirmed[0] that 4.4 is actually OK.
> >
> > Did someone request stable backports yet,
On 23/12/15 21:06, Julia Lawall wrote:
> The cleancache_ops structure is never modified, so declare it as const.
>
> This also removes the __read_mostly declaration on the cleancache_ops
> variable declaration, since it seems redundant with const.
>
> Done with the help of Coccinelle.
>
> Signed
On 21/01/16 10:28, Wei Liu wrote:
> [RFC] VirtFS support on Xen
>
> # Introduction
>
> QEMU/KVM supports file system passthrough via an interface called
> VirtFS [0]. VirtFS is in turn implemented with 9pfs protocol [1] and
> VirtIO transport.
>
> Xen used to have its own implementation of file
On 21/01/16 11:00, Ian Campbell wrote:
> On Thu, 2016-01-21 at 07:49 +0100, Juergen Gross wrote:
>> On 21/01/16 07:31, Platform Team regression test user wrote:
>>> This run is configured for baseline tests only.
>>>
>>> flight 38676 xen-4.5-testing real [real]
>>> http://osstest.xs.citrite.net/~os
On Thu, Jan 21, 2016 at 10:37:51AM +, Ian Campbell wrote:
> On Thu, 2016-01-21 at 10:25 +, Wei Liu wrote:
> > On Thu, Jan 21, 2016 at 10:12:27AM +, Ian Campbell wrote:
> > [...]
> > > > I've asked the reporter to send logs for the 4.4 case to xen-devel.
> > >
> > > User confirmed[0] th
>>> On 20.01.16 at 22:47, wrote:
> This consolidates some of the different variables used for the ARM
> builds. This change was prompted by the Kconfig changes but looking back
> in time the CONFIG_ARM_{32,64} variables existed before Kconfig so this
> should just be a generic cleanup.
>
> Signed
On 20/01/16 12:23, Ian Campbell wrote:
> There have been a few reports recently[0] which relate to a failure of
> netfront to allocate sufficient grant refs for all the queues:
>
> [0.533589] xen_netfront: can't alloc rx grant refs
> [0.533612] net eth0: only created 31 queues
>
> Which c
On Thu, Jan 21, 2016 at 10:50:08AM +, David Vrabel wrote:
> On 21/01/16 10:28, Wei Liu wrote:
> > [RFC] VirtFS support on Xen
> >
> > # Introduction
> >
> > QEMU/KVM supports file system passthrough via an interface called
> > VirtFS [0]. VirtFS is in turn implemented with 9pfs protocol [1] a
On Thu, 21 Jan 2016, David Vrabel wrote:
> On 23/12/15 21:06, Julia Lawall wrote:
> > The cleancache_ops structure is never modified, so declare it as const.
> >
> > This also removes the __read_mostly declaration on the cleancache_ops
> > variable declaration, since it seems redundant with cons
>>> On 20.01.16 at 21:10, wrote:
> First of all, SMEP and SMAP. 32bit PV guests are subject to Xen's
> SMEP/SMAP choices, because of running in ring 1.
>
> SMAP in particular is problematic because older Linux guests do fall
> foul of it; they don't understand what a SMAP pagefault is, and enter
El 21/01/16 a les 11.29, Ian Campbell ha escrit:
> On Thu, 2016-01-21 at 11:01 +0100, Roger Pau Monné wrote:
>> El 21/01/16 a les 10.39, Ian Campbell ha escrit:
It also means that HVMlite guests created with current Xen will be
capable of migrating to newer version of Xen, that might have
flight 38678 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38678/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3863 host-install(3) broken REG
On 21/01/16 11:07, Jan Beulich wrote:
On 20.01.16 at 21:10, wrote:
>> First of all, SMEP and SMAP. 32bit PV guests are subject to Xen's
>> SMEP/SMAP choices, because of running in ring 1.
>>
>> SMAP in particular is problematic because older Linux guests do fall
>> foul of it; they don't und
flight 78620 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78620/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail like 77671
test-amd64-i386-xl-qemuu-w
On Thu, Jan 21, 2016 at 11:01:43AM +0100, Roger Pau Monné wrote:
> El 21/01/16 a les 10.39, Ian Campbell ha escrit:
> > On Wed, 2016-01-20 at 19:33 +0100, Roger Pau Monné wrote:
> >> El 20/01/16 a les 14.01, Ian Campbell ha escrit:
> >>> On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote:
> >
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Paul Durrant
> Sent: 20 January 2016 13:14
> To: Ian Campbell; xen-de...@lists.xenproject.org
> Cc: Ian Jackson; Keir (Xen.org); Jan Beulich; Tim (Xen.org)
> Subject: Re: [X
On Tue, Jan 19, 2016 at 09:43:59PM +0800, Shannon Zhao wrote:
>
> On 2016/1/19 21:13, Mark Rutland wrote:
> >On Tue, Jan 19, 2016 at 12:23:17PM +, Stefano Stabellini wrote:
> >>>On Tue, 19 Jan 2016, Mark Rutland wrote:
> >On Tue, Jan 19, 2016 at 06:25:25PM +0800, Shannon Zhao wrote:
> >>>
On Thu, 2016-01-21 at 11:48 +, Paul Durrant wrote:
> > -Original Message-
> > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> > boun...@lists.xen.org] On Behalf Of Paul Durrant
> > Sent: 20 January 2016 13:14
> > To: Ian Campbell; xen-de...@lists.xenproject.org
> > Cc: Ian Ja
Hi Dave,
Please could you queue these three:
32a8440 xen-netfront: respect user provided max_queues
4c82ac3 xen-netback: respect user provided max_queues
ca88ea1 xen-netfront: update num_queues to real created
for stable backports to at least 4.1. Multiqueue was added in v3.16 so I
think they co
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 21 January 2016 11:59
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Ian Jackson; Keir (Xen.org); Jan Beulich; Tim (Xen.org)
> Subject: Re: [Xen-devel] [PATCH] public/io/netif.h: change semantics of
On Tue, Jan 19, 2016 at 08:10:07PM -0700, Jim Fehlig wrote:
> On 01/19/2016 11:11 AM, Ian Jackson wrote:
> > Chunyan Liu writes ("[PATCH V13 5/5] xl: add pvusb commands"):
> >> Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
> >> usbdev-attach and usbdev-detach.
> > Thanks for swappin
Hi Ian,
On Thu, Jan 21, 2016 at 10:19:32AM +, Ian Campbell wrote:
>On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote:
>>
>> To platform device of ARM, hypervisor is responsible for the mapping
>> between machine address and guest physical address, also responsible
>> for the irq mapping.
>>
On Thu, 2016-01-21 at 12:12 +, Wei Liu wrote:
> On Tue, Jan 19, 2016 at 08:10:07PM -0700, Jim Fehlig wrote:
> > On 01/19/2016 11:11 AM, Ian Jackson wrote:
> > > Chunyan Liu writes ("[PATCH V13 5/5] xl: add pvusb commands"):
> > > > Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
>
On Thu, 2016-01-21 at 10:56 +, David Vrabel wrote:
> On 20/01/16 12:23, Ian Campbell wrote:
> > There have been a few reports recently[0] which relate to a failure of
> > netfront to allocate sufficient grant refs for all the queues:
> >
> > [0.533589] xen_netfront: can't alloc rx grant re
On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> Hi Ian,
>
> On Thu, Jan 21, 2016 at 10:19:32AM +, Ian Campbell wrote:
> > On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote:
> > >
> > > To platform device of ARM, hypervisor is responsible for the mapping
> > > between machine address and
Hi Jan,
On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote:
On 21.01.16 at 09:59, wrote:
>> uart2 needs clock IMX7D_UART2_ROOT_CLK from the ccm.
>> passthrough uart2, hypervisor handles the reg and interrupts, that is
>> because
>> hypervisor handles the memory map and the interrup
On Thu, Jan 21, 2016 at 12:21:11PM +, Ian Campbell wrote:
> On Thu, 2016-01-21 at 12:12 +, Wei Liu wrote:
> > On Tue, Jan 19, 2016 at 08:10:07PM -0700, Jim Fehlig wrote:
> > > On 01/19/2016 11:11 AM, Ian Jackson wrote:
> > > > Chunyan Liu writes ("[PATCH V13 5/5] xl: add pvusb commands"):
>
... and consolidate the cmdline/extra/root parsing to facilitate doing
so.
The logic is the same as xl's parse_cmdline from the current xen.git master
branch (e6f0e099d2c17de47fd86e817b1998db903cab61).
On the formatting side switch to producing cmdline= instead of extra=.
Update a few tests and
flight 78597 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78597/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 78509 pass
in 78597
test-armhf-armhf-xl-rtd
On 01/20/2016 09:59 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 01, 2015 at 11:32:58PM +0100, Marek Marczykowski-Górecki wrote:
>> On Tue, Dec 01, 2015 at 05:00:42PM -0500, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Nov 17, 2015 at 03:45:15AM +0100, Marek Marczykowski-Górecki wrote:
On Wed,
Hi Ian,
On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
>On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
>> Hi Ian,
>>
>> On Thu, Jan 21, 2016 at 10:19:32AM +, Ian Campbell wrote:
>> > On Thu, 2016-01-21 at 16:59 +0800, Peng Fan wrote:
>> > >
>> > > To platform device of AR
On Thu, 2016-01-21 at 20:35 +0800, Peng Fan wrote:
> On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
> > Would adding a dummy fixed-clock[0] (or several of them) to the guest
> > passthrough DT satisfy the driver's requirements? They would be hardcoded
> > to whatever rate dom0 and/or
>>> On 21.01.16 at 13:06, wrote:
> On Thu, Jan 21, 2016 at 03:21:38AM -0700, Jan Beulich wrote:
> On 21.01.16 at 09:59, wrote:
>>> uart2 needs clock IMX7D_UART2_ROOT_CLK from the ccm.
>>> passthrough uart2, hypervisor handles the reg and interrupts, that is
>>> because
>>> hypervisor handles
On Thu, 21 Jan 2016, Peng Fan wrote:
> Hi Ian,
>
> On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
> >On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> >> Hi Ian,
> >>
> >> On Thu, Jan 21, 2016 at 10:19:32AM +, Ian Campbell wrote:
> >> > On Thu, 2016-01-21 at 16:59 +0800, Peng
>>> On 21.01.16 at 12:16, wrote:
> On 21/01/16 11:07, Jan Beulich wrote:
> On 20.01.16 at 21:10, wrote:
>>> First of all, SMEP and SMAP. 32bit PV guests are subject to Xen's
>>> SMEP/SMAP choices, because of running in ring 1.
>>>
>>> SMAP in particular is problematic because older Linux gue
On Thu, 2016-01-21 at 12:55 +, Stefano Stabellini wrote:
> On Thu, 21 Jan 2016, Peng Fan wrote:
> > Hi Ian,
> >
> > On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
> > > On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> > > > Hi Ian,
> > > >
> > > > On Thu, Jan 21, 2016 at 10
On 21/01/16 12:59, Jan Beulich wrote:
>>
For the PTE bits, _PAGE_GNTTAB (bit 62) is used exclusively in debug
build (so there is a guest observable difference between running on a
debug and a non-debug Xen), and the comment beside it even identifies
that it breaks BSD guests. P
On 01/21/2016 03:38 AM, Roger Pau Monné wrote:
El 20/01/16 a les 22.33, Luis R. Rodriguez ha escrit:
On Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk
wrote:
+static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn)
+{
+ if (!fn->supp_hardware_subarch) {
+ pr_err("
>>> On 21.01.16 at 14:17, wrote:
> On 21/01/16 12:59, Jan Beulich wrote:
>>>
> For the PTE bits, _PAGE_GNTTAB (bit 62) is used exclusively in debug
> build (so there is a guest observable difference between running on a
> debug and a non-debug Xen), and the comment beside it even ident
On 01/21/16 03:25, Jan Beulich wrote:
> >>> On 21.01.16 at 10:10, wrote:
> > On 01/21/2016 04:53 PM, Jan Beulich wrote:
> > On 21.01.16 at 09:25, wrote:
> >>> On 01/21/2016 04:18 PM, Jan Beulich wrote:
> Yes. But then - other than you said above - it still looks to me as
> if the sp
On 21/01/16 12:19, Ian Campbell wrote:
> On Thu, 2016-01-21 at 10:56 +, David Vrabel wrote:
>> On 20/01/16 12:23, Ian Campbell wrote:
>>> There have been a few reports recently[0] which relate to a failure of
>>> netfront to allocate sufficient grant refs for all the queues:
>>>
>>> [0.5335
On 21/01/16 13:17, Andrew Cooper wrote:
>
> As we see with the Protection Key feature, newer hardware feature start
> using bits which were previously software available, and we absolutely
> don't want to be in a position where our ABI prevents us from ever
> supporting a new feature.
I don't see
On 21/01/16 14:29, David Vrabel wrote:
> On 21/01/16 13:17, Andrew Cooper wrote:
>> As we see with the Protection Key feature, newer hardware feature start
>> using bits which were previously software available, and we absolutely
>> don't want to be in a position where our ABI prevents us from ever
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-win7-amd64
testid windows-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git
On 21/01/16 14:37, Andrew Cooper wrote:
>> I think we should document the PV ABI as-is. i.e., that these two PTE
>> bits are not available for PV guest use.
>
> This is already known to break some guests. It shouldn't stay as it
> currently is.
It's unfortunate that the current ABI is incompati
>>> On 21.01.16 at 15:01, wrote:
> On 01/21/16 03:25, Jan Beulich wrote:
>> >>> On 21.01.16 at 10:10, wrote:
>> > b) some _DSMs control PMEM so you should filter out these kind of _DSMs and
>> > handle them in hypervisor.
>>
>> Not if (see above) following the model we currently have in plac
On 2016/1/21 9:17, David Vrabel wrote:
On 21/01/16 12:19, Ian Campbell wrote:
On Thu, 2016-01-21 at 10:56 +, David Vrabel wrote:
On 20/01/16 12:23, Ian Campbell wrote:
There have been a few reports recently[0] which relate to a failure of
netfront to allocate sufficient grant refs for all
On 21/01/16 13:55, Jan Beulich wrote:
I was intending to have CONFIG_PV_PTE_DEBUG as an EXPERT option,
disabled by default even in debug builds.
There should not be an ABI difference between release and "normal" debug
builds.
>>> Well, I see your point, but as said above I
On Wed, 2016-01-20 at 03:06 -0700, Jan Beulich wrote:
> > > > On 19.01.16 at 20:55, wrote:
> >
> > $ 'addr2line -e xen-syms 82d0801c1cce' returns
> > 'xen/xen/arch/x86/xstate.c:387' which again points to
> > xsave. Also, adding 'xsave=0' makes it boot just fine.
>
> Ah, I think I see the iss
On Fri, 2015-12-18 at 14:09 +, David Vrabel wrote:
> atomic_compareandswap() used atomic_t as the new, old and returned
> values which is less convinient than using just int.
"convenient"
diff --git a/xen/include/asm-arm/atomic.h b/xen/include/asm-arm/atomic.h
> index 5a38c67..29ab265 100644
On Fri, 2015-12-18 at 16:08 +, Malcolm Crossley wrote:
> diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
> index 71e7649..c308a56 100644
> --- a/xen/include/asm-arm/percpu.h
> +++ b/xen/include/asm-arm/percpu.h
> @@ -27,6 +27,11 @@ void percpu_init_areas(void);
> #defi
On Thu, Jan 21, 2016 at 8:44 PM, Dario Faggioli
wrote:
> On Wed, 2016-01-20 at 03:06 -0700, Jan Beulich wrote:
>> > > > On 19.01.16 at 20:55, wrote:
>> >
>> > $ 'addr2line -e xen-syms 82d0801c1cce' returns
>> > 'xen/xen/arch/x86/xstate.c:387' which again points to
>> > xsave. Also, adding 'xs
On Wed, 2016-01-20 at 12:50 +, Paul Durrant wrote:
> My patch b2700877 "move and amend multicast control documentation"
> clarified use of the multicast control protocol between frontend and
> backend. However, it transpires that the restrictions that documentation
> placed on the "request-mult
On Fri, 2015-12-18 at 16:08 +, Malcolm Crossley wrote:
>
> xen/arch/arm/mm.c | 4 +-
[...]
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 47bfb27..81f9e2e 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1055,7 +1055,7 @@ int xenmem_add_to_physmap_on
El 21/01/16 a les 16.29, Ian Campbell ha escrit:
> On Wed, 2016-01-20 at 12:50 +, Paul Durrant wrote:
>> My patch b2700877 "move and amend multicast control documentation"
>> clarified use of the multicast control protocol between frontend and
>> backend. However, it transpires that the restric
On Thu, Jan 21, 2016 at 03:29:36PM +, Ian Campbell wrote:
> On Wed, 2016-01-20 at 12:50 +, Paul Durrant wrote:
> > My patch b2700877 "move and amend multicast control documentation"
> > clarified use of the multicast control protocol between frontend and
> > backend. However, it transpires
On Thu, Jan 21, 2016 at 04:35:40PM +0100, Roger Pau Monné wrote:
> El 21/01/16 a les 16.29, Ian Campbell ha escrit:
> > On Wed, 2016-01-20 at 12:50 +, Paul Durrant wrote:
> >> My patch b2700877 "move and amend multicast control documentation"
> >> clarified use of the multicast control protocol
The cleancache_ops structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
v2: put back the read mostly
drivers/xen/tmem.c |2 +-
include/linux/cleancache.h |2 +-
mm/cleancache.c|4 ++--
3 files c
El 21/01/16 a les 12.31, Wei Liu ha escrit:
> On Thu, Jan 21, 2016 at 11:01:43AM +0100, Roger Pau Monné wrote:
>> El 21/01/16 a les 10.39, Ian Campbell ha escrit:
>>> On Wed, 2016-01-20 at 19:33 +0100, Roger Pau Monné wrote:
El 20/01/16 a les 14.01, Ian Campbell ha escrit:
> On Wed, 2016-0
On Thu, 21 Jan 2016, Ian Campbell wrote:
> On Thu, 2016-01-21 at 12:55 +, Stefano Stabellini wrote:
> > On Thu, 21 Jan 2016, Peng Fan wrote:
> > > Hi Ian,
> > >
> > > On Thu, Jan 21, 2016 at 12:26:04PM +, Ian Campbell wrote:
> > > > On Thu, 2016-01-21 at 19:55 +0800, Peng Fan wrote:
> > > >
> On January 20, 2016 at 7:29 pm, wrote:
> >>> On 20.01.16 at 11:26, wrote:
> >> On January 15, 2016 at 9:10, wrote:
> >> >>> On 23.12.15 at 09:25, wrote:
> >> > @@ -229,6 +239,63 @@ int qinval_device_iotlb(struct iommu *iommu,
> >> > return 0;
> >> > }
> >> >
> >> > +static void dev_inv
Ian Campbell wrote:
> On Wed, 2016-01-20 at 11:16 -0700, Jim Fehlig wrote:
>> Ian Campbell wrote:
>>> ... and consolidate the cmdline/extra/root parsing to facilitate doing
>>> so.
>>>
>>> The logic is the same as xl's parse_cmdline from the current xen.git
>>> master
>>> branch (e6f0e099d2c17de47f
flight 78659 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78659/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saver
flight 78649 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78649/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 65543
test-amd64-amd64-
>>> On 21.01.16 at 17:16, wrote:
>> On January 20, 2016 at 7:29 pm, wrote:
>> >>> On 20.01.16 at 11:26, wrote:
>> >> On January 15, 2016 at 9:10, wrote:
>> >> >>> On 23.12.15 at 09:25, wrote:
>> >> > @@ -229,6 +239,63 @@ int qinval_device_iotlb(struct iommu *iommu,
>> >> > return 0;
>>
>>> On 20.01.16 at 16:01, wrote:
> Initially reported to debian
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810964), redirected here:
>
> With AMD Opteron 6xxx processors, half of the memory controllers are
> missing from /sys/devices/system/edac/mc
> Checked with single 6120 (dual memory
>>> On 16.12.15 at 22:24, wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -278,11 +278,16 @@ unsigned int xstate_ctxt_size(u64 xcr0)
> /* Collect the information of processor's extended state */
> void xstate_init(struct cpuinfo_x86 *c)
> {
> +static bool_t __initdat
This fixes the fallout from the HVMlite series, that removed the emulated
PIT from PV(H) guests. Also, this patch forces the hardware domain to
always have an emulated PIT, regardless of whether the toolstack specified
one or not.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Coo
Current implementation of elf_load_bsdsyms is broken when loading inside of
a HVM guest, because it assumes elf_memcpy_safe is able to write into guest
memory space, which it is not.
Take the oportunity to do some cleanup and properly document how
elf_{parse/load}_bsdsyms works. The new implementa
libxl__arch_domain_prepare_config has access to the libxl_domain_build_info
struct, so make sure it's properly initialised. Note that prepare_config is
called from within libxl__domain_make.
This is not a bug at the moment, because prepare_config doesn't access
libxl_domain_build_info yet, but thi
Hello,
The series is sorted in the following way:
- Patch 1 is a preparatory patch for Dom0 HVMlite support.
- Patch 4 is a fix from a fallout introduced by the HVMlite series, which
inadvertently disabled the emulated PIT that was added to PV(H) guests.
- Patches 2, 3 and 5 expand the field
Add a new HVM-specific feature flag that signals the presence of a bitmap
that contains the current set of enabled emulated devices. The bitmap is
placed in the ecx register. The bit fields used in the bitmap are the same
as the ones used in the xen_arch_domainconfig emulation_flags field, and
thei
Joao Martins wrote:
> As suggested in a previous thread [0] this patch adds some missing calls
> to libxl_dominfo_{init,dispose} when doing some of the libxl_domain_info
> operations which would otherwise lead to memory leaks.
>
> [0]
> https://www.redhat.com/archives/libvir-list/2015-September/ms
Allow enabling or disabling emulated devices from the libxl domain
configuration file. For HVM guests with a device model all the emulated
devices are enabled. For HVM guests without a device model no devices are
enabled by default, although they can be enabled using the options provided.
The arbit
And use it as the default value for the VGA kind. This allows libxl to set
it to the default value later on when the domain type is known. For HVM
guests the default value is LIBXL_VGA_INTERFACE_TYPE_CIRRUS while for
HVMlite the default value is LIBXL_VGA_INTERFACE_TYPE_NONE.
Signed-off-by: Roger
From: Cao jin
To catch the error message. Also modify the caller
Signed-off-by: Cao jin
Reviewed-by: Eric Blake
Reviewed-by: Stefano Stabellini
---
hw/xen/xen_pt.c |8 ---
hw/xen/xen_pt.h |2 +-
hw/xen/xen_pt_config_init.c | 51 +++---
1 - 100 of 173 matches
Mail list logo
