Virtual Disk
1.0 PQ: 0 ANSI: 4
[8.434538] scsi host1: storvsc_host_t
[8.435324] sd 0:0:0:0: Attached scsi generic sg0 type 0
Any ideas why sda is never attached under Xen or how I can further diagnose
this?
Thanks,
Mark
[0.00] Initializing cgroup subsys cpuset
[0.00] In
it. I built Xen by doing 'make dist debug=y'.
What I did notice was that inside the /sys directory tree without Xenthere
were lots of files with a file name containing 'vmbus' but veryfew with
Xen. So I wonder if something is going wrong with thehv_vmbus driver.
I'm no expert on
On 29 March 2015 at 12:15, Jan Beulich wrote:
> >>> Mark 03/27/15 7:38 PM >>>
> >Are you saying that this isn't going to work by design?
>
> No, all I'm saying is that this case hasn't been considered so far.
>
> >I appreciate it'
e any ideas why it'd be getting stuck or how I can further debug
this?
Thanks,
Mark
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.18.10 (root@buildbuntu) (gcc version 4.8
> > - return 1;
> > + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> > + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> > + return 1;
> > + }
>
> Hmm, but xen_initial_domain() is false when
Xen /hypervisor node, I would prefer we
checked the compatible string rather than the path.
An is_xen_node() helper (which could also check that the path is
"/hypervisor") would avoid having redundant, subtly distinct ways of
checking, and would explicitly document precisely
On Wed, Apr 20, 2016 at 10:34:41AM +0100, Stefano Stabellini wrote:
> Hello Mark,
>
> do you think that this patch addresses your previous comments
> (http://marc.info/?l=devicetree&m=145926913008544&w=2) appropriately?
>
> Thanks,
>
> Stefano
>
>
e:
> >>>> There is a couple of assembly functions, which are invoked only locally
> >>>> in the file they are defined. In C, we mark them "static". In assembly,
> >>>> annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their
> >>&g
On Wed, Oct 25, 2017 at 04:21:48PM +0200, Jiri Slaby wrote:
> Hi,
>
> On 10/06/2017, 03:21 PM, Mark Rutland wrote:
> > If the aim of this series is to introduce something that architectures
> > use consistently, then can we please actually poke other architectures
> >
*/
> IMO the function description is pretty straight-forward.
> But let us wait for device tree guys feedback.
This might be the designed of *memblock*, but that does not mean that it
is a deliberate part of the DT handling. I beleive this is simply an
implementation detail that happens to mask a DT bug.
Thanks,
Mark.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
t irq, irq_handler_t handler,
unsigned long flags, const char *devname,
void __percpu *percpu_dev_id);
Thanks,
Mark.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm/perf/refactoring
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
55,7 +55,7 @@ static void efi_power_off(void)
> >
> > static int __init efi_shutdown_init(void)
> > {
> >- if (!efi_enabled(EFI_RUNTIME_SERVICES))
> >+ if (!efi_enabled(EFI_RUNTIME_SERVICES) || efi_enabled(EFI_PARAVIRT))
> >return -
previous permission and trap into the
> hypervisor the permission fault. However, as the permission as
> changed, p2m_memaccess_check may fail and we will inject an abort to
> the guest.
>
> The problem is very similar to [1]. This will still be tr
On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote:
> On 01/08/16 17:34, Mark Rutland wrote:
> >On Mon, Aug 01, 2016 at 04:40:50PM +0100, Julien Grall wrote:
> >>After I read again multiple time the ARM ARM (D4-1732 in ARM DDI
> >>0487A.i) and spoke with vari
Hi,
I realised I made a confusing mistake in my last reply; clarification below.
On Mon, Aug 01, 2016 at 06:26:54PM +0100, Mark Rutland wrote:
> On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote:
> > however we only need one TLBI instruction (assuming there is
> &g
On Tue, Aug 02, 2016 at 10:58:00AM +0100, Julien Grall wrote:
> On 01/08/2016 19:22, Mark Rutland wrote:
> >On Mon, Aug 01, 2016 at 06:26:54PM +0100, Mark Rutland wrote:
> >>On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote:
> >>>however we only need one TL
t;
> With a few more acks I think this should be ready to go. More testing is
> always appreciated though.
I've given the whole series a go with kasan, kexec, and hibernate (using
test_resume with the disk target), and everything looks happy. So FWIW,
for the series:
Reviewed-by: Mark
un an older build than
> >> intended. Simply hardcode the axf image file names.
> >>
> >> Signed-off-by: Christoffer Dall
> >> Signed-off-by: Andre Przywara
> >> Reviewed-by: Julien Grall
> >
> > Tested-by: Konrad Rzeszutek Wilk
> > Revie
([test "x$X_IMAGE" = "x"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
> +C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c09"
Just to check: what happesns if Dom0 tries to write to 0x1c09?
Shouldn't we override/delete earlyprintk/earlyco
and pushed it out to git.kernel.org.
I made minor tweaks to patches 1 and 3 for consistency, as noted in the
commit logs, but neither of these should have a functional impact.
Thanks,
Mark.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lis
der-y += shmbuf.h
> -header-y += sigcontext.h
> -header-y += signal.h
> -header-y += socket.h
> -header-y += sockios.h
> -header-y += stat.h
> -header-y += swab.h
> -header-y += termbits.h
> -header-y += termios.h
> -header-y += types.h
> -header-y += unistd.h
> g
On Wed, Mar 22, 2017 at 12:16:20PM +, Julien Grall wrote:
> (CC Mark for the TLB question)
[Adding Marc since he should understand this better than I do]
I've trimmed a lot of context here, since it wasn't clear if it was
relevant to the question. If there's something I
anipulate system registers which are
context switched with the thread, e.g. when setting tpidrro_el0 in
tls_thread_flush() [1].
Surely similar applies for the manipulation of other system registers
while in the guest context?
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds
+ barrier();
You can also have:
*res = READ_ONCE(*state);
That will which will handle the barriers implicitly.
Thanks,
Mark.
> + } while (get64(&state->state_entry_time) != state_time);
> +}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
ea get unregsitered when a kernel tears
things down, or is kexec somehow inhibited for xen guests?
i couldn't spot either happening, but I may have missed it.
Mark.
> +
> after_register_vcpu_info:
> enable_percpu_irq(xen_events_irq, 0);
> put_cpu();
> @@ -271,
On Fri, Nov 06, 2015 at 11:41:49AM +, David Vrabel wrote:
> On 06/11/15 11:39, Stefano Stabellini wrote:
> > On Thu, 5 Nov 2015, Mark Rutland wrote:
> >>> static void xen_percpu_init(void)
> >>> {
> >>> struct vcpu_register_vcpu_inf
On Fri, Nov 06, 2015 at 11:11:40AM +, Stefano Stabellini wrote:
> On Thu, 5 Nov 2015, Mark Rutland wrote:
> > Hi,
> >
> > > +static u64 get64(const u64 *p)
> > > +{
> > > + u64 ret;
> > > +
> > > + if (BITS_PER_LONG < 64)
> + delta = arch_timer_read_counter(); /* time since system boot */
> + delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec;
The arch counter value is not a number of nanoseconds (unless CNTFRQ
reads as 100), so this doesn't look right; the units don't matc
f we do that, and reuse
> the same names in the xen version (i.e., drop the "xen," prefix), we
> could make this change a *lot* simpler.
Regardless of if we drop the "linux," prefix from the existing strings,
I think we need the "xen," prefix here.
The xen EFI interface comes with additional caveats, and we need to
treat it separately.
Unless you're suggesting that /hypervisor/uefi-* is handled differently
to /chosen/uefi-*?
I think I'd still prefer the "xen," prefix regardless.
Thanks,
Mark.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hello,
http://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=summary
looking at the tags for the 2 stable branches which are involved in the recent
patch to xen.gitunifying the qemu trees.
tags:
qemu-xen-4.6.0qemu-xen-4.5.2
The revisions pointed to in the above tags are not unique and cause wrong
resu
quot; clocks in Xen to the hypervisor
> >node. The Linux kernel has to register the clocks from the hypervisor
> >node, then.
> >
> >Therefore, check if there is a "clocks" entry in the hypervisor node
> >and if so register the given clocks to the Linux kernel cloc
; Therefore, check if there is a "clocks" entry in the hypervisor node
> and if so register the given clocks to the Linux kernel clock
> framework and with this mark them as used. This prevents the clocks
> from being disabled.
>
> Signed-off-by: Dirk Behme
> ---
&
Hi,
On Thu, Jun 30, 2016 at 04:56:40PM +0200, Dirk Behme wrote:
> On 30.06.2016 16:21, Mark Rutland wrote:
> >On Thu, Jun 30, 2016 at 12:32:32PM +0200, Dirk Behme wrote:
> >>+- clocks: one or more clocks to be registered.
> >>+ Xen hypervisor drivers might replace n
;
> Therefore, check if there is a "clocks" entry in the hypervisor node
> and if so register the given clocks to the Linux kernel clock
> framework and with this mark them as used. This prevents the clocks
> from being disabled.
>
> Signed-off-by: Dirk Behme
>
Hi,
On Tue, Jul 05, 2016 at 12:45:34PM +0200, Dirk Behme wrote:
> On 05.07.2016 12:39, Mark Rutland wrote:
> >On Tue, Jul 05, 2016 at 08:50:23AM +0200, Dirk Behme wrote:
> >>+- clocks: one or more clocks to be registered.
> >>+ Xen hypervisor drivers might replace n
appy to see
> disabled clocks which are actually supposed to be used by some devices.
If you were to do that, that would cover the entire clock-controller,
not necessarily for the individual clock line (as this does not
necessarily have a node of its own). So you'd prevent the use of other
clocks owned by that controller.
That's also not sufficient, as you'd have to do the same for resources
required to keep that clock active (parent clocks from different
controllers, regulators, GPIOs, etc).
I don't think that will work other than in very basic cases.
Thanks,
Mark.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
eeds to be consistent with Linux. I would support PSCI
> 0.1 too.
That's not possible, so I don't follow. Prior to 0.2 the function IDs
are not defined.
The FADT has a single bit which describes PSCI 0.2+ being implemented,
and does not describe function IDs.
You must assume PSCI 0.2+ in order to have a set of function IDs to use.
You should also assume the presence of the rest of the mandatory
portions of PSCI 0.2, as these are also required per the combination of
the PSCI spec and the ACPI spec.
Mark.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
hould support PSCI 0.1 as well.
I believe that's an oversight in the ACPI documentation, which should
state 0.2+.
There was a deliberate decision that the FADT PSCI flag implied PSCI
0.2+, since prior to PSCI 0.2 function IDs were not well-defined, and
functions crticial for some uses cases
On Mon, Jan 04, 2016 at 03:00:45PM +, Mark Rutland wrote:
> On Mon, Jan 04, 2016 at 02:51:51PM +, Stefano Stabellini wrote:
> > On Wed, 30 Dec 2015, Shannon Zhao wrote:
> > > I check this again. There are not limitations of supporting PSCI version
> > > in ACPI S
f (spcr_uart_addr != 0x) {
The SPCR spec says that the Base Address fields being zero means that
console redirection is disabled (though I'm not clear on whether or not
that requires the whole acpi_generic_address to be zero).
Can we not use
e to,
given the compatiblity nightmare that's sure to result.
We should also consider if the "hypervisor" node name is sufficient (I
think it is, but let's not assume anything).
Mark.
>
> @@ -184,7 +187,8 @@ void __init acpi_boot_table_init(void)
> /*
>
on/arm/uefi.txt
> +which are used by normal UEFI. But to Xen ARM virtual platforms, it needs to
> +introduce a Xen specific UEFI and it doesn't want to mix with normal UEFI.
> +Therefore, it defines these parameters under /hypervisor node.
Could we please describe what that actual dif
(fdt_find_uefi_node, &uefi_found);
> + if (uefi_found)
> + set_bit(EFI_PARAVIRT, &efi.flags);
> + }
> }
This alone is insufficient given that we haven't parsed the rest of the
/hypervisor/uefi properties. Is the kernel resilient such that th
") != 0)
> - return 0;
> + if (efi_enabled(EFI_PARAVIRT)) {
> + if (depth != 2 || strcmp(uname, "uefi") != 0)
> + return 0;
Please check the full path rather than the leaf node name alone.
Mark.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
ule;
> + efi.query_capsule_caps = xen_efi_query_capsule_caps;
> + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
> + efi.reset_system = NULL;
> +}
How do capsules work in the absence of an EFI system reset?
Are there any other mandatory
On Mon, Jan 18, 2016 at 05:45:24PM +, Stefano Stabellini wrote:
> On Mon, 18 Jan 2016, Mark Rutland wrote:
> > On Fri, Jan 15, 2016 at 02:55:29PM +0800, Shannon Zhao wrote:
> > > +void __init xen_efi_runtime_setup(void)
> > > +{
> > > + efi.get_tim
On Tue, Jan 19, 2016 at 06:25:25PM +0800, Shannon Zhao wrote:
>
>
> On 2016/1/19 1:34, Stefano Stabellini wrote:
> > On Mon, 18 Jan 2016, Mark Rutland wrote:
> >> On Fri, Jan 15, 2016 at 02:55:25PM +0800, Shannon Zhao wrote:
> >>> From: Shannon Zhao
On Tue, Jan 19, 2016 at 12:03:59PM +, Stefano Stabellini wrote:
> On Mon, 18 Jan 2016, Mark Rutland wrote:
> > On Mon, Jan 18, 2016 at 05:45:24PM +, Stefano Stabellini wrote:
> > > On Mon, 18 Jan 2016, Mark Rutland wrote:
> > > > On Fri, Jan 15, 2016 at 02:55:
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:
> > > >> We don't do this in Documentation/arm/uefi.txt, and I don't see
t;>+ if (depth != 2 || strcmp(uname, "uefi") != 0)
> >
> >You are already introducing this check in the previous patch when
> >setting EFI_PARAVIRT, why do this again now? But if we need to do this
> >check again, then, like Mark suggested, it should be d
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, 20
; +/hypervisor node.
>
> Please replace the paragraph with the following which mentions
> include/xen/interface/platform.h and improves the wording:
>
> "The format and meaning of the "xen,uefi-*" parameters are similar to
> those in Documentation/arm/uefi.txt, w
gt; > Xen opens the window wider.
You definitely want that one. Without it, the page table walker could
end up using a stale pointer to a page being used for something other
than page tables.
> >
> > How confident are you in
> >
> > https://github.com/colum
On Tue, 2015-03-24 at 09:54 -0400, Mark Salter wrote:
> On Mon, 2015-03-23 at 23:58 +, Stefano Stabellini wrote:
> > On Mon, 23 Mar 2015, Christoffer Dall wrote:
> > > On Mon, Mar 23, 2015 at 1:36 PM, Ian Campbell
> > > wrote:
> > > On Sat, 2015-03
berately trying to replicate the issue, but the problem doesn't
manifest.
Mark
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 31 March 2015 at 11:56, Mark Chambers wrote:
>
>
> It's nested under Hyper-V in the same manner as the problematic install. I
> was deliberately trying to replicate the issue, but the problem doesn't
> manifest.
>
> Mark
>
>>
>
Hi,
I've go
rm(64) kernels
other than a PE/COFF EFI application.
Does Xen not talk to EFI itself and/or give the kernel a virtual EFI
interface?
Thanks,
Mark.
> Documentation/arm/uefi.txt | 10 +-
> drivers/firmware/efi/efi.c | 10 +-
> drivers/firmware/efi/libstub/f
EFI entry point,
simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest
to make things sane for itself...
Mark.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote:
> On Thu, 10 Sep 2015, Mark Rutland wrote:
> > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI
> > > > interface?
> > >
> > > Xen talks to EFI itself b
On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote:
> On Thu, 10 Sep 2015, Mark Rutland wrote:
> > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote:
> > > On Thu, 10 Sep 2015, Mark Rutland wrote:
> > > > > > Does Xen not talk to
On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote:
> >>> On 10.09.15 at 13:37, wrote:
> > On Thu, 10 Sep 2015, Mark Rutland wrote:
> >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g.
> >> create pages of RuntimeServicesCode t
ortant, as Ian
> > > wrote what is important is how to pass the RSDP.
> >
> > Unfortunately we're still going to have to care about this eventually,
> > even if for something like kexec. So we still need to spec out the state
> > of things if this is going to be
On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
> > > > C) When you could go:
> > > >
> > > >DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACP
ws is safe for us to use, rather
than we tip-toe around until we're sure Xen isn't present and/or doesn't
need additional constraints met.
Thanks,
Mark.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
provide
a known-safe (but potentially sub-optimal) view to the kernel by
default.
> > Incompatible changes are a spec problem regardless of how this is
> > handled.
>
> Not necessarily - we don't expose the memory map (we'd have to
> if we were to mimic EFI for Dom0
On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
>
>
- Support for 64KB in gnttdev
> - Support of non-indirect grant with 64KB frontend (patch sent [1])
> - It may be possible to move some common define between
> netback/netfront and blkfront/blkback in an header
Would any of these require more work to also handle 16K?
T
ething.
>
> Correct, this series is able to cope with any PAGE_SIZE as long as it's
> a multiple of the granularity used by Xen (i.e 4KB on ARM).
[...]
> > Would any of these require more work to also handle 16K?
>
> No. It should just boot on Xen as long as
copy.
Later kernel_zimage_load calls copy_from_paddr, which uses a
non-cacheable alias, bypassing the caches and going straight to memory.
Even if the two aliases were in use simultaneously, they wouldn't be
coherent with each other.
For more background, Marc Zyngier did a good talk at KV
think I can fix this, but I have no business submitting a patch for a
blue-chip project.
thanks for developer attention on this,Mark
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Instead of tracking down which commit involving libxl* which prints all kind of
noiseto stderr, I will post a workaround.
If you build, install, and use 4.5 this bug will drive you mad, so here it is:
snip -
--- a/tools/hotplug/Linux/xendomains.in+++ b/tools/
:`$(which
xendomains) start`
I am using the above patch to rdname() in all my dom0 builds with 4.5 (HEAD) to
avoid this trouble.
On Saturday, December 13, 2014 8:45 AM, Wei Liu
wrote:
On Sat, Dec 13, 2014 at 01:34:14AM +, Mark Pryor wrote:
> Instead of tracking down which com
Signed-off-by: Mark Pryor
---
src/kbd.c | 6 +++---
src/mouse.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/kbd.c b/src/kbd.c
index 33a95a3..fbcecc3 100644
--- a/src/kbd.c
+++ b/src/kbd.c
@@ -11,7 +11,7 @@
#include "hw/ps2port.h" // ps2_kbd_command
Signed-off-by: Mark Pryor
---
.../firmware/etherboot/patches/ipxe-ath9k-gcc5.patch | 20
.../etherboot/patches/ipxe-ath9k2-gcc5.patch | 20
tools/firmware/etherboot/patches/series | 2 ++
3 files changed, 42 insertions(+)
create
r format) that could trip up existing PSCI 0.2 aware OSs,
but hopefully we won't have that kind of thing happen again.
> (which begs the question why there is not a "arm,psci-1.x" compat string,
> Mark/Andre?)
There will be one, in fact (see Lorenzo's pull request
On 31 March 2015 at 17:31, Mark Chambers wrote:
>
> On 31 March 2015 at 11:56, Mark Chambers wrote:
>>
>>
>> It's nested under Hyper-V in the same manner as the problematic install.
>> I was deliberately trying to replicate the issue, but the prob
Hello Xen,
after failing with the combo of system-219 + ocamltools (4.01) in Ubuntu Vivid
(15.04) I wanted to seeif Debian can get this combination right.
After learning that the Debian experimental repo has a build of systemd-219 I
went to work.
First cloned my Deb8 LVM with the buildroot into a
77 matches
Mail list logo
