On Thu, Sep 3, 2015 at 9:55 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K
>>
>> Store number of lpis and number of id bits
>> in vgic structure
>>
>> Signed-off-by: Vijaya Kumar K
>> ---
>> xen/arch/arm/irq.c |9 ++
>>> On 04.09.15 at 10:53, wrote:
> I have set the adhoc bisector working on the ~200 commits between rc3 and
> rc4. It's running in the Citrix instance (which is quieter) so the interim
> results are only visible within our network at http://osstest.xs.citrite.ne
> t/~osstest/testlogs/results-adh
>>> On 06.09.15 at 22:05, wrote:
> The original implementation of populate_pfns didn't consider the same
> pfn can be present multiple times in the array. The mechanism to prevent
> populating the same pfn multiple times only worked if the recurring pfn
> appeared in different batches.
>
> This b
flight 61421 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61421/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 3 host-install(3) broken REGR. vs. 60666
b
Hi,
I'm tring to hibernate an x86 HVM guest with 1TB ram,
[1.VM config]
builder = "hvm"
name = "suse12_sp3"
memory = 1048576
vcpus = 16
boot = "c"
disk = [ '/mnt/sda10/vm/SELS_ide_disk.img,raw,xvda,rw' ]
device_model_version = "qemu-xen"
vnc = 1
vnclisten = '9.51.3.174'
vncdi
This is the result of the bisection of the migration issue with 32-bit on
Linux 4.1 onwards.
This is just for info as I believe the issue is already under discussion
etc elsewhere.
I've copied the final graph to
http://xenbits.xen.org/people/ianc/tmp/adhoc/test-amd64-i386-xl..html
Ian.
On Sun
On Fri, 2015-09-04 at 14:49 -0400, D'Mita Levy wrote:
> Hello,
Hi.
xapi/XenAPI has it's own development list at xen-...@lists.xen.org where
you will likely find more people with the expertise to answer your
questions.
Ian.
>
> I am a student at FIU working on a school project so I am a not ver
On 06/09/15 21:05, Wei Liu wrote:
The prefix "Memory" is confusing because the numbers shown after that
are referring to frames.
Change a bunch of prefixes from "Memory" to "Frames". Also rename
send_memory_verify to verify_frames.
Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
Hello,
El 04/09/15 a les 18.12, Ian Campbell ha escrit:
> On Fri, 2015-09-04 at 17:47 +0200, Roger Pau Monné wrote:
>> VCPUOP_initialize was never available to HVM guests, so I don't think
>> changing the argument is a problem. However, I understand that for the
>> sake of clarity overloading an h
On Mon, Sep 07, 2015 at 01:18:44AM -0600, Jan Beulich wrote:
> >>> On 06.09.15 at 22:05, wrote:
> > The original implementation of populate_pfns didn't consider the same
> > pfn can be present multiple times in the array. The mechanism to prevent
> > populating the same pfn multiple times only wor
>>> On 06.09.15 at 06:19, wrote:
> On 9/6/2015 11:19 AM, Tamas K Lengyel wrote:
>>> --- a/xen/drivers/passthrough/vtd/iommu.c
>>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>>> @@ -2310,12 +2310,16 @@ static int intel_iommu_assign_device(
>>> PCI_DEVFN2(bdf) == devfn &&
>>>
On 07/09/15 09:09, wangxin (U) wrote:
Hi,
I'm tring to hibernate an x86 HVM guest with 1TB ram,
[1.VM config]
builder = "hvm"
name = "suse12_sp3"
memory = 1048576
vcpus = 16
boot = "c"
disk = [ '/mnt/sda10/vm/SELS_ide_disk.img,raw,xvda,rw' ]
device_model_version = "qemu-x
Hi,
I found this memory leak on xen-4.5.0:
linux-byXjTX:~ # virsh version
Compiled against library: libvirt 1.2.17
Using library: libvirt 1.2.17
Using API: Xen 1.2.17
Running hypervisor: Xen 4.5.0
Steps to produce this leak:
1. Start a vm, win7_64_2U_vhd, for example.
2. Stop libvirt
>>> On 07.09.15 at 11:36, wrote:
> On Mon, Sep 07, 2015 at 01:18:44AM -0600, Jan Beulich wrote:
>> >>> On 06.09.15 at 22:05, wrote:
>> > The original implementation of populate_pfns didn't consider the same
>> > pfn can be present multiple times in the array. The mechanism to prevent
>> > populat
On Mon, Sep 07, 2015 at 03:53:57AM -0600, Jan Beulich wrote:
> >>> On 07.09.15 at 11:36, wrote:
> > On Mon, Sep 07, 2015 at 01:18:44AM -0600, Jan Beulich wrote:
> >> >>> On 06.09.15 at 22:05, wrote:
> >> > The original implementation of populate_pfns didn't consider the same
> >> > pfn can be pre
On 07/09/15 10:36, Wei Liu wrote:
> On Mon, Sep 07, 2015 at 01:18:44AM -0600, Jan Beulich wrote:
> On 06.09.15 at 22:05, wrote:
>>> The original implementation of populate_pfns didn't consider the same
>>> pfn can be present multiple times in the array. The mechanism to prevent
>>> populating
On Thu, Sep 03, 2015 at 05:25:17PM +0100, Wei Liu wrote:
> Committers,
>
> Xen tree is going to branch at 4.6 RC3. I don't want to branch when
> master != staging, so please avoid committing new patches to staging now
> to let master catch up with staging. Another announcement will be made
> when
On 06/09/15 21:05, Wei Liu wrote:
Wei Liu (5):
libxc: clearer migration v2 debug message
libxc: migration v2 prefix Memory -> Frames
libxc: fix indentation
libxc: don't populate same pfn more than once in populate_pfns
libxc: add assertion to avoid setting same bit more than once
>>> On 07.09.15 at 11:34, wrote:
> So AFAICS we have 3 options:
>
> 1. Overload VCPUOP_initialise like it's done in the current series (v6).
> For PV guests the hypercall parameter is of type vcpu_guest_context,
> while for HVM guests the parameter is of type vcpu_hvm_context.
>
> 2. Create a ne
On 09/07/2015 11:53 AM, Jan Beulich wrote:
On 07.09.15 at 11:36, wrote:
On Mon, Sep 07, 2015 at 01:18:44AM -0600, Jan Beulich wrote:
On 06.09.15 at 22:05, wrote:
The original implementation of populate_pfns didn't consider the same
pfn can be present multiple times in the array. The mechanis
>>> On 07.09.15 at 11:59, wrote:
> But this bug would be avoided if the page table pages were more often
> located towards the end of RAM such that the PFNs were already populated
> as part of the normal page transfer.
Ah, good point.
> I suppose it is possible that the Linux commit found by the
On Mon, Sep 07, 2015 at 11:04:25AM +0100, Andrew Cooper wrote:
> On 06/09/15 21:05, Wei Liu wrote:
> >Wei Liu (5):
> > libxc: clearer migration v2 debug message
> > libxc: migration v2 prefix Memory -> Frames
> > libxc: fix indentation
> > libxc: don't populate same pfn more than once in po
On 07/09/15 11:07, Wei Liu wrote:
On Mon, Sep 07, 2015 at 11:04:25AM +0100, Andrew Cooper wrote:
On 06/09/15 21:05, Wei Liu wrote:
Wei Liu (5):
libxc: clearer migration v2 debug message
libxc: migration v2 prefix Memory -> Frames
libxc: fix indentation
libxc: don't populate same p
On Sun, Sep 06, 2015 at 03:03:13PM +0800, 甘清甜 wrote:
> I'm a master student from Huazhong University of Science & technology,
> China. I'm now researching on Xen optimization under NUMA. I'm puzzled
> that if vNUMA on HVM is enbaded in Xen or not. If yes, which version of
> xen support it?
>
Upc
>>> On 06.09.15 at 08:07, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 04, 2015 10:23 PM
>> >>> On 25.08.15 at 03:57, wrote:
>> > ---
>> > v6:
>> > - Fix a typo
>> >
>> > v5:
>> > - Change back the parameters of __cmpxchg16b() to __uint128_t *
>> > - Remove po
On Mon, 2015-09-07 at 11:01 +0100, Wei Liu wrote:
> On Thu, Sep 03, 2015 at 05:25:17PM +0100, Wei Liu wrote:
> > Committers,
> >
> > Xen tree is going to branch at 4.6 RC3. I don't want to branch when
> > master != staging, so please avoid committing new patches to staging
> > now
> > to let mast
>>> On 06.09.15 at 08:32, wrote:
>> From: Wu, Feng
>> Sent: Sunday, September 06, 2015 2:07 PM
>> If that is the case, what about the changes below?
>>
>> #define cmpxchg16b(ptr,o,n)
>> \
>> ASSERT((unsigned long)ptr & 0xF == 0);
>> \
>> ASSERT(sizeof(*o) == sizeof(__uint128_t))
>> \
>>
I only had a brief look at this.
On Mon, Sep 07, 2015 at 09:52:08AM +, Sunguodong wrote:
> Hi,
> I found this memory leak on xen-4.5.0:
> linux-byXjTX:~ # virsh version
> Compiled against library: libvirt 1.2.17
> Using library: libvirt 1.2.17
> Using API: Xen 1.2.17
> Running hypervisor: Xen
>>> On 06.09.15 at 08:07, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 04, 2015 10:23 PM
>> >>> On 25.08.15 at 03:57, wrote:
>> > ---
>> > v6:
>> > - Fix a typo
>> >
>> > v5:
>> > - Change back the parameters of __cmpxchg16b() to __uint128_t *
>> > - Remove po
On Mon, Sep 07, 2015 at 11:37:48AM +0100, Wei Liu wrote:
> I only had a brief look at this.
>
> On Mon, Sep 07, 2015 at 09:52:08AM +, Sunguodong wrote:
> > Hi,
> > I found this memory leak on xen-4.5.0:
> > linux-byXjTX:~ # virsh version
> > Compiled against library: libvirt 1.2.17
> > Using l
>>> On 06.09.15 at 03:49, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 04, 2015 10:31 PM
>> >>> On 25.08.15 at 03:57, wrote:
>> > --- a/xen/drivers/passthrough/vtd/iommu.c
>> > +++ b/xen/drivers/passthrough/vtd/iommu.c
>> > @@ -2079,6 +2079,9 @@ static int ini
On Mon, 2015-09-07 at 11:37 +0100, Wei Liu wrote:
> I only had a brief look at this.
>
> On Mon, Sep 07, 2015 at 09:52:08AM +, Sunguodong wrote:
> > Hi,
> > I found this memory leak on xen-4.5.0:
> > linux-byXjTX:~ # virsh version
> > Compiled against library: libvirt 1.2.17
> > Using library:
>>> On 06.09.15 at 04:05, wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 04, 2015 10:40 PM
>> To: Wu, Feng
>> Cc: Andrew Cooper; Tian, Kevin; xen-devel@lists.xen.org; Keir Fraser
>> Subject: Re: [PATCH v6 06/18] vmx: Add some hel
>>> On 06.09.15 at 04:22, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 04, 2015 10:47 PM
>> >>> On 25.08.15 at 03:57, wrote:
>> > --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> > +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> > @@ -39,6 +39,7 @@
>> > #include
>> > #include
>>
On Mon, 7 Sep 2015, Shannon Zhao wrote:
> On 2015/9/2 20:18, Ian Campbell wrote:
> > On Fri, 2015-08-28 at 17:45 +0800, Shannon Zhao wrote:
> >>
> >> 1. Create minimal DT to pass required information to Dom0
> >> --
> >> The UEFI stub is a fea
On 03/09/15 17:15, David Vrabel wrote:
On 03/09/15 17:01, Ben Catterall wrote:
Intel Intel 2.2GHz Xeon E5-2407 0 processor:
1.55e-06 seconds was the average time for performing the write without the
deprivileged code running.
5.75e-06 se
>>> On 06.09.15 at 04:33, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 04, 2015 10:53 PM
>> >>> On 25.08.15 at 03:57, wrote:
>> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> > @@ -1701,8 +1701,36 @@ static void vmx_deliver_posted_
>>> On 06.09.15 at 07:24, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 04, 2015 11:11 PM
>> >>> On 25.08.15 at 03:57, wrote:
>> > --- a/xen/drivers/passthrough/vtd/intremap.c
>> > +++ b/xen/drivers/passthrough/vtd/intremap.c
>> > @@ -899,3 +899,110 @@ void iom
Hi Vijay,
On 07/09/15 07:59, Vijay Kilari wrote:
> On Thu, Sep 3, 2015 at 9:55 PM, Julien Grall wrote:
>> I still don't think that it makes sense to introduce the number of LPIs
>> variable in a patch for vITS. As you describe it, it should be part of
>> an ITS/GICv3 patch.
>>
>> Although, I thin
>>> On 06.09.15 at 06:54, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 04, 2015 11:59 PM
>> >>> On 25.08.15 at 03:57, wrote:
>>
>> First of all - an empty Cc list on a patch is suspicious.
>
> I did Cc you for this patch. Why do you say "an empty Cc list"?
On Sun, 2015-09-06 at 21:05 +0100, Wei Liu wrote:
> Wei Liu (5):
> libxc: clearer migration v2 debug message
> libxc: migration v2 prefix Memory -> Frames
> libxc: fix indentation
> libxc: don't populate same pfn more than once in populate_pfns
> libxc: add assertion to avoid setting same
On 07/09/15 07:07, Bob Liu wrote:
> Hi Julien,
Hi Bob,
> On 09/04/2015 09:51 PM, Julien Grall wrote:
>> Hi Roger,
>>
>> On 04/09/15 11:08, Roger Pau Monne wrote:
>>> Request allocation has been moved to connect_ring, which is called every
>>> time blkback connects to the frontend (this can happen
On Mon, Sep 07, 2015 at 11:10:24AM +0100, Andrew Cooper wrote:
>
>
> On 07/09/15 11:07, Wei Liu wrote:
> >On Mon, Sep 07, 2015 at 11:04:25AM +0100, Andrew Cooper wrote:
> >>On 06/09/15 21:05, Wei Liu wrote:
> >>>Wei Liu (5):
> >>> libxc: clearer migration v2 debug message
> >>> libxc: migrati
On 09/07/2015 07:10 PM, Julien Grall wrote:
> On 07/09/15 07:07, Bob Liu wrote:
>> Hi Julien,
>
> Hi Bob,
>
>> On 09/04/2015 09:51 PM, Julien Grall wrote:
>>> Hi Roger,
>>>
>>> On 04/09/15 11:08, Roger Pau Monne wrote:
Request allocation has been moved to connect_ring, which is called every
>>> On 25.08.15 at 03:57, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -661,6 +661,9 @@ int vmx_cpu_up(void)
> if ( cpu_has_vmx_vpid )
> vpid_sync_all();
>
> +INIT_LIST_HEAD(&per_cpu(pi_blocked_vcpu, cpu));
> +spin_lock_init(&per_cpu(p
On Sun, 2015-09-06 at 16:49 +, osstest service owner wrote:
> flight 61379 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/61379/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
>>> On 25.08.15 at 03:57, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2035,6 +2035,52 @@ static void pi_wakeup_interrupt(struct cpu_user_regs
> *regs)
> this_cpu(irq_count)++;
> }
>
> +/* Handle VT-d posted-interrupt when VCPU is running. */
> +stati
On Mon, Sep 07, 2015 at 12:55:25PM +0100, Ian Campbell wrote:
> On Sun, 2015-09-06 at 16:49 +, osstest service owner wrote:
> > flight 61379 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/61379/
> >
> > Failures and problems with tests :-(
> >
> > Tests which di
>>> On 25.08.15 at 03:57, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1573,6 +1573,22 @@ static void __context_switch(void)
> per_cpu(curr_vcpu, cpu) = n;
> }
>
> +static inline void pi_ctxt_switch_from(struct vcpu *prev)
> +{
> +/*
> + * When switching
Debian creates an entry such as:
127.0.1.1 lace-bug.xs.citrite.net lace-bug
This causes local lookups of the FQDN to get 127.0.1.1, which is
unhelpful if you are looking for an address to bind to and were hoping
to get the public IP address, as libvirt does on the target host f
On Mon, 2015-09-07 at 13:43 +0100, Wei Liu wrote:
> On Mon, Sep 07, 2015 at 12:55:25PM +0100, Ian Campbell wrote:
> > On Sun, 2015-09-06 at 16:49 +, osstest service owner wrote:
> > > flight 61379 xen-unstable real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/61379/
> > >
> >
Jan Beulich wrote on 2015-09-07:
>> + * jnz .Lvmx_process_softirqs
>> + *
>> + * ..
>> + *
>> + * je .Lvmx_launch
>> + *
>> + * ..
>> + *
>> + * .Lvmx_process_softirqs:
>> + * sti
>> + * call do_softirq
>> +
On Mon, Sep 07, 2015 at 01:49:16PM +0100, Ian Campbell wrote:
> On Mon, 2015-09-07 at 13:43 +0100, Wei Liu wrote:
> > On Mon, Sep 07, 2015 at 12:55:25PM +0100, Ian Campbell wrote:
> > > On Sun, 2015-09-06 at 16:49 +, osstest service owner wrote:
> > > > flight 61379 xen-unstable real [real]
> >
>>> On 25.08.15 at 03:57, wrote:
> @@ -220,7 +224,7 @@ static void dump_iommu_info(unsigned char key)
> struct iremap_entry *p;
> if ( i % (1 << IREMAP_ENTRY_ORDER) == 0 )
> {
> -/* This entry across page boundry */
> +
>>> On 25.08.15 at 03:57, wrote:
> Enable VT-d Posted-Interrupts and add a command line
> parameter for it.
>
> Signed-off-by: Feng Wu
> Reviewed-by: Kevin Tian
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.
>>> On 07.09.15 at 15:00, wrote:
> Jan Beulich wrote on 2015-09-07:
>> Yang, in this context: Why does __vmx_deliver_posted_interrupt()
>> not use cpu_raise_softirq(), instead kind of open coding it (see your
>> d7dafa375b ["VMX: Add posted interrupt supporting"])?
>
> Sorry, I am not in the cont
Hi Vijay,
On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Emulate GITS* registers
>
> Signed-off-by: Vijaya Kumar K
> ---
> v6: - Removed unrelated code of this patch
> - Used vgic_regN_{read,write}
> v4: - Removed GICR register emulation
> ---
> xen/arch/arm/v
On Sun, Sep 06, 2015 at 12:46:01PM +0200, Sander Eikelenboom wrote:
> Hi All,
>
> Today i noticed that keyboard doesn't work when using VNC on a HVM guest
> which runs under qemu-xen device-model.
> Mouse still works with usbdevice='tablet', but keypress show no response
> what so ever.
>
> Unfor
On 04/08/15 12:59, Julien Grall wrote:
> Hi all,
Hi,
Any more comments on this series before I send a new version?
Regards,
> This series aims to fix the 32-bit access on 64-bit register. Some guest
> OS such as FreeBSD and Linux (only in the ITS) use those access and will
> crash when starting
Hi Vijay,
On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 659d919..1c88300 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -110,7 +110,13 @@ static inline void sgi_target_init(struct s
Objects loaded by FileHandle->Read need to be flushed to dcache,
otherwise copy_from_paddr will read stale data when copying the kernel,
causing a failure to boot.
Introduce efi_arch_flush_dcache_area and call it from read_file.
This commit introduces no functional changes on x86.
Reported-by: M
Hi Vijay,
On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
> +static int vgic_v3_gits_lpi_mmio_read(struct vcpu *v, mmio_info_t *info)
[...]
> +/* Neglect if not LPI. */
> +if ( offset < FIRST_GIC_LPI )
> +{
> +*r = 0;
> +return 1;
> +}
[...]
> +static int vgic_
On Mon, 2015-09-07 at 15:13 +0100, Stefano Stabellini wrote:
> Objects loaded by FileHandle->Read need to be flushed to dcache,
> otherwise copy_from_paddr will read stale data when copying the kernel,
> causing a failure to boot.
>
> Introduce efi_arch_flush_dcache_area and call it from read_file
Hi all,
this patch series introduces support for gzipped kernels, such as the
standard Image.gz format used by Linux on arm64 by default, in Xen on
arm. Without it, Xen cannot load the default kernel shipped by distros,
such as CentOS 7.
Stefano Stabellini (2):
xen: move perform_gunzip to
I believe this also has something to do with a windows guest boot hang
issue.
It randomly occured, when boot a guest has windows 2008 os and pv-driver
installed.
The boot process hangs when wait xenstored replay event signal.
It can be reproduced after hundreds reboot using the xen staging br
Free the memory used for the compressed kernel and update the relative
mod->start and mod->size parameters with the uncompressed ones.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
CC: ian.campb...@citrix.com
---
Changes in v5:
- code style
Changes in v4:
- return uint32_t from
The current gunzip code to decompress the Dom0 kernel is implemented in
inflate.c which is included by bzimage.c.
I am looking to doing the same on ARM64 but there is quite a bit of
boilerplate definitions that I would need to import in order for
inflate.c to work correctly.
Instead of copying/pa
>>> On 07.09.15 at 16:24, wrote:
> I believe this also has something to do with a windows guest boot hang
> issue.
>
> It randomly occured, when boot a guest has windows 2008 os and pv-driver
> installed.
> The boot process hangs when wait xenstored replay event signal.
>
> It can be reproduce
On Fri, Sep 04, 2015 at 03:27:42AM -0600, Jan Beulich wrote:
> Ian, Wei,
>
> I seem to be seeing two issues in the grant copy handling of netback,
> solely from code inspection:
>
> 1) Shouldn't MAX_GRANT_COPY_OPS, to take care of the copying
> the header may require, be
> ((MAX_SKB_FRAGS + 1) *
On Tue, 18 Aug 2015, Doug Goldstein wrote:
> When your distro is not supported, handle the case gracefully and let
> the user know instead of spitting out bash errors.
>
> Signed-off-by: Doug Goldstein
Thanks for the patch!
Reviewed-by: Stefano Stabellini
> lib/common-functions.sh | 11
>>> On 07.09.15 at 16:13, wrote:
> Objects loaded by FileHandle->Read need to be flushed to dcache,
> otherwise copy_from_paddr will read stale data when copying the kernel,
> causing a failure to boot.
I have to admit that I'm a little puzzled by this description: If this
was a general requireme
On Fri, Sep 04, 2015 at 06:50:45AM -0600, Jan Beulich wrote:
> Wei,
>
> coming back to commit 723a375f4e introducing this constant along
> with some commentary: First of all - why 18 when in old Linux kernels
> MAX_SKB_FRAGS is 18 and the head usually requires another slot?
That indeed didn't cou
>>> On 07.09.15 at 16:47, wrote:
> On Fri, Sep 04, 2015 at 03:27:42AM -0600, Jan Beulich wrote:
>> Ian, Wei,
>>
>> I seem to be seeing two issues in the grant copy handling of netback,
>> solely from code inspection:
>>
>> 1) Shouldn't MAX_GRANT_COPY_OPS, to take care of the copying
>> the heade
Monday, September 7, 2015, 3:21:45 PM, you wrote:
> On Sun, Sep 06, 2015 at 12:46:01PM +0200, Sander Eikelenboom wrote:
>> Hi All,
>>
>> Today i noticed that keyboard doesn't work when using VNC on a HVM guest
>> which runs under qemu-xen device-model.
>> Mouse still works with usbdevice='tablet
On Mon, Sep 07, 2015 at 09:03:12AM -0600, Jan Beulich wrote:
> >>> On 07.09.15 at 16:47, wrote:
> > On Fri, Sep 04, 2015 at 03:27:42AM -0600, Jan Beulich wrote:
> >> Ian, Wei,
> >>
> >> I seem to be seeing two issues in the grant copy handling of netback,
> >> solely from code inspection:
> >>
>
On Mon, 7 Sep 2015, Jan Beulich wrote:
> >>> On 07.09.15 at 16:13, wrote:
> > Objects loaded by FileHandle->Read need to be flushed to dcache,
> > otherwise copy_from_paddr will read stale data when copying the kernel,
> > causing a failure to boot.
>
> I have to admit that I'm a little puzzled b
On 04/09/15 10:27, Jan Beulich wrote:
> Ian, Wei,
>
> I seem to be seeing two issues in the grant copy handling of netback,
> solely from code inspection:
>
> 1) Shouldn't MAX_GRANT_COPY_OPS, to take care of the copying
> the header may require, be
> ((MAX_SKB_FRAGS + 1) * XEN_NETIF_RX_RING_SIZE)
>>> On 07.09.15 at 16:56, wrote:
> On Fri, Sep 04, 2015 at 06:50:45AM -0600, Jan Beulich wrote:
>> Wei,
>>
>> coming back to commit 723a375f4e introducing this constant along
>> with some commentary: First of all - why 18 when in old Linux kernels
>> MAX_SKB_FRAGS is 18 and the head usually requi
>>> On 07.09.15 at 17:10, wrote:
> On Mon, Sep 07, 2015 at 09:03:12AM -0600, Jan Beulich wrote:
>> >>> On 07.09.15 at 16:47, wrote:
>> > With that in mind, even MAX_SKB_FRAGS + 1 is not enough. It would be
>> > MAX_SKB_FRAGS + 64K / PAGE_SIZE, i.e. we count the most extreme
>> > situation that we
On Mon, Sep 7, 2015 at 7:50 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
>> +static int vgic_v3_gits_lpi_mmio_read(struct vcpu *v, mmio_info_t *info)
>
> [...]
>
>> +/* Neglect if not LPI. */
>> +if ( offset < FIRST_GIC_LPI )
>> +{
>> +
On Thu, 3 Sep 2015, Juergen Gross wrote:
> Introduce a new dummy system device serving as parent for virtual
> buses. This will enable new pv backends to introduce virtual buses
> which are removable again opposed to system buses which are meant
> to stay once added.
>
> Signed-off-by: Juergen Gro
The Xen hypercall interface is always using 4K page granularity on ARM
and x86 architecture.
With the incoming support of 64K page granularity for ARM64 guest, it
won't be possible to re-use the Linux page definition in Xen drivers.
Introduce Xen page definition helpers based on the Linux page
de
Currently, blkif_queue_request has 2 distinct execution path:
- Send a discard request
- Send a read/write request
The function is also allocating grants to use for generating the
request. Although, this is only used for read/write request.
Rather than having a function with 2 distinct ex
Many PV drivers contain the idiom:
pfn = page_to_gfn(...) /* Or similar */
gnttab_grant_foreign_access_ref
Replace it by a new helper. Note that when Linux is using a different
page granularity than Xen, the helper only gives access to the first 4KB
grant.
This is useful where drivers are alloca
Hi all,
ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
hypercall interface and PV protocol are always based on 4KB page granularity.
Any attempt to boot a Linux guest with 64KB pages enabled will result to a
guest crash.
This series is a first attempt to allow those
The skb doesn't change within the function. Therefore it's only
necessary to check if we need GSO once at the beginning.
Signed-off-by: Julien Grall
Acked-by: Wei Liu
---
Cc: Ian Campbell
Cc: net...@vger.kernel.org
Changes in v4:
- Add Wei's acked
Changes in v2:
- Pat
Currently, a grant is always based on the Xen page granularity (i.e
4KB). When Linux is using a different page granularity, a single page
will be split between multiple grants.
The new helpers will be in charge of splitting the Linux page into grants
and call a function given by the caller on each
Prepare the code to support 64KB page granularity. The first
implementation will use a full Linux page per indirect and persistent
grant. When non-persistent grant is used, each page of a bio request
may be split in multiple grant.
Furthermore, the field page of the grant structure is only used to
On ARM all dma-capable devices on a same platform may not be protected
by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
order to use correctly the device.
While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant
mapping will screw this contiguous mapping.
When
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant->pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszu
They are not used in common code expect in one place in balloon.c which is
only compiled when Linux is using PV MMU. It's not the case on ARM.
Rather than worrying how to handle the 64KB case, drop them.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Russell King
Cha
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using block
device on a non-modified Xen.
The block API is using segment which should at least be the size of a
Linux page. Therefore, the driver will have to break the page
The hypercall interface (as well as the toolstack) is always using 4KB
page granularity. When the toolstack is asking for mapping a series of
guest PFN in a batch, it expects to have the page map contiguously in
its virtual memory.
When Linux is using 64KB page granularity, the privcmd driver will
Only use the first 4KB of the page to store the events channel info. It
means that we will waste 60KB every time we allocate page for:
* control block: a page is allocating per CPU
* event array: a page is allocating everytime we need to expand it
I think we can reduce the memory waste f
The Xen interface is using 4KB page granularity. This means that each
grant is 4KB.
The current implementation allocates a Linux page per grant. On Linux
using 64KB page granularity, only the first 4KB of the page will be
used.
We could decrease the memory wasted by sharing the page with multiple
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Vrabel
Cc: Boris Ostrovsky
Cc: linuxppc-...@lists.ozlabs.org
Changes in v4:
- The ring is always 4K (
The hypercall interface is always using 4KB page granularity. This is
requiring to use xen page definition macro when we deal with hypercall.
Note that pfn_to_gfn is working with a Xen pfn (i.e 4KB). We may want to
rename pfn_gfn to make this explicit.
We also allocate a 64KB page for the shared
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using network
device on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on the gran
For ARM64 guests, Linux is able to support either 64K or 4K page
granularity. Although, the hypercall interface is always based on 4K
page granularity.
With 64K page granularity, a single page will be spread over multiple
Xen frame.
To avoid splitting the page into 4K frame, take advantage of the
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity working as a
network backend on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on
1 - 100 of 164 matches
Mail list logo
