Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute
Hi, On Wed, Nov 08, 2017 at 09:44:48AM -0600, Govinda Tatti wrote: > Thanks Jan for your review comments. Please see below for my comments. > > On 11/7/2017 8:40 AM, Jan Beulich wrote: > On 06.11.17 at 18:48, wrote: > >>--- a/Documentation/ABI/testing/sysfs-driver-pciback > >>+++ b/Documentation/ABI/testing/sysfs-driver-pciback > >>@@ -11,3 +11,15 @@ Description: > >> #echo 00:19.0-E0:2:FF > > >> /sys/bus/pci/drivers/pciback/quirks > >> will allow the guest to read and write to the > >> configuration > >> register 0x0E. > >>+ > >>+What: /sys/bus/pci/drivers/pciback/do_flr > >>+Date: Nov 2017 > >>+KernelVersion: 4.15 > >>+Contact:xen-de...@lists.xenproject.org > >>+Description: > >>+An option to perform a slot or bus reset when a PCI device > >>+ is owned by Xen PCI backend. Writing a string of :BB:DD.F > >>+ will cause the pciback driver to perform a slot or bus reset > >>+ if the device supports it. It also checks to make sure that > >>+ all of the devices under the bridge are owned by Xen PCI > >>+ backend. > >Why do you name this "do_flr" when you don't even try FLR, but > >go to slot or then bus reset right away. > Yes, I agree but xen toolstack has already been modified to consume"do_flr" > attribute. Hence, we are using the > function that matches with sysfs attribute. > Hmm.. I remember some discussion from ages ago related to this. Back then it was suggested to "emulate" the flr capability (by doing slot or bus reset) for devices which don't have *native* flr available? So is this patch perhaps related to that? If the PCI device in question has native flr capability, then native flr is used, right ? I guess I should read the full patch.. -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
On Thu, Nov 02, 2017 at 05:11:17PM +, Roger Pau Monné wrote: > On Thu, Nov 02, 2017 at 07:02:49PM +0200, Pasi Kärkkäinen wrote: > > On Thu, Aug 24, 2017 at 09:23:16AM +0100, Roger Pau Monné wrote: > > > On Wed, Aug 23, 2017 at 07:13:00PM +0200, Andreas Kinzler wrote: > > > > > > > From a brief look it looks like this would be doable, but the way > > > > > > these flags are being communicated is rather ugly (the values used > > > > > > here > > > > > > > aren't part of the public interface, and hence it wasn't > > > > > > > immediately > > > > > > > clear whether using one of the unused bits would be an option, but > > > > > > > it looks like it is). > > > > > > Yes, it's not pretty... Last used bit is 15, hence bit 16 could be > > > > > > used to signal to Xen whether the interrupt should be unmasked after > > > > > > binding. I have a half-drafted patch, will finish it now. > > > > > Andreas, could you please give a try to the attached two patches? One > > > > > is for Xen and the other one is for QEMU. > > > > > > > > Seems to work after I fixed a bug ;-) > > > > > > > > -gflags |= masked ? 0 : XEN_PT_GFLAGSSHIFT_UNMASKED; > > > > +gflags |= masked ? 0 : (1 << XEN_PT_GFLAGSSHIFT_UNMASKED); > > > > > > > > Please let Jan and/or others review the patches. > > > > > > Thanks. I would like to add your tested-by if possible, since I'm not > > > able to trigger this behavior myself. > > > > > > > Hmm.. did these patches get merged / acked? > > Yes, both the QEMU and the Xen sides have been merged. > Great, thanks a lot! > Roger. -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
On Thu, Aug 24, 2017 at 09:23:16AM +0100, Roger Pau Monné wrote: > On Wed, Aug 23, 2017 at 07:13:00PM +0200, Andreas Kinzler wrote: > > > > > From a brief look it looks like this would be doable, but the way > > > > these flags are being communicated is rather ugly (the values used > > > > here > > > > > aren't part of the public interface, and hence it wasn't immediately > > > > > clear whether using one of the unused bits would be an option, but > > > > > it looks like it is). > > > > Yes, it's not pretty... Last used bit is 15, hence bit 16 could be > > > > used to signal to Xen whether the interrupt should be unmasked after > > > > binding. I have a half-drafted patch, will finish it now. > > > Andreas, could you please give a try to the attached two patches? One > > > is for Xen and the other one is for QEMU. > > > > Seems to work after I fixed a bug ;-) > > > > -gflags |= masked ? 0 : XEN_PT_GFLAGSSHIFT_UNMASKED; > > +gflags |= masked ? 0 : (1 << XEN_PT_GFLAGSSHIFT_UNMASKED); > > > > Please let Jan and/or others review the patches. > > Thanks. I would like to add your tested-by if possible, since I'm not > able to trigger this behavior myself. > Hmm.. did these patches get merged / acked? Thanks, -- Pasi > Roger. > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] pci-passthrough loses msi-x interrupts ability after domain destroy
Hi, On Fri, Sep 22, 2017 at 03:25:00PM -0400, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 22, 2017 at 09:35:40AM +0200, Sander Eikelenboom wrote: > > On 22/09/17 04:09, Christopher Clark wrote: > > > On Thu, Sep 21, 2017 at 1:27 PM, Sander Eikelenboom > > > wrote: > > >> > > >> On Thu, September 21, 2017, 10:39:52 AM, Roger Pau Monné wrote: > > >> > > >>> On Wed, Sep 20, 2017 at 03:50:35PM -0400, Jérôme Oufella wrote: > > > > I'm using PCI pass-through to map a PCIe (intel i210) controller into > > a HVM domain. The system uses xen-pciback to hide the appropriate PCI > > device from Dom0. > > > > When creating the HVM domain after an hypervisor cold boot, the HVM > > domain can access and use the PCIe controller without problem. > > > > However, if the HVM domain is destroyed then restarted, it won't be > > able to use the pass-through PCI device anymore. The PCI device is > > seen and can be mapped, however, the interrupts will not be passed to > > the HVM domain anymore (this is visible under a Linux guest as > > /proc/interrupts counters remain 0). The behavior on a Windows10 guest > > is the same. > > > > A few interesting hints I noticed: > > > > - On Dom0, 'lspci -vv' on that PCIe device between the "working" and > > the "muted interrupts" states, I noted a difference between the > > MSI-X caps: > > > > - Capabilities: [70] MSI-X: Enable- Count=5 Masked- <-- IRQs will work > > if domain started > > + Capabilities: [70] MSI-X: Enable- Count=5 Masked+ <-- IRQs won't > > work if domain started > > ^^^ > > >> > > >>> IMHO it seems that either your device is not able to perform a reset > > >>> successfully, or Linux is not correctly performing such reset. I don't > > >>> think there's a lot that can be done from the Xen side. > > >> > > >> Unfortunately for a lot of pci-devices a simple reset as performed by > > >> default isn't enough, > > >> but also almost none support a real pci FLR. > > >> > > >> In the distant past Konrad has made a patchset that implemented a bus > > >> reset and > > >> reseting config space. (It piggy backed on already existing libxl > > >> mechanism of > > >> trying to call on a syfs "do_flr" attribute which triggers pciback to > > >> perform > > >> the busreset and rewrite of config space for the device. > > >> > > >> I use that patchset ever since for my pci-passtrough needs and it works > > >> pretty > > >> well. I can shutdown an restart VM's with pci devices passed trhough > > >> (also AMD > > >> Radeon graphic cards). > > > > > > Just to confirm the utility of that piece of work: OpenXT also uses an > > > extended version of that same patch to perform device reset for > > > passthrough. > > > > > > I've attached a copy of that OpenXT patch to this message and it can > > > also be obtained from our git repository: > > > https://github.com/OpenXT/xenclient-oe/blob/f8d3b282a87231d9ae717b13d506e8e7e28c78c4/recipes-kernel/linux/4.9/patches/thorough-reset-interface-to-pciback-s-sysfs.patch > > > This version creates a sysfs node named "reset_device" and the OpenXT > > > libxl toolstack is patched to use that node instead of "do_flr". > > > > Nice to hear there are more users of this patch. On #xen on IRC there were > > from time to time > > also users who tried pci-passtrough and ran into this issue (and probably > > abandonning the idea > > since having to restart your host before being able to use your pass > > throughed device again > > defies much of the use case). > > > > > Konrad's original work encountered pushback on upstream acceptance at > > > the time it was developed. I'm not sure I've found where that > > > discussion ended. Is there any prospect of a more comprehensive reset > > > mechanism being accepted into xen-pciback, or elsewhere in the kernel? > > > > Yeah it was nacked by David Vrabel and the discussion somewhat bleeded to > > death. > > >From what i remember the main issue was with the naming, since it doesn't > > >do a FLR, > > the sysfs hook shouldn't be called "do_flr". > > > > Some other perhaps minor issues i can think of are: > > - No way to excempt pci-devices from this new way of resetting them. > > Perhaps there could be pci devices/topologies were this way of > > resetting causes more problems than it solves and could cause a > > regression. Unfortunately auto detecting what works doesn't seem to > > be possible. On the other hand (though only with my n=10) i haven't > > encountered > > such a device yet. > > > > - The communication path between libxl and the kernel via sysfs. > > I think the preference was for a: > > a) having it use a more common used Xen communication channel or > > b) having it all self-contained in pci-back. (from my memory and the > > openxt patch description > > there could be some locking issue when try
Re: [Xen-devel] pci-passthrough loses msi-x interrupts ability after domain destroy
Hi, On Thu, Sep 21, 2017 at 07:09:12PM -0700, Christopher Clark wrote: > On Thu, Sep 21, 2017 at 1:27 PM, Sander Eikelenboom > wrote: > > > > On Thu, September 21, 2017, 10:39:52 AM, Roger Pau Monné wrote: > > > >> On Wed, Sep 20, 2017 at 03:50:35PM -0400, Jérôme Oufella wrote: > >>> > >>> I'm using PCI pass-through to map a PCIe (intel i210) controller into > >>> a HVM domain. The system uses xen-pciback to hide the appropriate PCI > >>> device from Dom0. > >>> > >>> When creating the HVM domain after an hypervisor cold boot, the HVM > >>> domain can access and use the PCIe controller without problem. > >>> > >>> However, if the HVM domain is destroyed then restarted, it won't be > >>> able to use the pass-through PCI device anymore. The PCI device is > >>> seen and can be mapped, however, the interrupts will not be passed to > >>> the HVM domain anymore (this is visible under a Linux guest as > >>> /proc/interrupts counters remain 0). The behavior on a Windows10 guest > >>> is the same. > >>> > >>> A few interesting hints I noticed: > >>> > >>> - On Dom0, 'lspci -vv' on that PCIe device between the "working" and > >>> the "muted interrupts" states, I noted a difference between the > >>> MSI-X caps: > >>> > >>> - Capabilities: [70] MSI-X: Enable- Count=5 Masked- <-- IRQs will work if > >>> domain started > >>> + Capabilities: [70] MSI-X: Enable- Count=5 Masked+ <-- IRQs won't work > >>> if domain started > >>> ^^^ > > > >> IMHO it seems that either your device is not able to perform a reset > >> successfully, or Linux is not correctly performing such reset. I don't > >> think there's a lot that can be done from the Xen side. > > > > Unfortunately for a lot of pci-devices a simple reset as performed by > > default isn't enough, > > but also almost none support a real pci FLR. > > > > In the distant past Konrad has made a patchset that implemented a bus reset > > and > > reseting config space. (It piggy backed on already existing libxl mechanism > > of > > trying to call on a syfs "do_flr" attribute which triggers pciback to > > perform > > the busreset and rewrite of config space for the device. > > > > I use that patchset ever since for my pci-passtrough needs and it works > > pretty > > well. I can shutdown an restart VM's with pci devices passed trhough (also > > AMD > > Radeon graphic cards). > > Just to confirm the utility of that piece of work: OpenXT also uses an > extended version of that same patch to perform device reset for > passthrough. > > I've attached a copy of that OpenXT patch to this message and it can > also be obtained from our git repository: > https://github.com/OpenXT/xenclient-oe/blob/f8d3b282a87231d9ae717b13d506e8e7e28c78c4/recipes-kernel/linux/4.9/patches/thorough-reset-interface-to-pciback-s-sysfs.patch > This version creates a sysfs node named "reset_device" and the OpenXT > libxl toolstack is patched to use that node instead of "do_flr". > > Konrad's original work encountered pushback on upstream acceptance at > the time it was developed. I'm not sure I've found where that > discussion ended. Is there any prospect of a more comprehensive reset > mechanism being accepted into xen-pciback, or elsewhere in the kernel? > > As noted in the original LKML threads, vfio has similar relevant pci > device reset retry logic. (Thanks to Rich Persaud for this pointer:) > http://elixir.free-electrons.com/linux/v4.14-rc1/source/drivers/vfio/pci/vfio_pci.c#L1353 > > libvirt also performs similar reset logic, using a direct low level > interface to config space (Thanks to Marek for this pointer, libvirt > is used by Qubes:) > https://github.com/libvirt/libvirt/blob/master/src/util/virpci.c#L929 > I thinks this indicates that it would be possible to extend libxl to > do something similar, but that seems less satisfactory compared to > performing the work in a kernel-provided implementation. > > Is there a way forward to providing this functionality within Xen > software or Linux? > Adding Konrad to CC .. -- Pasi > Christopher > -- > > openxt.org > From d686351d8ea4a1ea1d755d0a10f6f14d1c870911 Mon Sep 17 00:00:00 2001 > From: Kyle Temkin > Date: Wed, 8 Apr 2015 00:58:24 -0400 > Subject: [PATCH] Add thorough reset interface to pciback's sysfs. > > > SHORT DESCRIPTION: > > Adds an interface that allows "more thorough" resets to be performed > on devices which don't support Function Level Resets (FLRs). This > interface should allow the toolstack to ensure that a PCI device is in a > known state prior to passing it through to a VM. > > > LONG DESCRIPTION: > > > From Konrad Rzeszutek Wilk's original post to
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
Hi, On Mon, Jul 17, 2017 at 06:32:42PM +0200, Andreas Kinzler wrote: > Hello Jan, Pasi, all > > >>Jan, I still have access to the hardware so perhaps we can finally solve > >>this problem. > >Feel free to go ahead; I'll be on vacation for the next three weeks. > > Perhaps we can shortcut debugging a bit because I looked through the patches > of XenServer 7.2 and found the attached patch. Now I tried it and it seems > to solve all the problems. Does that patch look good to you, too? > I think Jan is on vacation/offline currently. Can someone else comment about the patch? Can it be upstreamed? Sounds like it fixes an actual bug/problem. > Regards Andreas Thanks, -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] USB Passthrough support X86_64
On Fri, Jul 21, 2017 at 10:39:36AM +0200, Juergen Gross wrote: > > > > USB passthrough requires the device model. There is currently no > > provision in toolstack to spawn a device model on demand. > > > > The easiest workaround is to add one device (vfb?) that would require > > spawning a device model when creating the domain. > > > >> > >> i am trying to hotplug my usb. I haveint made any changes in the config > >> file, as i assumed it wont be needed for hotplug, also i didnt have to do > >> it for pci passthrough. Should i? > >> > >> Also, i cannot find any usbback and frond in my PC. > > Uuh, yes. I've sent some patches to LKML for pvUSB frontend support > about 2 years ago: > > https://lists.xen.org/archives/html/xen-devel/2015-06/msg03436.html > > I didn't find any time since then to address all comments. Maybe I > should finish that task... > That'd be awesome! :) > The patches should still work fine, AFAIK. > Good to know. -- Pasi > > Juergen > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] hw/pt-graphics.c: Gave guest iomem permission for host opregion in qemu-xen-traditional
Hi,
Perhaps Anthony can review this patch (noticing you reviewed other igd related
patches recently..) ?
Thanks,
-- Pasi
On Tue, Jun 27, 2017 at 12:12:50PM +0800, Xiong Zhang wrote:
> Currently guest couldn't access host opregion when igd is passed through
> to guest with qemu-xen-traditional. Because guest lack of
> iomem permission to map guest allocated opregion pages to host opregion
> pages.
>
> So guest should get iomem permission for host opregion before mapping.
>
> Signed-off-by: Xiong Zhang
> ---
> hw/pt-graphics.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index 7302b25..893bf12 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -78,10 +78,20 @@ void igd_write_opregion(struct pt_dev *real_dev, uint32_t
> val)
> igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);
> PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion);
>
> +ret = xc_domain_iomem_permission(xc_handle, domid,
> +host_opregion >> XC_PAGE_SHIFT, 3, 1);
> +if (ret)
> +{
> +PT_LOG("Error[%d]: Can't enable to access IGD host opregion: 0x%x\n",
> +ret, host_opregion >> XC_PAGE_SHIFT);
> +igd_guest_opregion = 0;
> +return;
> +}
> +
> ret = xc_domain_memory_mapping(xc_handle, domid,
> igd_guest_opregion >> XC_PAGE_SHIFT,
> host_opregion >> XC_PAGE_SHIFT,
> -2,
> +3,
> DPCI_ADD_MAPPING);
>
> if ( ret != 0 )
> --
> 2.7.4
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
On Fri, Jul 07, 2017 at 06:39:03PM +0200, Andreas Kinzler wrote: > Hello, > > I noticed that PCI passthrough for an LSI SAS HBA 9211 did not longer work > (at least under Windows) when using Xen 4.8.1. > I then bisected through various released versions and finally I narrowed it > down to > > 4.5.5 (with qemu from Xen 4.6.5) -> working > 4.6.0-rc1 (with qemu from Xen 4.6.5) -> no longer working > So can you please bisect which exact commit between Xen 4.5 and 4.6 causes the problem? > 4.6.4, 4.7.2, 4.8.1 -> no longer working > > dom0 kernel is 4.8.17 but that should not matter. > > PCI passthrough is still working when initializing the controller BIOS in > Seabios, but when Windows starts > it is stuck in an endless loop of spinning dots (see first seconds of > https://www.youtube.com/watch?v=3za5fsfYftQ). > My guess is that is has something to do with PCI enumeration. > > Any ideas? Help? > > Regards Andreas > Thanks, -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] HostedXen: Build Instructions
On Tue, Feb 14, 2017 at 09:40:17AM -0500, Konrad Rzeszutek Wilk wrote: > On Tue, Feb 14, 2017 at 11:08:11AM +0530, rohan kumbhar wrote: > > Hi, > > > > I am interested to restart Hosted Xen Project. > > > > I have gone through the presentation of Hosted Xen and Ian Pratt's video in > > Xen Summit 9. > > I have secured the source code for HostedXen from > > https://downloads.xen.org/HostedXen/release/ > > > > Tried to build it on windows but its failing. > > It would be of utmost help if detailed build instructions be available. > > Sorry :-( > > I think you are on your own. You could see labs.bromium.com ? > There's also this blog post, but he has probably already found it: https://blog.xenproject.org/2009/04/01/hosted-xen-project-kxen-available/ Although the "release" URL you have above is later version than the "snapshot" mentioned on the blog. mailinglist discussion thread about HXEN: http://markmail.org/thread/rd4vt53amplzpyj2 -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] dom0pvh issue with XEN 4.8.0
Hi, On Sun, Feb 05, 2017 at 04:05:32PM +0800, G.R. wrote: > Hi all, > dom0pvh=1 is not working well for me with XEN 4.8.0 + linux kernel 4.9.2. > > The system boots with no obvious issue. > But many user mode application are suffering from segfault, which > makes the dom0 not useable: The segfault always come from libc-2.24.so > while it works just fine in PV dom0. > I have no idea why, but those segfault would kill my ssh connection > while sshd is not showing up in the victim list. > > Some examples: > Feb 5 14:25:28 gaia kernel: [ 123.446346] getty[3044]: segfault at 0 > ip 7f5e769e6c60 sp 7ffc57bc0a98 error 6 in > libc-2.24.so[7f5e769b7000+195000] > Feb 5 14:29:04 gaia kernel: [ 339.671742] grep[4195]: segfault at 0 > ip 7f5d3b95ac60 sp 7ffcc1620bb8 error 6 in > libc-2.24.so[7f5d3b92b000+195000] > Feb 5 14:29:23 gaia kernel: [ 358.495888] tail[4203]: segfault at 0 > ip 7f751314bc60 sp 7fffe5ce5e48 error 6 in > libc-2.24.so[7f751311c000+195000] > Feb 5 14:35:06 gaia kernel: [ 701.314247] bash[4323]: segfault at 0 > ip 7f3fef30ec60 sp 7ffd48cc2058 error 6 in > libc-2.24.so[7f3fef2df000+195000] > Feb 5 14:48:43 gaia kernel: [ 1518.809924] ls[4910]: segfault at 0 ip > 7f29e9bc1c60 sp 7ffd712752b8 error 6 in > libc-2.24.so[7f29e9b92000+195000] > > Any suggestion on how to get this fixed? > I don't think I can do live debug since the userspace is quite unstable. > On the other hand, dmesg from both dom0 && XEN looks just fine. > > PS: I'm using a custom compiled dom0 kernel. Is there any specific > kernel config is required to get dom0pvh=1 work? > I think the plan is to replace/rewrite the PVH (dom0) support with PVHv2, see Roger's recent series here on xen-devel mailinglist.. > Thanks, > Rui > -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.9 Development Update
On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote: > >> > >>Should we have a section on new PV drivers? If so, I suggest to add: > >>- Xen transport for 9pfs > >>- PV Calls > > > >Good idea. We could also include DRM and PV Sound (CC Oleksandr). > > > This is a great idea. Let me explain what we have and what the direction is: > 1. Frontends which we already have, working, but need to refactor/cleanup: > 1.1. PV sound > 1.2. PV DRM > 1.3. DISPL protocol, I will push v1 for review right after sndif done > 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy > via DRM Prime buffer sharing) > 1.4. PV events not done, but we are considering [1]. If it fits and > is maintained, > then we'll probably stick to it, otherwise new PV will be created > > 2. Backends, for the above frontends already implemented: > 2.1. A unified library for Xen backends (libxenbe) > 2.2. DRM + Wayland > 2.3. ALSA > 2.4. Events not implemented yet > > All the above sources are available on *public* Github repos > (I can provide links on request) and the intention is to > upstream. > Please do post the links.. Thanks, -- Pasi > 3. We are interested in extending xl + libxl to support new PV drivers > > Thank you, > Oleksandr > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen Solaris support still required? Illumos/Dilos Xen
Hello Igor, I noticed you're using @dilos.org email address these days, so i'm sending this email again.. see below for more info and a question for you.. On Thu, Nov 03, 2016 at 03:56:32PM +0200, Pasi Kärkkäinen wrote: > On Thu, Nov 03, 2016 at 01:49:07PM +0100, Juergen Gross wrote: > > Xen tools contain several sources specific to Solaris, e.g. in > > libxc, xenstored, xenstat, some other libs. > > > > Is this still required? If yes, all of it? > > > > Google tells me Oracle has dropped XVM support on Solaris. > > Openindiana seems to have replaced XVM by a KVM port. > > > > In 2014 there was some work being done by Igor Kozhukhov (CC'd) to get > Illumos (Opensolaris) Xen support improved / working.. > > Illumos Xen 4.3 port status: > https://lists.xenproject.org/archives/html/xen-devel/2014-01/msg02240.html > > Illumos Xen dom0: > https://lists.xenproject.org/archives/html/xen-devel/2014-02/msg00146.html > > Illumos PV domU support: > https://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01160.html > > Let's hope Igor can comment if he's still working on Illumos Xen stuff.. > > > -- Pasi > Thanks, -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Wondering about cirris and stdvga
On Fri, Nov 18, 2016 at 07:04:15PM +0100, Dario Faggioli wrote: > Sending again, this time, with Anthony's and xen-devel address spelled > right. Sorry!! :-( > --- > Hello to you, various pseudo-random people, > > It's not my field of expertise, so bear with me, at least a little bit > (and, Konrad, you help me, or there will be consequences! :-D) > > So, I and Konrad recently discovered --while testing the about to be > released Fedora 25 as a Xen guest-- that the Cirrus emulated graphic > card that we consume from QEMU for HVM guests is broken on Wayland. > > We just discovered it because Fedora 25 uses Wayland by default, but it > appears not to be something new: > > https://bugzilla.redhat.com/show_bug.cgi?id=1227770 > > And at least from what we see in that bugreport, not much has happened > so far. > > Using "vga='stdvga'" in the config file, or even "vga='qxl'" make > things work again. Disabling Wayland in the guest also works (i.e., if > not using Wayland, Cirrus is ok). And that's what made us think that > it's probably a Wayland issue. > > I've tried the same on KVM, and the situation is identical > (Cirrus+Wayland=breaks, whatever-else+Wayland=works, > Cirrus+Xorg=works). > > I've also read around that these days, e.g., stdvga is at least as good > as cirrus, performance wise, that cirrus is broken and impossible to > fix (because it is the hardware that it's emulating that was broken), > that stdvga enables better screen resolution in guests, etc. > > I'm not sure about these claims, in particular the performance one, is > probably pretty hard to verify. And as I said, it's not my field. > > Still I thought it could be worthwhile to at least bring this up: > should we start to consider changing the default from cirrus to stdvga > (or something else)? > There's multiple things here.. 1) Yes, +1, let's change the Xen HVM default to "stdvga". 2) It'd good to create an upstream Wayland bugreport and investigate more about why cirrus is broken with Wayland. 3) It'd be good to have Xen HVM with "qxl" tested by OSStest aswell.. > Thanks for your time and Regards, > Dario Thanks, -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [DRAFT RFC] PVHv2 interaction with physical devices
On Wed, Nov 09, 2016 at 06:51:49PM +, Andrew Cooper wrote: > > > > Low 1MB > > --- > > > > When booted with a legacy BIOS, the low 1MB contains firmware related data > > that should be identity mapped to the Dom0. This include the EBDA, video > > memory and possibly ROMs. All non RAM regions below 1MB will be identity > > mapped to the Dom0 so that it can access this data freely. > > Are you proposing a unilateral identity map of the first 1MB, or just > the interesting regions? > > One thing to remember is the iBVT, for iscsi boot, which lives in > regular RAM and needs searching for. > I think you mean iBFT = iSCSI Boot Firmware Table. -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen Solaris support still required? Illumos Xen
On Thu, Nov 03, 2016 at 01:49:07PM +0100, Juergen Gross wrote: > Xen tools contain several sources specific to Solaris, e.g. in > libxc, xenstored, xenstat, some other libs. > > Is this still required? If yes, all of it? > > Google tells me Oracle has dropped XVM support on Solaris. > Openindiana seems to have replaced XVM by a KVM port. > In 2014 there was some work being done by Igor Kozhukhov (CC'd) to get Illumos (Opensolaris) Xen support improved / working.. Illumos Xen 4.3 port status: https://lists.xenproject.org/archives/html/xen-devel/2014-01/msg02240.html Illumos Xen dom0: https://lists.xenproject.org/archives/html/xen-devel/2014-02/msg00146.html Illumos PV domU support: https://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01160.html Let's hope Igor can comment if he's still working on Illumos Xen stuff.. -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] 3.18.y missing "x86/cpu: Fix SMAP check in PVOPS environments"
On Mon, Oct 24, 2016 at 11:37:14AM +0100, Ian Jackson wrote:
> Levin, Alexander writes ("Re: 3.18.y missing "x86/cpu: Fix SMAP check in
> PVOPS environments""):
> > On Tue, Oct 18, 2016 at 12:46:31PM -0400, Ian Jackson wrote:
> > > Hi. It appears that 3.18.y is lacking 581b7f158fe0 "x86/cpu: Fix SMAP
> > > check in PVOPS environments". Without this, it crashes when booting
> > > under Xen PVOPS on processors with the new SMAP feature.
> > >
> > > Andrew Cooper tells me this bug is definitely present in 3.18.y.
> > >
> > > Would you please consider applying this commit to 3.18 ? It appears
> > > to apply cleanly.
> >
> > Added, thanks!
>
> Thanks for your attention.
>
> Forgive me if I'm missing something obvious, but: I just fetched
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable
> and there the ref stable/linux-3.18.y was not updated and remains at
> 3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430 aka v3.18.43.
>
> When you say "added", do you mean it is in some branch of yours which
> will be pushed later ?
>
> (I tried to find the answer to my question by typing random junk into
> general web search engines, but without success.)
>
I can see Linux 3.18.44 at least here:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/sashal/linux-stable/+/linux-3.18.y-queue
With the SMAP/PVOPS fix included:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/sashal/linux-stable/+log/linux-3.18.y-queue
> Thanks,
> Ian.
>
-- Pasi
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] Hardware Random Number Generator (RNG) access from Xen VMs, providing more entropy to guests
Hello, Has anyone thought of writing Xen RNG (PV) driver? Afaik currently there's no access to hardware accelerated RNGs from Xen VMs, so for example SSL/TLS operations can result in low entropy and blocking /dev/random in Xen VMs, resulting in poor performance of applications. Running same applications on baremetal Linux result in much better performance because baremetal Linux can access the hardware RNG directly, and thus gets much more entropy. Qemu/KVM provides virtio-rng driver.. I wonder if that'd work easily with Xen aswell? I guess I should try.. virtio-rng backend is available in Qemu 1.3+: - http://wiki.qemu-project.org/Features/VirtIORNG - https://fedoraproject.org/wiki/Features/Virtio_RNG And virtio-rng driver is included in upstream Linux kernel since 2.6.26. Thanks, -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.8 Development Update
On Thu, Jul 21, 2016 at 05:07:23PM +0100, George Dunlap wrote: > > > > == Toolstack == > > > > * Make ACPI builder available to components other than hvmloader > > - Boris Ostrovsky > > > > * Libxl PVSCSI support > > - Olaf Hering > > > > * HVM USB passthrough > > - George Dunlap > > I am not currently working on this, so you can probably remove it from > the list for now. > Anyone else interested in picking up this HVM USB passthrough item? Thanks, -- Pasi > -George > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Remus and blktap2
Hi, On Fri, Apr 22, 2016 at 06:07:46PM +, Shriram Rajagopalan wrote: >Blktap2 was the first disk backend implementation. I moved Remus to DRBD >because it had disk resynchronization support. For eg, when primary fails, >backup takes over. When primary comes back online, DRBD would >automatically resynchronize new changes from the backup disk to the >primary disk and will continue to keep them synchronized. >At this stage, you have the option of starting Remus replication from >backup to primary, or, migrating the VM back to the primary host and doing >the primary to backup replication. > >The DRBD support (last I remember) is quite out of date, because the Remus >DRBD kernel module I wrote relies on an older kernel version (3.4?) and >older DRBD code base (8.1 I think). > Are there plans to get the Remus DRBD module upstreamed? Or working with recent DRBD versions? Thanks, -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs and Xen
Hello, And now all the components listed below are released and available easily. Dom0: - Qemu 2.5 has virtio-gpu 3D/OpenGL acceleration support for VMs. DomU: - Linux 4.4 kernel has the virtio-gpu drm driver. - Mesa 11.1 has the virtio-gpu 3D driver (virgl galliumd3 / OpenGL). Did anyone try this stuff with Xen already? :) -- Pasi On Mon, Nov 16, 2015 at 10:52:41PM +0200, Pasi Kärkkäinen wrote: > Hello, > > It seems upstream Linux/Gallium3D/Mesa/Qemu/KVM has recently gained > virtualized support for 3D/OpenGL hardware acceleration in VMs, allowing > using the GPU of the host in VMs. > > Components: > - Linux 4.4 kernel includes the DRM driver for VirtIO-GPU 3D > acceleration (needed in the VM). > - Qemu 2.5 (rc0) includes the VirtIO-GPU 3D mode support (needed on the > host/dom0). > - Gallium3D VirGL driver is included in Mesa git (needed in the VM, > supports up to OpenGL 3.3 atm). > - On the host/dom0 one needs *any* OpenGL driver (for the host GPU > obviously), no special requirements there, if I understood correctly. > > > Has someone looked into this already? How much work would it be to get > VirtIO-GPU working in Xen HVM guests? > > > Thanks, > > -- Pasi > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs and Xen
Hello, It seems upstream Linux/Gallium3D/Mesa/Qemu/KVM has recently gained virtualized support for 3D/OpenGL hardware acceleration in VMs, allowing using the GPU of the host in VMs. Components: - Linux 4.4 kernel includes the DRM driver for VirtIO-GPU 3D acceleration (needed in the VM). - Qemu 2.5 (rc0) includes the VirtIO-GPU 3D mode support (needed on the host/dom0). - Gallium3D VirGL driver is included in Mesa git (needed in the VM, supports up to OpenGL 3.3 atm). - On the host/dom0 one needs *any* OpenGL driver (for the host GPU obviously), no special requirements there, if I understood correctly. Has someone looked into this already? How much work would it be to get VirtIO-GPU working in Xen HVM guests? Thanks, -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [PULL 0/19] xen-2015-09-08-tag
Hi, On Mon, Sep 28, 2015 at 11:01:11AM +0100, Stefano Stabellini wrote: > No, unfortunately it is not possible at this stage of the release cycle. > But users can still use QEMU 2.5 (as soon as it is released, which > should be in a couple of months) with Xen 4.6 as there is not a strong > tie between QEMU releases and Xen releases. > Is backport to qemu-xen-4.6 possible *after* Xen 4.6.0 has been released? So basicly for Xen 4.6.1. There's value in having this feature available out-of-the-box, with stock Xen, without having to replace qemu with a custom build/version. Thanks, -- Pasi > On Mon, 28 Sep 2015, Chen, Tiejun wrote: > > On 9/22/2015 12:03 AM, Stefano Stabellini wrote: > > > It is going to be in QEMU 2.5 and qemu-xen 4.7. > > > > Thanks for your reply. > > > > Do we have any possibility of just merging this series into qemu-xen 4.6? We > > really want to support IGD passthrough on xen 4.6 if possible :) > > > > Thanks > > Tiejun > > > > > > > > On Mon, 21 Sep 2015, Chen, Tiejun wrote: > > > > Stefano, > > > > > > > > I have two questions, > > > > > > > > #1. Which qemu version is this igd stuff going into? 2.6? > > > > #2. Is this igd stuff going into qemu-xen inside xen? Any plan to go > > > > into > > > > xen > > > > 4.6? > > > > > > > > Thanks > > > > Tiejun > > > > > > > > On 9/9/2015 1:21 AM, Stefano Stabellini wrote: > > > > > The following changes since commit > > > > 8611280505119e296757a60711a881341603fa5a: > > > > > > > > > >target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 > > > > > +0200) > > > > > > > > > > are available in the git repository at: > > > > > > > > > >git://xenbits.xen.org/people/sstabellini/qemu-dm.git > > > > > tags/xen-2015-09-08-tag > > > > > > > > > > for you to fetch changes up to > > > > > ba2250ad148997b1352aba976aac66b55410e7e4: > > > > > > > > > >xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings. > > > > > (2015-09-08 15:21:56 +) > > > > > > > > > > > > > > > Xen branch xen-2015-09-08 > > > > > > > > > > > > > > > Don Slutz (1): > > > > >xen-hvm: Add trace to ioreq > > > > > > > > > > Jan Beulich (1): > > > > >xen/HVM: atomically access pointers in bufioreq handling > > > > > > > > > > Konrad Rzeszutek Wilk (7): > > > > >xen-hvm: When using xc_domain_add_to_physmap also include errno > > > > when > > > > > reporting > > > > >xen/pt: Update comments with proper function name. > > > > >xen/pt: Make xen_pt_msi_set_enable static > > > > >xen/pt: xen_host_pci_config_read returns -errno, not -1 on > > > > failure > > > > >xen: use errno instead of rc for xc_domain_add_to_physmap > > > > >xen/pt/msi: Add the register value when printing logging and > > > > error > > > > > messages > > > > >xen/pt: Use XEN_PT_LOG properly to guard against compiler > > > > warnings. > > > > > > > > > > Michael S. Tsirkin (1): > > > > >i440fx: make types configurable at run-time > > > > > > > > > > Tiejun Chen (9): > > > > >pc_init1: pass parameters just with types > > > > >piix: create host bridge to passthrough > > > > >hw/pci-assign: split pci-assign.c > > > > >xen, gfx passthrough: basic graphics passthrough support > > > > >xen, gfx passthrough: retrieve VGA BIOS to work > > > > >igd gfx passthrough: create a isa bridge > > > > >xen, gfx passthrough: register a isa bridge > > > > >xen, gfx passthrough: register host bridge specific to > > > > passthrough > > > > >xen, gfx passthrough: add opregion mapping > > > > > > > > > > configure | 28 + > > > > > hw/core/machine.c | 20 +++ > > > > > hw/i386/Makefile.objs |1 + > > > > > hw/i386/kvm/pci-assign.c | 82 ++--- > > > > > hw/i386/pc_piix.c | 139 - > > > > > hw/i386/pci-assign-load-rom.c | 93 ++ > > > > > hw/pci-host/piix.c| 91 +- > > > > > hw/xen/Makefile.objs |1 + > > > > > hw/xen/xen-host-pci-device.c |5 + > > > > > hw/xen/xen-host-pci-device.h |1 + > > > > > hw/xen/xen_pt.c | 42 ++- > > > > > hw/xen/xen_pt.h | 22 +++- > > > > > hw/xen/xen_pt_config_init.c | 59 - > > > > > hw/xen/xen_pt_graphics.c | 272 > > > > > + > > > > > hw/xen/xen_pt_msi.c |2 +- > > > > > include/hw/boards.h |1 + > > > > > include/hw/i386/pc.h |9 +- > > > > > include/hw/pci/pci-assign.h | 27 > > > > > include/hw/xen/xen_common.h | 34 +- > > > > > qemu-options.hx |3 + > > > > > trace-events |7 ++ > > > > > vl.c
Re: [Xen-devel] Non readable output with XEN 4.4.3 serial console
On Sat, Sep 26, 2015 at 08:17:05PM +0300, NiX wrote: > Hi. > Hi, > As I posted about a week ago. I had an issue with an AMD FX-8350/Radeon > 7970/Gigabyte GA-970A-UD3 and still do. After passing through the 7970, it > works just fine on windows 10 for as long as I do not reboot/shutdown that > VM. > > Upon shutting down or rebooting the VM whole system becomes unresponsive. > A full reboot of Dom0 is required in order to get passthrough working > again without a system crash. > > Someone suggested me to purchase a PCI serial card and I did. I can get > linux serial console working without any issue including login via that > console. > Good. > As soon as I enable XEN hvc0 in kernel boot params all I get is VGA > console output though I did not enabled it via XEN boot params. > > > A working one: GRUB_CMDLINE_LINUX="console=tty0 console=ttyS1,115200n81". > A non working one: GRUB_CMDLINE_LINUX="console=hvc0" as suggested at > http://wiki.xen.org/wiki/Xen_Serial_Console > Please add "earlyprintk=xen nomodeset" for dom0 linux kernel aswell.. "console=hvc0 earlyprintk=xen nomodeset". > dmesg | grep ttyS > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > 00:04: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > :03:07.0: ttyS1 at I/O 0xc120 (irq = 21) is a 16550A --> Is a PCI > serial card > > GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=4096M,max:8192M dom0_max_vcpus=4 > dom0_vcpus_pin iommu=1 loglvl=all guest_loglvl=all > com1=115200,8n1,0xc120,21 console=com1" > Did you try with "com1=115200,8n1,0xc120,0" ? So giving 0 as the irq. Also try with lower speeds.. like 38400, and even 9600. And dom0_mem should probably have the same value as initial and max. > Wit the above line I only get non-readable output. I tried it pretty much > all way around including different RTS/CTS options and 3 different tools > and the result was always non-readable output > With the correct options it'll work with Xen too. Which program are you using to display/capture the serial console? Thanks, -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] AMD Radeon 7970 passthrough on XEN 4.4.3 with an AMD FX-8350/Gigabyte GA-970A-UD3 *HORROR*
Hello, On Sat, Sep 19, 2015 at 08:21:15PM +0300, NiX wrote: > After a lot of trial and error I got it working as a secondary > pass-through. Thanks mainly to bullshit examples around the net. None seem > to know nothing. > > I though of I am the idiot but I was wrong. > GPU passthru isn't very simple or straight-forward unfortunately.. > Whole system crashes upon shutting down the VM that had the adapter passed > through. This actually screw up whole pass-through feature. Do that crash > happen because 7970 does not have device reset feature or whatever it was > called? > Do you happen to have a serial console available, so you could capture the crash/error messages from Xen and/or dom0 Linux kernel? SOL (Serial-Over-LAN) works too, if you have Intel AMT, IPMI, or other BMC.. > I got it working only few times and Battlefield 4 started and ran actually > surprisingly good at 50+ FPS with maxed details at 1600:900 on AMD 7970. > > However the next day immediately after when I attempt to login to VM > screen goes blank and whole system crashes (power off is required to > restore). It is also significantly lagged. ie. typing the password has > around 1 second delay per letter. > > This is unacceptable issue. Anyone else experienced the same horror? > > Thanks anyway for providing XEN but there are a lot to be fixed ... > > I've no issues on that VM when I don't use pass-through expect a > significantly high CPU usage in HVM mode when I start using the computer > say IE 11 browser. All cores have a 30-50% CPU usage when I do a small > tasks such as windows udpate etc. > How do you use the VM? I hope using RDP over the network.. > PS. That VM image is on Samsung 840 PRO SSD and it was loading the game > really fast when it worked. > > There was no difference to the issue wheter or not CCC was installed. -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Asus X99-A VT-d problems
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 IDENTIFY". > >I also tried to disable the SATA controller completely from BIOS and try >to boot from USB stick (to debug further). However, also the USB-ports >fail when using VT-d with error message "Fatal error, HC died" and then >the kernel panics. > >I googled around and tried the pci-phantom boot parameter for both the >SATA and USB controllers and also the iommu=workaround_bios_bug but with >no success. > >The SATA controller that my system is using is: > >00:1f.2 SATA controller: Intel Corporation Wellsburg 6-Port SATA >Controller [AHCI mode] (rev 05) > >And the USB controllers: > >00:14.0 USB controller: Intel Corporation Wellsburg USB xHCI Host >Controller (rev 05) >00:1d.0 USB controller: Intel Corporation Wellsburg USB Enhanced Host >Controller #1 (rev 05) >07:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host >Controller > >And lastly: I installed ESXI 6.0 and it installed successfully with VT-d >enabled. So I suspect that this might be a combination of BIOS/Xen bug >that VMware has been able to solve (or then they do something >differently). > >I'm happy to help to debug this further if needed, but so far I'm not able >to boot the system at all without iommu=0 boot parameter. > It'd be helpful if you could use a serial console (PCI serial card perhaps? Or if your motherboard has a built-in IPMI/BMC/AMT management processor with Serial-Over-LAN port that works aswell..) and capture a logfile from the full Xen + Linux boot.. with all the verbose/debugging options enabled. >Best regards, >Valtteri Kiviniemi -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch V4 1/3] usb: Add Xen pvUSB protocol description
On Thu, Jul 23, 2015 at 12:08:01PM -0700, Greg KH wrote: > > Somewhere that people can refer to that describes this public-facing API > that "must not ever be broken or changed". If you want to put it in a > documentation file, or a .h file, I don't care. > > > >>It is used e.g. in SUSE's xen kernel since 2.6.18. > > > > > >I am very aware of the amount of Xen crap in SuSE's kernel, don't use > > >that as an excuse for me to merge it to mainline :) > > > > :-) > > > > Wasn't meant as an excuse, just a hint why the interface can't be the > > same as for usbip. We have to ensure compatibility with those kernels > > This shouldn't be a kernel/kernel compability issue, as the api talks > between Xen and the OS, not between different OSs, right? > > > and possibly other operating systems (BSD?, Windows?) which already > > might be using pvUSB with a Dom0 based on the SUSE xen kernel. > > Are there other operating system drivers today that use this API? Is > this an API in the Xen core today that we have to support? > > Some more background / descriptions would be nice to have. > For example Xen "GPLPV" drivers for Windows do have PVUSB frontend driver.. -- Pasi > thanks, > > greg k-h > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On Wed, Mar 04, 2015 at 02:46:33PM +, Ian Campbell wrote: > On Wed, 2015-03-04 at 15:41 +0100, Juergen Gross wrote: > > On 03/04/2015 03:29 PM, Ian Campbell wrote: > > > On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote: > > >> On 04/03/15 14:09, Juergen Gross wrote: > > >>> > > >>> The main question whether it is worth to consider this alternative is > > >>> the performance aspect. Does anyone have an idea which USB devices would > > >>> typically be used via pvusb? I'd suspect memory sticks and USB disks > > >>> and perhaps webcams being the most performance relevant ones. Is an > > >>> additional copy operation of user data acceptable here? > > >> > > >> I have no idea. We (XenServer) have no use cases at all for USB device > > >> passthrough. > > > I've seen XenServer customers asking for USB passthru functionality on IRC channels.. > > > My gut feeling is that for USB 1 and 2 the bus itself isn't fast enough > > > that anyone would care. qdisk has acceptable for disks, so it's probably > > > ok for usb too. > > > > While I can accept the bus speed reasoning, I doubt qdisk is copying > > data between user and kernel space under normal circumstances. I think > > disk I/Os are done using DMA to/from the user buffer directly. > > I thought there was at least one copy on the datapath with qdisk, > wherever it is. But I don't know for sure. > > > > For usb 3 onwards, well, maybe when we care about those we'll decide > > > that a kernel space driver is needed, but for now it seems like > > > userspace would be ok. > > > > Do you have another feeling about the probability of a need to do usb 3? > > If it is already on the horizon I wouldn't want to do the user space > > backend now and the kernel one next year. :-) > > Well, what is *your* use case for USB passthru? I don't actually have > one myself. > > I'd speculate that people are more interested in passing in > low/medium/high speed devices rather than the superfast usb3 disks etc. > But I have no reason to back that up. > People seem to ask/need USB passthru support for various use cases including passing thru: webcams, video grabbers, printers, mobile broadband modems, copy protection dongles, gaming controllers, you name it.. -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen Development for Dummies.
On Fri, Feb 06, 2015 at 01:35:58PM +, Jason Long wrote: > In your opinion, Can a normal user like me become a developer? > I must first start learning C or Ocaml? Can you recommend a book for both to > me? > Can you tell me why developers choose Ocaml and C? and not C++ or Python? > Xen hypervisor, like any other hypervisor, is a very low level piece of software. Lowlevel software tends to be written in lowlevel languages, such as C and assembler. Like said most of Xen is written in C, so you need to learn/know C. You should first start with learning programming with C language, and the generic concepts of computer hardware, operating systems, kernels, memory management, etc. Something like a hypervisor, or an operating system kernel, is a quite complex beast, so you should probably first start with something much easier and learn C properly in an easier project. When you know C and Linux/Unix internals well you can continue working on Xen aswell. -- Pasi > Cheers. > > > > On Friday, February 6, 2015 2:46 AM, Pasi Kärkkäinen wrote: > On Fri, Feb 06, 2015 at 10:31:09AM +, Jason Long wrote: > > Can you tell me why Ocaml used? What is the features of this language? Why > > not other? > > Excuse me, I'm a beginner in programming and can you show me some books or > > reference step by step? I'm a dummies :( > > > > There are two different versions of xenstore-daemon (xenstored). > The earlier one, written in C, and the newer one, written in OCaml > (oxenstored). > > Note that this is just one of the many components in Xen. Most Xen components > are written in C. > > Here you have some slides about oxenstored: > http://gazagnaire.org/pub/GH09.pdf > > > -- Pasi > > > > Cheers. > > > > > > > > On Thursday, February 5, 2015 11:59 PM, Pasi Kärkkäinen > > wrote: > > On Fri, Feb 06, 2015 at 06:46:23AM +, Jason Long wrote: > > > Hello Folks. > > > I want to become a Xen developer and I don't have any knowledge about > > > development. Can you tell me what programming language is needed? How can > > > I start and etc? > > > > > > > Hello, > > > > Xen is mostly written in C language, but there are other languages being > > used aswell.. obviously lowlevel assembly language for some architecture > > specific lowlevel stuff, and some highler level languages (OCaml) for > > certain components (oxenstored). Also various scripting languages are used, > > perl, python, etc. > > > > Also you need to know all the usual Linux/Unix commandline (development) > > tools. > > > > -- Pasi > > > > > > > > > > Tnx. > > > > > > ___ > > > Xen-devel mailing list > > > Xen-devel@lists.xen.org > > > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen Development for Dummies.
On Fri, Feb 06, 2015 at 10:31:09AM +, Jason Long wrote: > Can you tell me why Ocaml used? What is the features of this language? Why > not other? > Excuse me, I'm a beginner in programming and can you show me some books or > reference step by step? I'm a dummies :( > There are two different versions of xenstore-daemon (xenstored). The earlier one, written in C, and the newer one, written in OCaml (oxenstored). Note that this is just one of the many components in Xen. Most Xen components are written in C. Here you have some slides about oxenstored: http://gazagnaire.org/pub/GH09.pdf -- Pasi > Cheers. > > > > On Thursday, February 5, 2015 11:59 PM, Pasi Kärkkäinen wrote: > On Fri, Feb 06, 2015 at 06:46:23AM +, Jason Long wrote: > > Hello Folks. > > I want to become a Xen developer and I don't have any knowledge about > > development. Can you tell me what programming language is needed? How can I > > start and etc? > > > > Hello, > > Xen is mostly written in C language, but there are other languages being used > aswell.. obviously lowlevel assembly language for some architecture specific > lowlevel stuff, and some highler level languages (OCaml) for certain > components (oxenstored). Also various scripting languages are used, perl, > python, etc. > > Also you need to know all the usual Linux/Unix commandline (development) > tools. > > -- Pasi > > > > > > Tnx. > > > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen Development for Dummies.
On Fri, Feb 06, 2015 at 06:46:23AM +, Jason Long wrote: > Hello Folks. > I want to become a Xen developer and I don't have any knowledge about > development. Can you tell me what programming language is needed? How can I > start and etc? > Hello, Xen is mostly written in C language, but there are other languages being used aswell.. obviously lowlevel assembly language for some architecture specific lowlevel stuff, and some highler level languages (OCaml) for certain components (oxenstored). Also various scripting languages are used, perl, python, etc. Also you need to know all the usual Linux/Unix commandline (development) tools. -- Pasi > > Tnx. > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC V2 0/5] pvusb toolstack work
On Wed, Jan 28, 2015 at 03:51:03PM +, Ian Campbell wrote: > On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote: > > This patch series is based on Simon's work. Since there is no progress > > after last August, I hope we can make this work proceed. Any comment will > > be very appreciated. > > > > It adds pvusb toolstack implementation, with pvusb kernel side work, > > one could attach/detach a usb device to guest. > > By any chance do you (or anyone else) have a link handy to the design > discussions for this stuff around the start of last year? > > In particular I'm hoping for some reminder on what the > libxl_usbctrl_type / libxl_usb_type options mean. > George probably knows/remembers the best.. > Although this is PV USB only I think the intention was to leave a > suitable hole for HVM emulated USB support. Or am I mis-remembering? > PVUSB should work with both PV and HVM guests, as long as the required PV drivers are in the domU kernel. -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching
Hello,
On Fri, Aug 22, 2014 at 08:45:03AM +, Gonglei (Arei) wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: Thursday, August 21, 2014 6:31 AM
> > To: Fabio Fantoni
> > Cc: Ross Philipson; Ian Campbell; Paul Durrant; ke...@koconnor.net;
> > Huangweidong (C); Hanweidong (Randy); m...@redhat.com;
> > qemu-de...@nongnu.org; xen-devel@lists.xen.org;
> > johannes.kra...@googlemail.com; Gonglei (Arei); Stefano Stabellini; Gaowei
> > (UVP); Jan Beulich; Anthony Perard
> > Subject: Re: [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only supply
> > _EJ0
> > methods for PCIslots that support hotplug by runtime patching
> >
> > On Wed, Aug 20, 2014 at 02:11:48PM +0200, Fabio Fantoni wrote:
> > > Il 12/05/2014 16:32, Ross Philipson ha scritto:
> > > >On 05/12/2014 05:05 AM, Ian Campbell wrote:
> > > >>On Fri, 2014-05-09 at 13:32 -0400, Ross Philipson wrote:
> > > >>>On 05/09/2014 12:34 PM, Paul Durrant wrote:
> > > >-Original Message-
> > > >From: Ian Campbell
> > > >Sent: 09 May 2014 17:12
> > > >To: Konrad Rzeszutek Wilk
> > > >Cc: Ross Philipson; ke...@koconnor.net; Huangweidong (C);
> > Hanweidong
> > > >(Randy); m...@redhat.com; qemu-de...@nongnu.org; xen-
> > > >de...@lists.xen.org; fabio.fant...@m2r.biz;
> > > >johannes.kra...@googlemail.com; Gonglei (Arei); Stefano Stabellini;
> > > >Gaowei (UVP); Jan Beulich; Anthony Perard; Paul Durrant
> > > >Subject: Re: [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only
> > > >supply
> > > >_EJ0 methods for PCIslots that support hotplug by runtime patching
> > >
> > > Ping...
> > > Are there any news about this patch?
> >
> > I think we are waiting on the patch submitter to do some homework
> > and reimplement the patch based on our feedback.
> > >
>
> I' m so sorry. It's so long time.
>
> And this work is not a top job for me right now.
>
Now that Xen 4.6 development has been opened, it would be good to get this ACPI
hotplug issue fixed aswell.
Gonglei: Do you think you'll have time to look at this, or should someone else
take a look at it?
Thanks,
-- Pasi
> Best regards,
> -Gonglei
>
> > > Thanks for any reply.
> > >
> > > >
> > > >On Fri, 2014-05-09 at 12:00 -0400, Konrad Rzeszutek Wilk wrote:
> > > >
> > > >>So we could just then gat the _EJ0 functionality based on values
> > > >>that
> > > >>are present (or not) in the SSDT ?
> > > >
> > > >AIUI the very presence of _EJ0 is what marks the device as being
> > > >ejectable (e.g. in the Windows device manager).
> > > >
> > > >It would be possible to make _EJ0 conditionally turn itself into a
> > > >NOP
> > > >without resorting to an SSDT, but I don't think that solves the issue
> > > >they are trying to solve, which is that the user can even try to
> > > >eject
> > > >an non-hotplug device. (grep for UAR1 in our dsdt.asl and
> > > >acpi_info->com1_present in hvmloader/acpi/build.c for an example
> > > >of this
> > > >sort of conditional thing)
> > > >
> > > >>>
> > > >>>Going back to the SSDT idea. A little poking around and what not and I
> > > >>>came up with something like this that I build into an SSDT:
> > > >>>
> > > >>>DefinitionBlock ("SSDTX.aml", "SSDT", 2, "Xen", "HVM", 0)
> > > >>>{
> > > >>> /* S00 device is defined in DSDT, this allows me to
> > > >>> * refrence it in this SSDT
> > > >>> */
> > > >>> External (\_SB.PCI0.S00, DeviceObj)
> > > >>>
> > > >>> ...
> > > >>>
> > > >>> /* Extend the functionality of S00 */
> > > >>> Scope ( \_SB.PCI0.S00 ) {
> > > >>> Method(_EJ0, 1, NotSerialized)
> > > >>> {
> > > >>> /* Do stuffs here */
> > > >>> }
> > > >>> }
> > > >>>}
> > > >>
> > > >>Thanks, this looks like the sort of thing I was naively imagining would
> > > >>be possible.
> > > >>
> > > >>>So I did find some examples of this after all in my pile of ACPI
> > > >>>firmware snapshots from all our supported platforms.
> > > >>
> > > >>Thanks (none of the machines I looked at had PCI hotplug apparently). I
> > > >>was curious to know how Real Firmware Engineers(tm) dealt with this sort
> > > >>of issue.
> > > >>
> > > >>I was worried how real life OSPMs might interpret this method being in
> > > >>an SSDT instead of the DSDT. In theory it shouldn't matter, and the fact
> > > >>that real firmware does this seem to suggest that at least Windows
> > > >>treats it that way (which is a relief).
> > > >
> > > >I did actually find SSDTs that were specifically adding an _EJ0 to a
> > > >device scope for a device defined externally. I attached an example from
> > > >a
> > > >Fujitsu system I have. The PRT1 device on SAT0 is external:
> > > >
> > > >External (\_SB_.PCI0.SAT0.PRT1, DeviceObj)
> > > >
> > > >And _EJ0 is added to the scope.
> > > >
> > > >>
> > > >>> I think this would
> > > >>>work allowing you to just add or not add _EJ0 methods
Re: [Xen-devel] [PATCH Linux-2.6.18] scsifront: avoid aquiring same lock twice if ring is full
Hi,
On Tue, Jan 13, 2015 at 05:22:58PM +0100, Juergen Gross wrote:
> The locking in scsifront_dev_reset_handler() is obviously wrong. In
> case of a full ring the host lock is aquired twice.
>
> Fixing this issue enables to get rid of the endless fo loop with an
> explicit break statement.
>
Is this patch needed in upstream Linux kernel aswell, now that Xen PVSCSI
drivers are in upstream Linux ?
Thanks,
-- Pasi
> Signed-off-by: Juergen Gross
> ---
>
> diff -r 078f1bb69ea5 drivers/xen/scsifront/scsifront.c
> --- a/drivers/xen/scsifront/scsifront.c Wed Dec 10 10:22:39 2014 +0100
> +++ b/drivers/xen/scsifront/scsifront.c Tue Jan 13 14:32:33 2015 +0100
> @@ -447,12 +447,10 @@ static int scsifront_dev_reset_handler(s
> uint16_t rqid;
> int err = 0;
>
> - for (;;) {
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,12)
> - spin_lock_irq(host->host_lock);
> + spin_lock_irq(host->host_lock);
> #endif
> - if (!RING_FULL(&info->ring))
> - break;
> + while (RING_FULL(&info->ring)) {
> if (err) {
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,12)
> spin_unlock_irq(host->host_lock);
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] (v2) Design proposal for RMRR fix
On Mon, Jan 12, 2015 at 11:25:56AM +, George Dunlap wrote: > On Fri, Jan 9, 2015 at 2:43 AM, Tian, Kevin wrote: > >> From: George Dunlap > >> Sent: Thursday, January 08, 2015 8:55 PM > >> > >> On Thu, Jan 8, 2015 at 12:49 PM, George Dunlap > >> wrote: > >> > If RMRRs almost always happen up above 2G, for example, then a simple > >> > solution that wouldn't require too much work would be to make sure > >> > that the PCI MMIO hole we specify to libxc and to qemu-upstream is big > >> > enough to include all RMRRs. That would satisfy the libxc and qemu > >> > requirements. > >> > > >> > If we then store specific RMRRs we want included in xenstore, > >> > hvmloader can put them in the e820 map, and that would satisfy the > >> > hvmloader requirement. > >> > >> An alternate thing to do here would be to "properly" fix the > >> qemu-upstream problem, by making a way for hvmloader to communicate > >> changes in the gpfn layout to qemu. > >> > >> Then hvmloader could do the work of moving memory under RMRRs to > >> higher memory; and libxc wouldn't need to be involved at all. > >> > >> I think it would also fix our long-standing issues with assigning PCI > >> devices to qemu-upstream guests, which up until now have only been > >> worked around. > >> > > > > could you elaborate a bit for that long-standing issue? > > So qemu-traditional didn't particularly expect to know the guest > memory layout. qemu-upstream does; it expects to know what areas of > memory are guest memory and what areas of memory are unmapped. If a > read or write happens to a gpfn which *xen* knows is valid, but which > *qemu-upstream* thinks is unmapped, then qemu-upstream will crash. > > The problem though is that the guest's memory map is not actually > communicated to qemu-upstream in any way. Originally, qemu-upstream > was only told how much memory the guest had, and it just "happens" to > choose the same guest memory layout as the libxc domain builder does. > This works, but it is bad design, because if libxc were to change for > some reason, people would have to simply remember to also change the > qemu-upstream layout. > > Where this really bites us is in PCI pass-through. The default <4G > MMIO hole is very small; and hvmloader naturally expects to be able to > make this area larger by relocating memory from below 4G to above 4G. > It moves the memory in Xen's p2m, but it has no way of communicating > this to qemu-upstream. So when the guest does an MMIO instuction that > causes qemu-upstream to access that memory, the guest crashes. > > There are two work-arounds at the moment: > 1. A flag which tells hvmloader not to relocate memory > 2. The option to tell qemu-upstream to make the memory hole larger. > > Both are just work-arounds though; a "proper fix" would be to allow > hvmloader some way of telling qemu that the memory has moved, so it > can update its memory map. > > This will (I'm pretty sure) have an effect on RMRR regions as well, > for the reasons I've mentioned above: whether make the "holes" for the > RMRRs in libxc or in hvmloader, if we *move* that memory up to the top > of the address space (rather than, say, just not giving that RAM to > the guest), then qemu-upstream's idea of the guest memory map will be > wrong, and will probably crash at some point. > > Having the ability for hvmloader to populate and/or move the memory > around, and then tell qemu-upstream what the resulting map looked > like, would fix both the MMIO-resize issue and the RMRR problem, wrt > qemu-upstream. > Hmm, wasn't this changed slightly during Xen 4.5 development by Don Slutz? You can now specify the mmio_hole size for HVM guests when using qemu-upstream: http://wiki.xenproject.org/wiki/Xen_Project_4.5_Feature_List "Bigger PCI MMIO hole in QEMU via the mmio_hole parameter in guest config, which allows configuring the MMIO size below 4GB. " "Backport pc & q35: Add new machine opt max-ram-below-4g": http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=commit;h=ffdacad07002e14a8072ae28086a57452e48d458 "x86: hvm: Allow configuration of the size of the mmio_hole.": http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2d927fc41b8e130b3b8910e4442d469d2ac7 -- Pasi > -George > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] (v2) Design proposal for RMRR fix
On Thu, Jan 08, 2015 at 06:02:04PM +, George Dunlap wrote: > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote: > On 08.01.15 at 16:59, wrote: > >> On Thu, Jan 8, 2015 at 1:54 PM, Jan Beulich wrote: > the 1st invocation of this interface will save all reported reserved > regions under domain structure, and later invocation (e.g. from > hvmloader) gets saved content. > >>> > >>> Why would the reserved regions need attaching to the domain > >>> structure? The combination of (to be) assigned devices and > >>> global RMRR list always allow reproducing the intended set of > >>> regions without any extra storage. > >> > >> So when you say "(to be) assigned devices", you mean any device which > >> is currently assigned, *or may be assigned at some point in the > >> future*? > > > > Yes. > > > >> Do you think the extra storage for "this VM might possibly be assigned > >> this device at some point" wouldn't really be that much bigger than > >> "this VM might possibly map this RMRR at some point in the future"? > > > > Since listing devices without RMRR association would be pointless, > > I think a list of devices would require less storage. But see below. > > > >> It seems a lot cleaner to me to have the toolstack tell Xen what > >> ranges are reserved for RMRR per VM, and then have Xen check again > >> when assigning a device to make sure that the RMRRs have already been > >> reserved. > > > > With an extra level of what can be got wrong by the admin. > > However, I now realize that doing it this way would allow > > specifying regions not associated with any device on the host > > the guest boots on, but associated with one on a host the guest > > may later migrate to. > > I did say the toolstack, not the admin. :-) > > At the xl level, I envisioned a single boolean that would say, "Make > my memory layout resemble the host system" -- so the MMIO hole would > be the same size, and all the RMRRs would be reserved. > There is e820_host= parameter for domUs already.. but currently it doesn't work for HVM guests afaik. -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] README, xen/Makefile: Update to Xen 4.5.0
On Wed, Jan 07, 2015 at 10:27:37AM -0500, Konrad Rzeszutek Wilk wrote: > > > > And I think there was optimizations to oxenstored to support up to 1000 VMs > > per host.. > > .. and that. > Actually I'm not sure anymore about "up to 1000 VMs per host".. I was certain I was reading about such number in the discussion related to some patches about performance improvements related to VDI bootstorms on xen-devel, but I can't find a reference now.. So maybe we should drop that number.. and only state performance/scalability improvements for oxenstored. Also the oxenstored fd limit was increased from 1024 to 4096, and oxenstored switched from select() to poll() for increased scalability/performance. -- Pasi > diff --git a/README b/README > index 4a9cac1..e2c9e83 100644 > --- a/README > +++ b/README > @@ -43,8 +43,9 @@ guests; and lower interrupt latency. > The toolstack has expanded to include support for: VM Generation ID (a > Windows 2012 Server requirement); Remus initial support (for high > availability) in libxl (since xend has been removed); libxenlight JSON > -support and persistent configuration support, and systemd support; and > -support in QEMU for expanding the PCI hole. > +support, HVM guest direct kernel boot, and persistent configuration > +support; systemd support; optimizations in oxenstored to support more > +than 1000+ VMs; and support in QEMU for expanding the PCI hole. > > Lastly, we have removed the Python toolstack (xend). > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] README, xen/Makefile: Update to Xen 4.5.0
On Tue, Jan 06, 2015 at 01:21:58PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 06, 2015 at 06:06:23PM +, Ian Jackson wrote:
> > Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH] README, xen/Makefile:
> > Update to Xen 4.5.0"):
> > > -The 4.3 release offers a number of improvements, including NUMA
> > > -scheduling affinity, openvswitch integration, and defaulting to
> > > -qemu-xen rather than qemu-traditional for non-stubdom guests.
> > > -(qemu-xen is kept very close to the upstream project.) We also have a
> > > -number of updates to vTPM, and improvements to XSM and Flask to allow
> > > -greater disaggregation. Additionally, 4.3 contains a basic version of
> > > -Xen for the new ARM server architecture, both 32- and 64-bit. And as
> > > -always, there are a number of performance, stability, and security
> > > +The 4.5 release offers a number of improvements: including shedding
> >
> > Should read
> > +The 4.5 release offers a number of improvements, including: shedding
> > (note two punctuation changes) and the list items should all be
> > separated with semicolons IMO.
>
>
> Thank you for your update.
>
> I've incorporated feedback from all folks I hope. Would this be satisfactory?
>
Do we want to mention things like HVM guest direct kernel boot,
or HVM guests MMIO hole resize support?
And I think there was optimizations to oxenstored to support up to 1000 VMs per
host..
-- Pasi
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] HVM PCI Passthrough: Code 12: Undersized PCI MMIO region?
On Tue, Dec 02, 2014 at 10:08:35PM -0500, Stephen Oberholtzer wrote:
> All,
>
Hello,
> Please bear with me. I don't fully understand all of the mechanisms
> involved here, so this message contains a large quantity of data,
> including some links to even larger quantities of data.
> The short version is: I think something isn't reserving enough (GPFN)
> address space for MMIO.
>
This issue probably should be taken to xen-devel mailinglist.. CC added..
> I'm trying to do a three-part PCI passthrough to a HVM domU running Windows
> 8.1:
> 00:14.0, An xHCI (USB 3.0) controller
> 01:00.0, Function 0 of an ATI card (VGA controller, non-primary passthrough)
> 01:00.1, Function 1 of the same ATI card (HDMI audio)
>
> The USB controller seems to work fine. USB mouse/keyboard are
> functional, and I plugged in a few Mass Storage devices and they work
> fine.
> The HDMI audio controller is harder to vet, because I don't have
> anything that will process audio without an associated video stream.
> However, I don't get any complains from the software.
>
> For the the VGA controller (01:00.0), Windows reports "Code 12" and
> complains about insufficient resources being available for the device.
>
> I tried to gather all of the information I could on the memory layouts
> involved, from three sources:
> (1) From dom0 and Xen itself
> (2) From domU running Windows, using a program called "SIV" (System
> Information Viewer)
> (3) From domU running Linux (by booting a Knoppix live DVD image)
>
> ---
>
> Information from dom0:
> http://www.klozoff.org/xen/dom0-xl-info.txt - 'xl info'
> http://www.klozoff.org/xen/dom0-xl-dmesg.txt - 'xl dmesg'
> http://www.klozoff.org/xen/dom0-proc_iomem.txt - 'cat /proc/iomem'
> http://www.klozoff.org/xen/dom0-lspci-output.txt - 'lspci -vvv' for
> the three devices I'm forwarding.
>
> Information from domU (Windows):
> http://www.klozoff.org/xen/domU-device-manager-info.txt - Text
> transcribed from Windows' "Device Manager"
> http://www.klozoff.org/xen/domU-siv-usb-controller-info.txt -
> Information on 00:14.0 from SIV
> http://www.klozoff.org/xen/domU-siv-video-card-info.txt - Information
> on 01:00.0 from SIV
> http://www.klozoff.org/xen/domU-siv-hdmi-audio-info.txt - Information
> on 01:00.1 from SIV
>
> Information from domU (Linux/Knoppix):
> http://www.klozoff.org/xen/domU-knoppix-proc-iomem.txt - 'cat /proc/iomem'
> http://www.klozoff.org/xen/domU-knoppix-lspci-output.txt - 'lspci
> -vvv' for the three devices.
>
>
> ---
>
> Of particular interest to me is domU-knoppix-lspci-output.txt, which
> for the VGA controller, says:
>
> Region 0: Memory at (64-bit, prefetchable)
> Region 2: Memory at f304 (64-bit, non-prefetchable) [size=256K]
>
> In dom0, this showed as:
>
> Region 0: Memory at d000 (64-bit, prefetchable) [size=256M]
> Region 2: Memory at efc0 (64-bit, non-prefetchable) [size=256K]
>
>
> I looked closer by running the following script:
>
> perl -lne '/^([0-9a-f]+)-([0-9a-f]+)/ && print $_, " (", ((hex($2) -
> hex($1)) >> 20), " MB)"' /proc/iomem
>
> In dom0, I see this:
>
> 0010-99f53fff : System RAM (2462 MB)
> bf20-feaf : PCI Bus :00 (1016 MB) <- Region 0 is in this range
> 1-83edf : System RAM (29677 MB)
>
>
> In domU, I see this:
> 0010-effecfff : System RAM (3838 MB)
> f000-fbff : PCI Bus :00 (191 MB)<- Definitely not big
> enough to hold the 256MB we need
> 1-20f7f : System RAM (4343 MB)
>
> Now, I don't fully understand how this stuff all works, but here's
> what appears to be happening: Xen isn't reserving enough contiguous
> GPFN (virtual machine address space) for all of the devices on the
> virtual PCI bus -- in particular, for what is probably a big honkin'
> window into the card's onboard RAM.
>
> So my two questions are:
> (1) Is my guess correct? Or at least close?
> (2) What the heck do I do about it? I don't see any options in
> xl.cfg(5) for specifying the size of the MMIO region for the virtual
> PCI bus, or anything similar to that.
>
>
> NOTE: If I assign 2048MB or less RAM to this VM, the VM crashes at
> bootup, and has a nasty tendency to take the host with it (lockup).
>
> --
> -- Stevie-O
> Real programmers use COPY CON PROGRAM.EXE
>
-- Pasi
> ___
> Xen-users mailing list
> xen-us...@lists.xen.org
> http://lists.xen.org/xen-users
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (RC4) - Documentation Updates
On Fri, Dec 19, 2014 at 03:30:23PM +, Jan Beulich wrote: > >>> On 19.12.14 at 15:52, wrote: > > ** The key changes normally are changes to scalability/memory/etc. limits - > > maybe Jan(x86) and Ian(ARM) can look let me know of changes > > Iirc scalability changes on the x86 side were mostly (if not exclusively) > in terms of performance improvements (in some cases getting bigger > guests out of not booting at all state). > Hmm, wasn't there improvements to allow more VMs per host aswell.. ? which would be worth mentioning.. xenstored related stuff iirc. -- Pasi > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] SRIOV on a NIC card
On Sun, Dec 14, 2014 at 07:05:18PM +0530, Galla Rao wrote: >Am trying to boot a guest OS on a Virtual Function, It hangs in preboot >The server is not a x86, it is on SUN SPARC > Afaik Xen has never been ported to SPARC.. Are you sure you're using Xen hypervisor? -- Pasi >What BIOS/pre-boot has to enable to make Guest OS boot on VF >The PF& VF driver in OS are working well >VF Enable is set >VF MSE is set >What could be the possible failure? >Any thoughts welcome, Thanks for your time! >Regards >Ranga ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V5] Update pvSCSI protocol description / libxl
Hello, Juergen/Olaf: Now that Xen PVSCSI drivers are in upstream Linux 3.18 kernel I was wondering if you guys also have plans to work on adding xl / libxl support for PVSCSI ? Thanks, -- Pasi On Thu, Aug 28, 2014 at 06:14:32AM +0200, Juergen Gross wrote: > Update the protocol description of the pvSCSI framework used to pass through > SCSI devices to a guest (pv or hvm). > > The main changes are: > - added comments > - add support for larger SG-lists by putting them in an own granted page > - deprecate VSCSIIF_ACT_SCSI_SG_PRESET action with related structures > - add ref_rqid for action VSCSIIF_ACT_SCSI_ABORT to be able to specify the > request to abort > - deprecate timeout_per_command as this really should be handled by the > backend in case of default settings or by the guest domain by aborting a > long running command > > This update is related to the rework of the pvSCSI backend and frontend > drivers > in the Linux kernel. This interface version is included in that rework, too. > > Signed-off-by: Juergen Gross > Reviewed-by: David Vrabel > Reviewed-by: Konrad Rzeszutek Wilk > --- > xen/include/public/io/vscsiif.h | 185 > +++- > 1 file changed, 164 insertions(+), 21 deletions(-) > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
On Fri, Nov 28, 2014 at 08:00:40PM -0600, Dr. Greg Wettstein wrote: > On Nov 27, 12:11pm, Sander Eikelenboom wrote: > } Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind. > > Hi, hope the week has gone well for everyone. > Hello, hopefully your weekend is going well. > > > So we are obviously working with qemu-dm-traditional and with the > > > IGD/LVDS BIOS configuration issue fixed the adapater passthrough is > > > working and Windows7 is coming up and detecting the IGD as a standard > > > VGA display adapter. Additional invocations of the VM after the first > > > one result in failed passthrough with a garbled display. > > > This is probably due to the current lack of slot/bus reset in > > xen-pciback, Konrad has a preliminary kernel patch for xen-pciback > > that does this. I have attached the patch, though it has some rough > > edges in the design :-) > > > > I'm currently running with his 3.19 xen-pciback patches series + the > > preliminary patch for slot/bus reset and rebooting a guest with > > vga/pci passthrough now works. (i'm running with a radeon card, > > passed through as a secondary card to the emulated qemu one, in a > > linux guest using qemu-xen, so i can't help you with your other > > questions and problems). > > Thanks for taking the time for respond and forward along the patch. > > I back ported the do_flr patch into the 3.14.x kernel and spent some > time working with it. I thought it might be useful to others to > document what we ran into. > > First of all the issue with the unsuccessful boot of Windows after the > first invocation doesn't appear to have anything to do with resetting > the card. This was fixed by installing the most recent version of the > Intel HD drivers in the Windows guest. > > If IGD passthrough is done without the HD drivers Windows 7 appears to > use its standard VGA driver which seems to be able to initialize and > run the IGD device but does not appear to shutdown the device in a > manner in which it can be re-started. After the first invocation of > the guest is shutdown the screen goes to a solid color. Subsequent > invocations result in the flashing multi-color screens which others > have documented. > > With the HD drivers installed IGD passthrough works fine through > multiple invocations of a guest with the stock xen-pciback in 3.14.x. > We ran 40-50 repetitive Windows guest invocations and every one was > completely deterministic. > It would be nice if you could let us know the exact Intel IGD Windows driver version that worked well for you? It might be a good reference for others aswell. Thanks, -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
On Mon, Nov 24, 2014 at 03:59:49AM -0600, Dr. Greg Wettstein wrote: > On Nov 23, 4:26pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote: > } Subject: Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind. > > Hi Pasi, hope your week is starting out well, hi to Konrad from Oracle > as well as I see you included him. > Hello, > > On Fri, Nov 21, 2014 at 02:57:14PM -0600, Dr. Greg Wettstein wrote: > > > Hi, hope the week is ending well for everyone. > > > > > > As readers of the list may remember we've kept the ATI primary adapter > > > passthrough patches current for qemu-traditional on Xen for a number > > > of years. Our 'run-passthrough' utility for binding/unbind devices > > > and running a Windows guest with passthrough have enjoyed a tidy > > > number of downloads through the years as well. > > > > > > We are taking on a passthrough project and in the process upgrading > > > our infrastructure to 4.4.x. We also need to take on the issue of > > > passing Intel IGD adapters through to a windows guest. We are > > > currently working on an Intel Q77 (DQ77KB) board in preparation for > > > moving to Q87 boards. > > > > > > The Intel display adapter is showing up as the standard 00:02.0 PCI > > > device and things go south pretty quickly. We create a slot for the > > > device on the pciback driver and as soon as we bind the device the > > > machine goes out like a light, no logs or diagnostics, just instantly > > > stone dead. > > I'm consolidating your comment from your other response as well so we > keep this on the same thread. > OK. > >> As I was walking out the door I remembered I had been delinquent > >> with information. The dom0 kernel is 32-bit 3.14.22 straight from > >> kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources. > > > Wow, quite an old thread :) > > > > So you're still seeing the same problem with recent Xen/Linux > > versions.. > > Yes, the perils of platforming for 7 year field deployments... :-) > > I can certainly build up a toolchain against the HEAD of XEN git and > the most recent release of the kernel if everyone feels that would be > beneficial. > > > This might be a stupid question, but here goes anyway: Do you have > > serial console set up? And all the debug/verbose options specified > > for Xen and Linux? > > The platform in question doesn't have any serial ports, at least not > surfaced. We will need to do a bit of wiring if we need to go in that > direction. > You mentioned it's Intel Q77 chipset based motherboard.. which means it should have Intel AMT functionality, which provides SOL (Serial-over-LAN), which you can use as a serial console for Xen. There are tools (at least amtterm) that you can use on another box to connect to the AMT SOL remotely.. > Now that I have the machine in a harness in the lab I will stick a > '#define DEBUG 1' in the top of drivers/xen/xen-pciback/pci_stub.c > since that is where the action seems to be going on. > > The platform is headed for a measured computing environment so I > thought there may be some type of conflict with tboot holding a > reference to the VGA driver but I verified the issue in a straight > hypervisor boot. > > I see that Tiejun Chen from Intel is sorting out issues with respect > to the need to export the ISA bridge into the device emulator in order > to support passthrough on these IGD devices. I bound the 00:1f.0 ISA > bridge device to pciback and that worked but it did not change the > behavior of the regression. When the 00:02.0 device is bound to > pciback the display is cleared and the machine dies in its tracks. > Yeah, Tiejun is working on upstreaming the IGD passthru patches to Qemu-upstream. Qemu-dm-traditional already has (most of) the IGD passthru patches. Hope that helps, -- Pasi > I will turn up debugging in pci_stub and see if I can pinpoint where > things blow up, somewhere in pcistub_init_device() I would imagine. > > > Thanks, > > > > -- Pasi > > Have a good day. > > }-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= > > As always, > Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. > 4206 N. 19th Ave. Specializing in information infra-structure > Fargo, ND 58102development. > PH: 701-281-1686 > FAX: 701-281-3949 EMAIL: g...@enjellic.com > -- > "Snow removal teaches all the important elements of succesful corporate > politics: 1.) Be the first one to work. 2.) Always signal your > intentions before moving. 3.) Be damn sure you're driving something > big enough to deal with anything that decides not to get out of your way." > -- Dr. G.W. Wettstein >Guerrilla Tactics for Corporate Survival ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
On Fri, Nov 21, 2014 at 02:57:14PM -0600, Dr. Greg Wettstein wrote: > Hi, hope the week is ending well for everyone. > > As readers of the list may remember we've kept the ATI primary adapter > passthrough patches current for qemu-traditional on Xen for a number > of years. Our 'run-passthrough' utility for binding/unbind devices > and running a Windows guest with passthrough have enjoyed a tidy > number of downloads through the years as well. > > We are taking on a passthrough project and in the process upgrading > our infrastructure to 4.4.x. We also need to take on the issue of > passing Intel IGD adapters through to a windows guest. We are > currently working on an Intel Q77 (DQ77KB) board in preparation for > moving to Q87 boards. > > The Intel display adapter is showing up as the standard 00:02.0 PCI > device and things go south pretty quickly. We create a slot for the > device on the pciback driver and as soon as we bind the device the > machine goes out like a light, no logs or diagnostics, just instantly > stone dead. > This might be a stupid question, but here goes anyway: Do you have serial console set up? And all the debug/verbose options specified for Xen and Linux? Thanks, -- Pasi > This issue is invariant over pciback in vpci or passthrough modes. It > also occurs instantly when the pciback assignment is made with 'xl > pci-assignable-add'. > > We will throw a '#define DEBUG 1' in the top of all the xen-pciback > driver code and see if we can get more information out of it. I just > wanted to get this in front of the list in case this is a well known > issue or we are headed into other problems we should know about. > > I'm assuming that qemu-traditional will handle an IGD primary > passthrough. If any of the Intel guys are reading this give me a > shout with some directions/advice if we need to roll up our sleeves > and modify the device emulator. > > At least it is an "Outlaw Josey Whales bug', not hard to track, leaves > dead machines wherever it goes... :-) > > Best wishes for a pleasant weekend to everyone. > > Greg > > As always, > Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. > 4206 N. 19th Ave. Specializing in information infra-structure > Fargo, ND 58102development. > PH: 701-281-1686 > FAX: 701-281-3949 EMAIL: g...@enjellic.com > -- > "The cynics are right nine times out of ten." > -- H. L. Mencken > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
On Sun, Nov 23, 2014 at 04:05:48PM +0200, Pasi Kärkkäinen wrote: > On Fri, Nov 21, 2014 at 03:02:33PM -0600, Dr. Greg Wettstein wrote: > > On Nov 21, 2:57pm, "Dr. Greg Wettstein" wrote: > > } Subject: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind. > > > > > Hi, hope the week is ending well for everyone. > > > > As I was walking out the door I remembered I had been delinquent with > > information. The dom0 kernel is 32-bit 3.14.22 straight from > > kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources. > > > > Wow, quite an old thread :) > Oh, there's also the new thread about this, I guess it's better to continue there :) http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02123.html -- Pasi > So you're still seeing the same problem with recent Xen/Linux versions.. > > > > The machine hang is reproducible in the absence of even starting a > > guest so the problem appears to be specific to the process of > > preparing the device for export through xen-pciback. > > > > OK.. Maybe Konrad has some thoughts about this. > > > -- Pasi > > > > Greg > > > > }-- End of excerpt from "Dr. Greg Wettstein" > > > > As always, > > Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. > > 4206 N. 19th Ave. Specializing in information infra-structure > > Fargo, ND 58102development. > > PH: 701-281-1686 > > FAX: 701-281-3949 EMAIL: g...@enjellic.com > > -- > > "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. > > Geniuses remove it. > > -- Perliss' Programming Proverb #58 > >SIGPLAN National, Sept. 1982 > > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind.
On Fri, Nov 21, 2014 at 03:02:33PM -0600, Dr. Greg Wettstein wrote: > On Nov 21, 2:57pm, "Dr. Greg Wettstein" wrote: > } Subject: [Xen-devel] Q77 IGD instantly crashes on xen-pciback bind. > > > Hi, hope the week is ending well for everyone. > > As I was walking out the door I remembered I had been delinquent with > information. The dom0 kernel is 32-bit 3.14.22 straight from > kernel.org under a 64-bit hypervisor compiled from 4.4.1 sources. > Wow, quite an old thread :) So you're still seeing the same problem with recent Xen/Linux versions.. > The machine hang is reproducible in the absence of even starting a > guest so the problem appears to be specific to the process of > preparing the device for export through xen-pciback. > OK.. Maybe Konrad has some thoughts about this. -- Pasi > Greg > > }-- End of excerpt from "Dr. Greg Wettstein" > > As always, > Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. > 4206 N. 19th Ave. Specializing in information infra-structure > Fargo, ND 58102development. > PH: 701-281-1686 > FAX: 701-281-3949 EMAIL: g...@enjellic.com > -- > "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. > Geniuses remove it. > -- Perliss' Programming Proverb #58 >SIGPLAN National, Sept. 1982 > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
