On Fri, Dec 05, 2014 at 05:30:52AM +, Tian, Kevin wrote:
> > From: Donald D. Dugger
> > Sent: Friday, November 21, 2014 1:12 PM
> >
> > Currently the quirk code for SandyBridge uses the VTd timeout value when
> > writing to an IGD register. This is the wrong timeout to use and, at
> > 1000 ms
On Thu, Dec 04, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 04, 2014 at 08:47:56AM +0100, Olaf Hering wrote:
> > Is that something the sysadmin has to adjust, or should the xen source
> > provide proper values?
> It would be rather cumbersome if the sysadmin had to adjust it. The goal
> here would
>>> On 05.12.14 at 07:24, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, December 05, 2014 12:29 AM
>>
>> >>> On 01.12.14 at 10:24, wrote:
>> > In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
>> > to allocate some memory to use in runtime cycle, so
>>> On 05.12.14 at 07:23, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, December 05, 2014 12:20 AM
>>
>> >>> On 01.12.14 at 10:24, wrote:
>> > We need to check to reserve all reserved device memory maps in e820
>> > to avoid any potential guest memory conflict.
>> >
>>
>>> On 04.12.14 at 22:22, wrote:
> On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich wrote:
> On 03.12.14 at 22:02, wrote:
>>> 3) Should not we change xen/arch/*/efi/efi-boot.h to
>>>xen/arch/*/efi/efi-boot.c? efi-boot.h contains more
>>>code than definitions, declarations and short static
> From: Don Dugger [mailto:n0...@n0ano.com]
> Sent: Friday, December 05, 2014 2:13 PM
>
> On Fri, Dec 05, 2014 at 05:30:52AM +, Tian, Kevin wrote:
> > > From: Donald D. Dugger
> > > Sent: Friday, November 21, 2014 1:12 PM
> > >
> > > Currently the quirk code for SandyBridge uses the VTd timeou
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, December 05, 2014 12:29 AM
>
> >>> On 01.12.14 at 10:24, wrote:
> > In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> > to allocate some memory to use in runtime cycle, so we alsoe need to
> > make sure all reser
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, December 05, 2014 12:20 AM
>
> >>> On 01.12.14 at 10:24, wrote:
> > We need to check to reserve all reserved device memory maps in e820
> > to avoid any potential guest memory conflict.
> >
> > Currently, if we can't insert RDM entrie
The inline function mfn_to_pfn_no_overrides() uses __get_user() to
access the machine_to_phys_mapping array to avoid crashes when
using out of bounds indices e.g. for I/O addresses.
Avoid sparse warnings by attributing the accessed address with __user.
Signed-off-by: Juergen Gross
---
arch/x86/
The patch "Speed up set_phys_to_machine() by using read-only mappings"
introduced a sparse warning:
arch/x86/xen/p2m.c:628:13: sparse: incorrect type in argument 1
(different address spaces)
Avoid the warning.
Signed-off-by: Juergen Gross
---
arch/x86/xen/p2m.c | 4 +
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 04, 2014 11:33 PM
> > +if ( pcidevs == NULL )
> > +{
> > +rcu_unlock_domain(d);
> > +return -ENOMEM;
> > +}
> > +
> > +if ( copy_from_guest(pcide
> From: Donald D. Dugger
> Sent: Friday, November 21, 2014 1:12 PM
>
> Currently the quirk code for SandyBridge uses the VTd timeout value when
> writing to an IGD register. This is the wrong timeout to use and, at
> 1000 msec., is also much too large. This patch changes the quirk code
> to use
flight 32071 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32071/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf-pin 5 xen-boot fail REGR. vs. 31885
test-amd64-i386-pair17 gue
On 12/04/2014 10:30 PM, Jan-Simon Moeller wrote:
Hi !
My name is Jan-Simon Moeller and I'm looking into compiling the kernel with
LLVM/Clang (see llvm.linuxfoundation.org) .
Right now we face this issue when compiling with clang:
CC arch/x86/xen/mmu.o
arch/x86/xen/mmu.c:1343:18: error:
flight 32084 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32084/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen 66b09d00078908e61d0f0c1b87fc140ed8c91e06
baseline version:
rumpuserxen f302fca6c18c1ccdefe3d0d5f583
On Thu, Dec 04, 2014 at 01:49:47PM +, Jan Beulich wrote:
> >>> On 28.11.14 at 16:46, wrote:
> > On 28/11/14 15:18, Jan Beulich wrote:
> > On 28.11.14 at 14:55, wrote:
> >>> The problem is with continuations which reuse the upper bits of the
> >>> input register, not with this HVMOP_op_mas
On Thu, Dec 04, 2014 at 08:47:56AM +0100, Olaf Hering wrote:
> On Wed, Dec 03, M A Young wrote:
>
> > On Wed, 3 Dec 2014, Konrad Rzeszutek Wilk wrote:
> > >Options=mode=755,context="$XENSTORED_MOUNT_CTX"
> >
> > Yes, that was on my probable bug list, as context="none" isn't a valid mount
> > opti
On 12/5/2014 12:04 AM, Tim Deegan wrote:
Hi,
At 21:13 +0800 on 04 Dec (1417724006), Yu Zhang wrote:
A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's page tables. Handling of this new
p2m type are similar with existing p2m_ram_ro in most condition
c
On Tue, Dec 02, 2014 at 01:36:20PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 04:16:28PM +0100, Daniel Kiper wrote:
> > Signed-off-by: Daniel Kiper
>
> This usage scenario which I can see this being useful (and
> I've tripped over this) is when you rebuild a new version
> from
flight 32069 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32069/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-installfail pass in 32024
test-amd64-i386-freebsd1
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, December 04, 2014 6:50 PM
> To: Zhangleiqiang (Trump)
> Cc: Wei Liu; xen-devel@lists.xen.org; zhangleiqiang; Luohao (brian); Xiaoding
> (B); Yuzhou (C); Zhuangyuxin
> Subject: Re: [Xen-devel] Poor network pe
On Thu, 4 Dec 2014 17:35:59 +0100
Roger Pau Monné wrote:
> Hello,
>
> I've just stumbled upon this assert while testing PVH on different
> hardware. It was added in 7c4870 as a safe belt, but it turns out INS
> and OUTS go through handle_mmio. So using this instructions from a PVH
> guest basica
Hi Tim,
On Thu, Dec 4, 2014 at 9:10 PM, Tim Deegan wrote:
> At 13:51 + on 04 Dec (1417697518), Julien Grall wrote:
>> On 04/12/14 03:50, Vijay Kilari wrote:
>> > Hi Tim,
>>
>> Hi Vijay,
>>
>> > I see that on uart interrupt, ICR is written to clear the all
>> > interrupts except TX, RX and RX
flight 32066 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32066/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 8 guest-start fail REGR. vs. 31241
test-amd64-i386-xl
On 04/12/14 14:40, Andrew Cooper wrote:
There are already-identified issues such as MiniOS leaking things like
ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits
to fix.
I think splitting things like the stub libc away from the "MiniOS Xen
Framework" is also a good idea. I
Hi !
My name is Jan-Simon Moeller and I'm looking into compiling the kernel with
LLVM/Clang (see llvm.linuxfoundation.org) .
Right now we face this issue when compiling with clang:
CC arch/x86/xen/mmu.o
arch/x86/xen/mmu.c:1343:18: error: fields must have a constant size:
'variable l
On Thu, Dec 4, 2014 at 1:35 AM, Jan Beulich wrote:
On 03.12.14 at 22:02, wrote:
>> Hey,
>>
>> 1) Why is there in EFI code so many functions (e.g. efi_start(),
>>efi_arch_edd(), ...) with local variables declared as a static?
>>Though some of them have also regular local variables. I
On Thu, Dec 04, 2014 at 07:26:55PM +, Julien Grall wrote:
> A 0 was forgotten when the arm32 BUG instruction opcode has been added in
> commit
> 3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".
>
> This will result to use a valid instruction (mcreq 0, 3, r0, cr15
A 0 was forgotten when the arm32 BUG instruction opcode has been added in commit
3e802c6ca1fb9a9549258c2855a57cad483f3cbd "xen/arm: Correctly support WARN_ON".
This will result to use a valid instruction (mcreq 0, 3, r0, cr15, cr0, {7}),
and inhibit usage of BUG/WARN_ON and co.
Signed-off-by: Jul
On Thu, Dec 04, 2014 at 02:31:11PM +, David Vrabel wrote:
> On 04/12/14 14:09, Sander Eikelenboom wrote:
> >
> > Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> >
> >> On 04/12/14 13:10, Sander Eikelenboom wrote:
> >>>
> >>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> >>>
>
flight 32065 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32065/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl 11 guest-saverestore fail baseline untested
test-amd64-i386-xl-credit29
flight 32083 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 32005
build-amd64-libvirt
On Thu, Dec 04, 2014 at 03:46:42PM +, David Vrabel wrote:
> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
> >
> > These patches fix some issues with PCI back and also add proper
> > bus/slot reset.
>
> Applied 1-8 to devel/for-linus-3.19. I did not apply #9.
Excellent. Thank you!
>
> Tha
Hi all,
At the Hackathon in Rackspace we discussed a plan to tidy up the
hypervisor side of PVH code so that 'PVH' stops being a separate guest
type, becoming instead a HVM guest with various features disabled (and
one or two other tweaks).
Although I had hoped to work on that in the meantime, v
>>> On 04.12.14 at 17:26, wrote:
> On 12/04/2014 06:55 AM, Dario Faggioli wrote:
>> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
>>> This change requires bumping XEN_SYSCTL_INTERFACE_VERSION
>>>
>> Which would not be the case if we take the approach of adding a new,
>> iotopology spec
On Thursday 04 December 2014 19:01:40 Mihai Donțu wrote:
> Implemented xmem_pool_check(), xmem_pool_check_locked() and
> xmem_pool_check_unlocked() to verity the integrity of the TLSF matrix.
>
> Signed-off-by: Mihai Donțu
> ---
> xen/common/xmalloc_tlsf.c | 119
> ++
>>> On 01.12.14 at 10:24, wrote:
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -572,10 +572,11 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
> {
> struct acpi_dmar_reserved_memory *rmrr =
> container_of(header, struct acpi_dmar_
Implemented xmem_pool_check(), xmem_pool_check_locked() and
xmem_pool_check_unlocked() to verity the integrity of the TLSF matrix.
Signed-off-by: Mihai Donțu
---
xen/common/xmalloc_tlsf.c | 119 +-
xen/include/xen/xmalloc.h | 7 +++
2 files changed,
On Thu, 2014-12-04 at 17:25 +0100, Sander Eikelenboom wrote:
> Thursday, December 4, 2014, 4:39:06 PM, you wrote:
>
> > On Thu, 2014-12-04 at 15:50 +0100, Sander Eikelenboom wrote:
> >> Thursday, December 4, 2014, 3:31:11 PM, you wrote:
> >>
> >> > On 04/12/14 14:09, Sander Eikelenboom wrote:
> >
>>> On 01.12.14 at 10:24, wrote:
> --- a/xen/common/mem_access.c
> +++ b/xen/common/mem_access.c
> @@ -55,6 +55,43 @@ void mem_access_resume(struct domain *d)
> }
> }
>
> +/* We can't expose reserved device memory. */
> +static int mem_access_check_rdm(struct domain *d, uint64_aligned_t st
>>> On 01.12.14 at 10:24, wrote:
> We always reserve these ranges since we never allow any stuff to
> poke them.
>
> But in theory some untrusted VM can maliciously access them. So we
> need to intercept this approach. But we just don't want to leak
> anything or introduce any side affect since o
On 04/12/14 16:11, Jan Beulich wrote:
On 04.12.14 at 16:46, wrote:
>> On 04/12/14 14:55, Jan Beulich wrote:
>> On 04.12.14 at 15:28, wrote:
On 04/12/14 13:49, Jan Beulich wrote:
On 28.11.14 at 16:46, wrote:
>> On 28/11/14 15:18, Jan Beulich wrote:
>> On 28.11.1
On 04/12/14 16:26, Boris Ostrovsky wrote:
> On 12/04/2014 06:55 AM, Dario Faggioli wrote:
>> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
>>> Make XEN_SYSCTL_topologyinfo more generic so that it can return both
>>> CPU and IO topology (support for returning the latter is added in the
>
>>> On 01.12.14 at 10:24, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -556,6 +556,40 @@ guest_physmap_remove_page(struct domain *d, unsigned
> long gfn,
> gfn_unlock(p2m, gfn, page_order);
> }
>
> +/* Check if we are accessing rdm. */
If a comment doesn't do a
On Thu, Dec 04, 2014 at 11:26:58AM -0500, Don Slutz wrote:
[...]
> >those warnings less scary.
>
> It was not so much that hvmloader is the one to change (but having it check
> for room first might be good), but more that a change to xen would be good
> (like changing the wording or maybe only out
Hello,
I've just stumbled upon this assert while testing PVH on different
hardware. It was added in 7c4870 as a safe belt, but it turns out INS
and OUTS go through handle_mmio. So using this instructions from a PVH
guest basically kills Xen.
I've removed it and everything seems fine, so I'm consi
>>> On 01.12.14 at 10:24, wrote:
> In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
> to allocate some memory to use in runtime cycle, so we alsoe need to
> make sure all reserved device memory don't overlap such a region.
While ideally this would get switched to the model ou
On 12/03/14 09:50, Stefano Stabellini wrote:
On Wed, 3 Dec 2014, Don Slutz wrote:
On 12/03/14 07:20, Stefano Stabellini wrote:
On Wed, 3 Dec 2014, Wei Liu wrote:
On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
[...]
hw_error("xc_domain_getinfo failed");
}
-i
Thursday, December 4, 2014, 4:39:06 PM, you wrote:
> On Thu, 2014-12-04 at 15:50 +0100, Sander Eikelenboom wrote:
>> Thursday, December 4, 2014, 3:31:11 PM, you wrote:
>>
>> > On 04/12/14 14:09, Sander Eikelenboom wrote:
>> >>
>> >> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
>> >>
>> >
On 12/04/2014 06:55 AM, Dario Faggioli wrote:
On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
Make XEN_SYSCTL_topologyinfo more generic so that it can return both
CPU and IO topology (support for returning the latter is added in the
subsequent patch)
Is it always the case that we nee
On Wed, Dec 03, 2014 at 06:16:18PM +0100, Vitaly Kuznetsov wrote:
> New libxl__domain_soft_reset_destroy_old() is an internal-only
> version of libxl_domain_destroy() which follows the same domain
> destroy path with the only difference: xc_domain_destroy() is
> being avoided so the domain is not a
>>> On 01.12.14 at 10:24, wrote:
> We need to check to reserve all reserved device memory maps in e820
> to avoid any potential guest memory conflict.
>
> Currently, if we can't insert RDM entries directly, we may need to handle
> several ranges as follows:
> a. Fixed Ranges --> BUG()
> lowmem_r
(I've skipped the internal implementation since I don't know what's
required to fulfil soft reset.)
On Wed, Dec 03, 2014 at 06:16:20PM +0100, Vitaly Kuznetsov wrote:
[...]
> + libxl__domain_create_state *dcs);
>
> /* Each time the dm needs to be saved, w
>>> On 04.12.14 at 16:46, wrote:
> On 04/12/14 14:55, Jan Beulich wrote:
> On 04.12.14 at 15:28, wrote:
>>> On 04/12/14 13:49, Jan Beulich wrote:
>>> On 28.11.14 at 16:46, wrote:
> On 28/11/14 15:18, Jan Beulich wrote:
> On 28.11.14 at 14:55, wrote:
>>> The problem is wi
Hi,
At 21:13 +0800 on 04 Dec (1417724006), Yu Zhang wrote:
> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
> the write operations on GPU's page tables. Handling of this new
> p2m type are similar with existing p2m_ram_ro in most condition
> checks, with only difference on final
>>> On 01.12.14 at 10:24, wrote:
> We need to make sure all mmio allocation don't overlap
> any rdm, reserved device memory. Here we just skip
> all reserved device memory range in mmio space.
I think someone else already suggested that this and patch 9 should
be swapped, and the BAR allocation b
>>> On 01.12.14 at 10:24, wrote:
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -22,27 +22,66 @@ struct get_reserved_device_memory {
> unsigned int used_entries;
> };
>
> -static int get_reserved_device_memory(xen_pfn_t start,
> -
At 21:13 +0800 on 04 Dec (1417724005), Yu Zhang wrote:
> From: Yu Zhang
>
> Currently, the P2M_RO_TYPES bears 2 meanings: one is
> "_PAGE_RW bit is clear in their PTEs", and another is
> to discard the write operations on these pages. This
> patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
>
On 04/12/14 15:12, Vitaly Kuznetsov wrote:
> Julien Grall writes:
>
>> Hi Vitaly,
>>
>> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>>> New operation sets the 'recipient' domain which will recieve all
>>
>> s/recieve/receive/
>>
>>> memory pages from a particular domain and kills the original do
On 04/12/14 15:36, Anthony Wright wrote:
>> On 01/12/14 14:22, David Vrabel wrote:
>> This VIF protocol is weird. The first slot contains a txreq with a
>> size
>> for the total length of the packet, subsequent slots have sizes for
>> that
>> fragment only.
>>
>> netback then has to calculate how l
On 12/04/2014 03:51 AM, Jan Beulich wrote:
On 03.12.14 at 21:13, wrote:
On 11/27/2014 03:57 AM, Jan Beulich wrote:
On 26.11.14 at 15:32, wrote:
On 11/25/2014 08:49 AM, Jan Beulich wrote:
On 17.11.14 at 00:07, wrote:
@@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
switch
>>> On 01.12.14 at 10:24, wrote:
> We need to use reserved device memory maps with multiple times, so
> provide just one common function should be friend.
I'm not going to repeat earlier comments; the way this is done right
now it's neither a proper runtime function nor a proper init time one.
J
At 14:28 + on 04 Dec (1417699730), Andrew Cooper wrote:
> On 04/12/14 13:49, Jan Beulich wrote:
> On 28.11.14 at 16:46, wrote:
> >> On 28/11/14 15:18, Jan Beulich wrote:
> >> On 28.11.14 at 14:55, wrote:
> The problem is with continuations which reuse the upper bits of the
> >>>
On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
>
> These patches fix some issues with PCI back and also add proper
> bus/slot reset.
Applied 1-8 to devel/for-linus-3.19. I did not apply #9.
Thanks.
David
___
Xen-devel mailing list
Xen-devel@lists.x
On 04/12/14 14:55, Jan Beulich wrote:
On 04.12.14 at 15:28, wrote:
>> On 04/12/14 13:49, Jan Beulich wrote:
>> On 28.11.14 at 16:46, wrote:
On 28/11/14 15:18, Jan Beulich wrote:
On 28.11.14 at 14:55, wrote:
>> The problem is with continuations which reuse the upper bit
On 28/11/14 10:53, Juergen Gross wrote:
> Paravirtualized kernels running on Xen use a three level tree for
> translation of guest specific physical addresses to machine global
> addresses. This p2m tree is used for construction of page table
> entries, so the p2m tree walk is performance critical.
At 13:51 + on 04 Dec (1417697518), Julien Grall wrote:
> On 04/12/14 03:50, Vijay Kilari wrote:
> > Hi Tim,
>
> Hi Vijay,
>
> > I see that on uart interrupt, ICR is written to clear the all
> > interrupts except TX, RX and RX timeout. With this, cpu always finds
> > TX/RX is active and never
On Thu, 2014-12-04 at 15:50 +0100, Sander Eikelenboom wrote:
> Thursday, December 4, 2014, 3:31:11 PM, you wrote:
>
> > On 04/12/14 14:09, Sander Eikelenboom wrote:
> >>
> >> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> >>
> >>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>
>
> On 01/12/14 14:22, David Vrabel wrote:
> This VIF protocol is weird. The first slot contains a txreq with a
> size
> for the total length of the packet, subsequent slots have sizes for
> that
> fragment only.
>
> netback then has to calculate how long the first slot is, by
> subtracting
> all th
>>> On 01.12.14 at 10:24, wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
Please don't - we use bool_t in the hypervisor, not bool. The header
only exists for source code shared with the too
Julien Grall writes:
> Hi Vitaly,
>
> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>> New operation sets the 'recipient' domain which will recieve all
>
> s/recieve/receive/
>
>> memory pages from a particular domain and kills the original domain.
>>
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>>
On Thu, Dec 04, 2014 at 03:46:59PM +0100, Vitaly Kuznetsov wrote:
> Wei Liu writes:
>
> > On Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
> >> Changes from RFCv3:
> >> This is the first non-RFC series as no major concerns were expressed. I'm
> >> trying
> >> to address Jan's co
>>> On 04.12.14 at 15:28, wrote:
> On 04/12/14 13:49, Jan Beulich wrote:
> On 28.11.14 at 16:46, wrote:
>>> On 28/11/14 15:18, Jan Beulich wrote:
>>> On 28.11.14 at 14:55, wrote:
> The problem is with continuations which reuse the upper bits of the
> input register, not with this
Thursday, December 4, 2014, 3:31:11 PM, you wrote:
> On 04/12/14 14:09, Sander Eikelenboom wrote:
>>
>> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
>>
>>> On 04/12/14 13:10, Sander Eikelenboom wrote:
Thursday, December 4, 2014, 1:24:47 PM, you wrote:
> On 04/12/14 12:0
Julien Grall writes:
> On 03/12/2014 17:16, Vitaly Kuznetsov wrote:
>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
>> index a42d0b8..552e4a3 100644
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -366,6 +366,8 @@ struct domain
>> bool_t i
Wei Liu writes:
> On Wed, Dec 03, 2014 at 06:16:12PM +0100, Vitaly Kuznetsov wrote:
>> Changes from RFCv3:
>> This is the first non-RFC series as no major concerns were expressed. I'm
>> trying
>> to address Jan's comments. Changes are:
>> - Move from XEN_DOMCTL_set_recipient to XEN_DOMCTL_devou
On 04/12/14 14:27, Martin Lucina wrote:
> Hi,
>
> In rumprun-xen [1] we use Mini-OS as a "base firmware" layer in our stack.
> Currently we are using a slightly bastardized fork of the xen.git Mini-OS.
>
> We would like to avoid this turning into a permanent fork. Following
> previous discussion [2
Thanks for your detailed explanation, Wei.
I am wondering if netfront/netback can be optimized to reach the 10Gbps
throughout between DomUs running on different hosts connected with 10GE
network. Currently, it seems like the RX is the bottleneck, which also consist
with the testing result in x
> -Original Message-
> From: Zoltan Kiss [mailto:zoltan.k...@linaro.org]
> Sent: Thursday, December 04, 2014 9:35 PM
> To: Zhangleiqiang (Trump); Wei Liu; xen-devel@lists.xen.org
> Cc: Xiaoding (B); Zhuangyuxin; zhangleiqiang; Luohao (brian); Yuzhou (C)
> Subject: Re: [Xen-devel] Poor netwo
On 04/12/14 14:09, Sander Eikelenboom wrote:
>
> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
>
>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>>
>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>>
On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>
> On Dec 4, 2014 6:30
Olaf Hering writes:
> On Wed, Dec 03, Vitaly Kuznetsov wrote:
>
>> Original description:
>>
>> When a PVHVM linux guest performs kexec there are lots of things which
>> require taking care of:
>> - shared info, vcpu_info
>> - grants
>> - event channels
>> - ...
>> Instead of taking care of all t
On 04/12/14 13:49, Jan Beulich wrote:
On 28.11.14 at 16:46, wrote:
>> On 28/11/14 15:18, Jan Beulich wrote:
>> On 28.11.14 at 14:55, wrote:
The problem is with continuations which reuse the upper bits of the
input register, not with this HVMOP_op_mask specifically; the
HVM
Hi,
In rumprun-xen [1] we use Mini-OS as a "base firmware" layer in our stack.
Currently we are using a slightly bastardized fork of the xen.git Mini-OS.
We would like to avoid this turning into a permanent fork. Following
previous discussion [2] on and openmirage-devel I would like to coordinate
On 04/12/14 13:32, Jan Beulich wrote:
On 04.12.14 at 13:58, wrote:
>> Konrad: I am requesting a release ack for this change. It aids the clarity
>> of
>> certain crash information, and prevents cascade pagefaults in certain
>> circumstances, which would prevent execution of the crash kernel
Hello Sander,
Thursday, December 4, 2014, 3:09:09 PM, you wrote:
> Thursday, December 4, 2014, 2:43:06 PM, you wrote:
>> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>>
>>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>>
On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>
>
Thursday, December 4, 2014, 2:43:06 PM, you wrote:
> On 04/12/14 13:10, Sander Eikelenboom wrote:
>>
>> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>>
>>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
On Dec 4, 2014 6:30 AM, David Vrabel wrote:
>
> On 03/12/14 21:40,
Hi,
following is a patch against vanilla Mini-OS in upstream xen.git for a
problem we have found in the netfront driver. When subjected to load
network receive would freeze due to the rx ring running out of free
request slots.
With this patch a httpd running on rumprun-xen [1] survives all the lo
On 04/12/14 03:50, Vijay Kilari wrote:
> Hi Tim,
Hi Vijay,
> I see that on uart interrupt, ICR is written to clear the all
> interrupts except TX, RX and RX timeout. With this, cpu always finds
> TX/RX is active and never
> comes out of the loop.
FWIW, the PL011 serial code has been copied from
>>> On 28.11.14 at 16:46, wrote:
> On 28/11/14 15:18, Jan Beulich wrote:
> On 28.11.14 at 14:55, wrote:
>>> The problem is with continuations which reuse the upper bits of the
>>> input register, not with this HVMOP_op_mask specifically; the
>>> HVMOP_op_mask simply adds to an existing proble
On 04/12/14 10:56, David Vrabel wrote:
> On 02/12/14 20:19, Boris Ostrovsky wrote:
>> Changes in v4:
>> * Added comment describing what we check for in pci_xen_init()
>
> I applied v3 ages ago to the devel/for-linus-3.19 branch and I'm not
> going to mess about replacing it for a comment change.
From: Yu Zhang
A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
the write operations on GPU's page tables. Handling of this new
p2m type are similar with existing p2m_ram_ro in most condition
checks, with only difference on final policy of emulation vs. drop.
For p2m_ram_ro types,
From: Yu Zhang
Currently, the P2M_RO_TYPES bears 2 meanings: one is
"_PAGE_RW bit is clear in their PTEs", and another is
to discard the write operations on these pages. This
patch adds a p2m type class, P2M_DISCARD_WRITE_TYPES,
to bear the second meaning, so we can use this type
class instead of
XenGT (Intel Graphics Virtualization technology, please refer to
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-
xengt) driver runs inside Dom0 as a virtual graphics device model,
and needs to trap and emulate the guest's write operations to some
specific memory pages, like memory p
On 04/12/14 13:10, Sander Eikelenboom wrote:
>
> Thursday, December 4, 2014, 1:24:47 PM, you wrote:
>
>> On 04/12/14 12:06, Konrad Rzeszutek Wilk wrote:
>>>
>>> On Dec 4, 2014 6:30 AM, David Vrabel wrote:
On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
>
> Instead of doing all
On 04/12/14 12:09, Zhangleiqiang (Trump) wrote:
I think that's expected, because guest RX data path still uses grant_copy while
>guest TX uses grant_map to do zero-copy transmit.
As I understand, the RX process is as follows:
1. Phy NIC receive packet
2. XEN Hypervisor trigger interrupt to Dom
>>> On 04.12.14 at 13:58, wrote:
> Konrad: I am requesting a release ack for this change. It aids the clarity of
> certain crash information, and prevents cascade pagefaults in certain
> circumstances, which would prevent execution of the crash kernel or a system
> reboot.
With
#ifndef NDEBUG
#
On Thu, 2014-12-04 at 13:22 +0100, Dario Faggioli wrote:
> On Tue, 2014-12-02 at 16:34 -0500, Boris Ostrovsky wrote:
>
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -1168,6 +1168,11 @@ _hidden int libxl__try_phy_backend(mode_t st_mode);
> >
> > _hidden cha
On Thu, 2014-12-04 at 07:13 -0500, Konrad Rzeszutek Wilk wrote:
> On Dec 4, 2014 6:55 AM, Ian Campbell wrote:
> >
> > On Wed, 2014-12-03 at 10:51 +, Ian Campbell wrote:
> > > On Wed, 2014-12-03 at 11:49 +0100, Olaf Hering wrote:
> > > > On Wed, Dec 03, Ian Campbell wrote:
> > > >
> > > > >
On Tue, 2014-12-02 at 13:43 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 04:04:44PM +, Wei Liu wrote:
> > On Tue, Dec 02, 2014 at 04:18:08PM +0100, Vitaly Kuznetsov wrote:
> > > XEN_DOMCTL_getdomaininfo, which is being used by xc_domain_getinfo(), has
> > > strange interface: i
On Tue, 2014-12-02 at 10:09 -0500, Konrad Rzeszutek Wilk wrote:
> > At this point in a freeze I'm much happier with:
> >
> > tools/pygrub/src/pygrub |4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
>
> The same here. This is now the season of handing out band-aids.
>
> As such
1 - 100 of 152 matches
Mail list logo
