search for: do_flr

Hi As we will use xl in xen 4.1. I had try use xl to do something. And I find some command is fails. For config file, when give "disk=" too args, it will show segment fault if we use xl create to start guest. Is there any change for xl''s config file? Following command can not work: xl migrate: when I use xl migrate domain localhost to do migrate, it shows error:

I think we need this feature at least for debugging purpose, right? Or, do we already have this feature? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...-------------------------------------------------------------------- diff -r 6ab55f716ce3 tools/python/xen/util/pci.py --- a/tools/python/xen/util/pci.py Thu Oct 09 17:18:11 2008 +0100 +++ b/tools/python/xen/util/pci.py Fri Oct 10 13:16:00 2008 +0800 @@ -696,6 +696,7 @@ class PciDevice: def do_FLR(self): """ Perform FLR (Functional Level Reset) for the device. """ + return if self.dev_type == DEV_TYPE_PCIe_ENDPOINT: # If PCIe device supports FLR, we use it. if self.pcie_flr: diff -r 6ab55f716ce3 to...

...we might as well move the logic to Control Panel for the time being. In the long run, the essential logic may be implemented in the pciback driver of Dom0 instead. [PATCH1] sysmnt_cleanup.patch: this is only a small cleanup. [PATCH2] remove_FLR_in_xen.patch: remove the FLR logic in Xen. [PATCH3] do_FLR_in_control_panel.patch: the improved FLR logic in Control Panel: 1) If the device is PCIe endpoint and supports PCIe FLR, we use that; 2) Else, if the device is PCIe endpoint, and all functions on the device are assigned to the same guest, we use the immediate parent bus''s Secondary Bus R...

Hello Xen Users, I have attached the latest copy of my own documentation in PDF format as well as some error files related to the latest tests I ran. I have documented the steps I took to reach my current situation. While I have a "working" install, it is not optimal and there are several problems and questions I would like to address: - If Dom0 is a privileged DomU, should we be

...} } @@ -267,15 +267,20 @@ int libxl_devices_destroy(struct libxl_ctx *ctx, uint32_t domid, int force) int libxl_device_pci_flr(struct libxl_ctx *ctx, unsigned int domain, unsigned int bus, unsigned int dev, unsigned int func) { + char *do_flr= "/sys/bus/pci/drivers/pciback/do_flr"; FILE *fd; - fd = fopen("/sys/bus/pci/drivers/pciback/do_flr", "w"); + fd = fopen(do_flr, "w"); if (fd != NULL) { fprintf(fd, PCI_BDF, domain, bus, dev, func); fclose(fd); ret...

...return 0; } +static int libxl_device_pci_reset(libxl_gc *gc, unsigned int domain, unsigned int bus, + unsigned int dev, unsigned int func) +{ + libxl_ctx *ctx = libxl_gc_owner(gc); + char *reset; + int fd, rc; + + reset = libxl_sprintf(gc, "%s/pciback/do_flr", SYSFS_PCI_DEV); + fd = open(reset, O_WRONLY); + if (fd > 0) { + char *buf = libxl_sprintf(gc, PCI_BDF, domain, bus, dev, func); + rc = write(fd, buf, strlen(buf)); + if (rc < 0) + XL_LOG(ctx, XL_LOG_ERROR, "write to %s returned %d", reset...