All guys,
Sorry to raise a question to you since I'm not very sure how to deal
with this.
When I passthrough a device like IGD, I can see so many messages:
"memory_map:add:" and "memory_map:remove:"
since we have to add/remove all pages map residing PCI bar. Especially
as a graphic devi
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 07, 2015 9:05 PM
> To: Wu, Feng
> Cc: Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v6 17/18] VT-d: Dump the posted format IRTE
>
> >>> On 25.08.15 at 03:
branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-vhd
test debian-di-install
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-u
>>> "Wu, Feng" 09/08/15 4:39 AM >>>
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, September 07, 2015 6:46 PM
>> >>> On 06.09.15 at 04:05, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Friday, September 04, 2015 10:40 PM
>> >> >>> On 25.08.15 at 03:57, w
flight 61512 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61512/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qcow2 9 debian-di-install fail REGR. vs. 60727
test-amd64-i386-x
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 07, 2015 8:10 PM
> To: Wu, Feng; Zhang, Yang Z
> Cc: Andrew Cooper; Tian, Kevin; xen-devel@lists.xen.org; Keir Fraser
> Subject: Re: [PATCH v6 15/18] vmx: Properly handle notification event when
>>> "Wu, Feng" 09/08/15 4:39 AM >>>
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, September 07, 2015 6:43 PM
>> >>> 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, w
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 07, 2015 7:03 PM
> To: Wu, Feng
> Cc: xen-devel@lists.xen.org
> Subject: RE: [PATCH v6 13/18] Update IRTE according to guest interrupt config
> changes
>
> >>> On 06.09.15 at 06:54, wrote:
> >>
Ok, I will try to explain, correct me if I got anything wrong:
The problem here is not interrupts lost but interrupts not delivered in
time.
there are basically two path to inject an interrupt into VM (or vCPU to
another vCPU):
Path 1, the traditional way:
1) set bit in vlapic IRR fi
Hi Vladimir,
Do you have any suggestion on this patchset?
Do I need to improve anything?
Great thanks for your help.
On 4 August 2015 at 16:34, Fu Wei wrote:
> Hi Vladimir,
>
> this patchset follows all your comment of v2 patchset.
> Do you have any suggestion on this patchset?
>
> Great thanks
branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
test debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenb
Hanweidong (Randy) wrote on 2015-09-08:
>
> Jan Beulich wrote on ent: 2015年9月7日 22:46:
>> Subject: Re: [Xen-devel] [PATCH] Remove a set operation for
>> VCPU_KICK_SOFTIRQ when post interrupt to vm.
>>
> On 07.09.15 at 16:24, wrote:
>>> I believe this also has something to do with a windows g
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 07, 2015 6:46 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 helper functions for
> Posted-Interrupts
>
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 07, 2015 6:43 PM
> To: Wu, Feng
> Cc: Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [PATCH v6 04/18] vt-d: VT-d Posted-Interrupts feature
> detection
>
> >>> On
> -Original Message-
> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew Cooper
> Sent: Monday, September 07, 2015 5:49 PM
> To: wangxin (U); xen-de...@lists.xenproject.org
> Cc: Fanhenglong; wei.l...@citrix.com; Hanweidong (Randy)
> Subject: Re: [Xen-devel] BUG: fai
Jan Beulich wrote on 2015-09-07:
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 supportin
flight 61516 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61516/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail
REGR. vs. 60958
test-am
Currently we don't allow passing through any group devices which are
sharing same RMRR entry since it would break security among VMs. And
indeed, we expect we can figure out a better way to handle this kind
of case completely.
But before the group assignment gets implemented, we might make this
pe
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 2015年9月7日 22:46
> To: Liuqiming (John)
> Cc: Hanweidong (Randy); Zhangwei (FF); yang.z.zh...@intel.com; xen-
> de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] Remove a set operation for
> VCPU_KICK_SO
On Mon, Sep 07, 2015 at 05:28:26PM +0100, George Dunlap wrote:
> On Wed, Jul 30, 2014 at 5:40 PM, Luis R. Rodriguez
> wrote:
> > From: "Luis R. Rodriguez"
> >
> > As it stands oxenstored will be used by default if ocaml tools are
> > found, the init system will also try to use oxenstored first if
On Mon, Sep 07, 2015 at 08:45:20PM +0300, Valtteri Kiviniemi wrote:
>Hi,
>
Hi,
>I'm using a Asus X99-A motherboard with latest bios which in paper (and in
>BIOS) supports VT-d. However, with Xen 4.5.1 and Xen unstable the VT-d
>fails completely on SATA AHCI with "failed to IDENTI
Hi,
I'm using a Asus X99-A motherboard with latest bios which in paper (and in
BIOS) supports VT-d. However, with Xen 4.5.1 and Xen unstable the VT-d
fails completely on SATA AHCI with "failed to IDENTIFY".
I also tried to disable the SATA controller completely from BIOS and try to
boot from USB
On Thu, 3 Sep 2015, Juergen Gross wrote:
> Add a backend for para-virtualized USB devices for xen domains.
>
> The backend is using host-libusb to forward USB requests from a
> domain via libusb to the real device(s) passed through.
>
> Signed-off-by: Juergen Gross
Aside from a few minor commen
On Mon, Sep 07, 2015 at 03:13:50PM +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 re
You might need to rebase you patch. A patch to netback went it recently.
On Mon, Sep 07, 2015 at 04:33:56PM +0100, Julien Grall wrote:
> 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
On Mon, 7 Sep 2015, Julien Grall wrote:
> 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
On Mon, Sep 07, 2015 at 05:06:36PM +0100, Ian Campbell wrote:
> On Mon, 2015-09-07 at 16:08 +0100, Stefano Stabellini wrote:
> > 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,
> > > > otherwis
On Wed, Jul 30, 2014 at 5:40 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> As it stands oxenstored will be used by default if ocaml tools are
> found, the init system will also try to use oxenstored first if its
> found otherwise the cxenstored will be used. Lets simplify the init
Use manual_allocation_base_jobinfo to obtain some information which
will go into `job' in the planner, and show up everywhere.
Put just the request (from the command line) in the Xinfo.
Signed-off-by: Ian Jackson
---
v2: New patch
---
mg-allocate |7 +--
1 file changed, 5 insertions(+),
This makes it slightly easier to see what it's happening if
mg-allocate or mg-blockage has no tty.
Signed-off-by: Ian Jackson
---
v2: New patch
---
mg-allocate |2 ++
mg-blockage |2 ++
2 files changed, 4 insertions(+)
diff --git a/mg-allocate b/mg-allocate
index 672d9ec..1e517a2 100755
This allows retrieval, by monitoring clients which are not
participating in the planning queue, of the finished projection, or
the unfinished plan as it was at the time of last restart.
Signed-off-by: Ian Jackson
---
v2: Fix invocation of return-plan-to-client.
Use data-W.final.pl, not data-W
Add a new parameter to $resourcecall which allows the alloc_resources
loop in Osstest::Executive to specify to its clients that on this
occasion they should not make any actual allocations.
The callers of alloc_resources are all adjusted to honour this new
parameter:
* ts-hosts-allocate-Executive
Supply most of the information about our allocations in JobInfo,
rather than Xinfo. And, correspondingly, rename all the variables
`xinfo' to `info'.
Supply only the supplied hostname as the Xinfo. This is slightly
redundant but it does at least tell us what came out of the db.
Signed-off-by: I
We are going to introduce multiple concurrent streams of planning
processing, called `walkers'.
Prepare the ground for this with some formulaic changes which will
otherwise greatly clutter substantive patches.
(A client will still only think for one walker at once, because that's
what the client
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
README.planner | 10 ++
1 file changed, 10 insertions(+)
diff --git a/README.planner b/README.planner
index 4cf682d..ef2acba 100644
--- a/README.planner
+++ b/README.planner
@@ -184,6 +184,16 @@ ms-queuedaemon commands
< O
We are going to want to process each walker's data into reports which
are not necessarily named after the same walker.
No functional change as yet.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
ms-queuedaemon |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
This series addresses a performance problem which we seem to be
experiencing with the existing osstest resource planner in Xen Project
test colo. The current setup can leave hosts idle for too long before
getting around to allocating them to test jobs.
There are also some reporting/debugging impr
* Document the ms-queuedaemon banner
* Document the argument to the allocation $resourcecall callback fn.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
Osstest/Executive.pm |2 +-
README.planner |3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/Osstes
This formalises the queue-completed interface, allowing parts outside
the queuerun machinery to cleanly be notified when a queue is
completed, and relieving the queuerun-perhaps-step of the need to know
what to do for the end of any particular walker's queue.
Currently there is still only one walk
This makes it possible to run mg-allocate with a different priority
simply by setting OSSTEST_RESOURCE_PRIORITY in its environment.
Signed-off-by: Ian Jackson
---
v2: New patch
---
mg-allocate |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mg-allocate b/mg-allocate
index
If multiple walkers want to ask the same chan, we want to serialise
them. This is actually straightforward: Firstly, we arrrange that
each walker finishing a thought will prompt _all_ walkers to
reconsider whether they need to continue. Then we can simply do
nothing if we want to a chan to think
We are going to introduce multiple concurrent streams of planning
processing, called `walkers' in ms-queuedaemon. The work-in-progress
plan is stored, server-side, during planning, in data-plan.pl. But we
need to have more than one of these.
Update ms-planner and ms-planner-debug to honour a -w
This solves a performance problem with the existing planner.
The problem is that with a large installation, and a big queue, a full
plan can take a long time to prepare. (In our current installation,
perhaps as long as half an hour.) Any resource which becomes free
during one plan run cannot be
Introduce a way for the queue daemon to tell its client that it must
not allocate anything in this planning iteration.
In the client:
* Advertise the new feature via set-info.
* Accept the `noalloc' part of `!OK think noalloc';
* Print that in our log message;
* Honour it by passing it to $res
This does not mean the planner is `idle' in any general sense of the
word. It just means that the Tcl event loop has finished processing
outstanding events. Change the debug message to be less confusing.
Signed-off-by: Ian Jackson
---
v2: New patch
---
ms-queuedaemon |2 +-
1 file changed,
This is going to want to do something more complicated shortly.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
v2: Fix a whitespace error
---
ms-queuedaemon | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/ms-queuedaemon b/ms-queuedaemon
index 3026a64..1f
This relieves the callers of the need to provide a desc. This is
helpful because chan-note-unprocessed doesn't have one.
Overall functional change is to show the chan desc (ie, the client TCP
connection info) in the list of unprocessed clients.
Signed-off-by: Ian Jackson
---
v2: New patch
---
Signed-off-by: Ian Jackson
---
v2: New patch
---
Osstest/Executive.pm |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 1efcfd4..84600b4 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -498,7 +498,10 @@ END
These wider fields will work well for up to 999 tasks.
Cosmetic change only.
Signed-off-by: Ian Jackson
---
v2: New patch
---
ms-queuedaemon | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/ms-queuedaemon b/ms-queuedaemon
index 9280f51..98cf5c1 100755
--- a/ms
Provide a facility for the daemon main program to get the channel
connection information.
No caller yet.
Signed-off-by: Ian Jackson
---
v2: New patch
---
tcl/daemonlib.tcl |5 +
1 file changed, 5 insertions(+)
diff --git a/tcl/daemonlib.tcl b/tcl/daemonlib.tcl
index d097624..55bc385 10
We are going to want to reuse this. No functional change.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
ms-queuedaemon |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/ms-queuedaemon b/ms-queuedaemon
index d48715e..8c9af81 100755
--- a/ms-queuedaemon
+++
This is called `jobinfo' because it ought to be used in
alloc_resources's JobInfo xparam, rather than an Xinfo in the booking:
JobInfo is per planning client; Xinfo is per individual resource.
mg-blockage currently gets this wrong; we will fix that shortly.
Signed-off-by: Ian Jackson
---
v2: New
Also, refactor the space separator handling to use a list and `join'
(since we are going to maybe have desc be "").
Signed-off-by: Ian Jackson
---
v2: New patch
---
ms-queuedaemon | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/ms-queuedaemon b/ms-queuedaemon
ind
(This will only take effect as such tasks appear in the plan for the
first time. Ie, once a rogue task is found, the plan is populated by
whatever version of the planner is running at that time. So the
effect will not be immediately visible.)
Signed-off-by: Ian Jackson
---
v2: New patch
---
ms
With recent changes, it can happen that a queue daemon client is not
given an opportunity to report itself in the plan. This makes the
plan incomplete.
(For resource-plan.html, because the planning run was restarted to try
to quickly allocate new resources; for resource-projection.html,
because i
Change `./ms-planner unprocessed' to take a file of infos on stdin,
and when we restart the planning, invoke it once.
(This would be an incompatible change to the planner, needing a
queuedaemon restart, if this patch were applied separately from the
previous "Report unprocessed planning clients".)
In ms-queuedaemon, and JobDB-Executive, once each. No functional
change.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
ms-queuedaemon |3 +--
tcl/JobDB-Executive.tcl |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/ms-queuedaemon b/ms-queuedaemon
runneeded-ensure-will would always reset the runneeded_holdoff_after
timer. So no new queue run would start until no runneeded-ensure-will
has occurred for (currently) 30s.
Instead, only start the timer if it's not already running.
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
---
ms-queu
Daniel,
I am assuming it is OK to post this one to the devel-list, to get extra answers.
> On 7 Sep 2015, at 16:19, Daniel Izquierdo wrote:
>
> Hi Lars,
>
> I promise this is the last email ;).
>
> We've found that there are several flags launched by different
> developers depending on the st
On Mon, 2015-09-07 at 16:08 +0100, Stefano Stabellini wrote:
> 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,
>
On Mon, Sep 07, 2015 at 09:15:40AM -0600, Jan Beulich wrote:
> >>> 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 wh
On Mon, Sep 07, 2015 at 09:23:59AM -0600, Jan Beulich wrote:
> >>> 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 +
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Changes in v3:
- Fix errors reported by checkpatch.pl
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity behaving as a
block backend on a non-modified Xen.
It's only necessary to adapt the ring size and the number of request per
indirect frames. The rest of the code is relying o
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
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
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 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
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 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
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
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 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 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 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 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 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:
> >>
>
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 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
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: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 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 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 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
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
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
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
1 - 100 of 164 matches
Mail list logo
